Clash 端口被占用怎么办：7890 冲突定位与 mixed-port 修改方法

先看日志：确认是监听冲突

处理顺序是：确认报错端口、查监听进程、决定释放还是改端口，最后同步调用方。7890 只是 Clash 配置中常见的代理端口，并不是必须使用的固定值。把它改成空闲的 7893 可以解决冲突，但前提是客户端已经应用新配置，浏览器、系统代理和终端也已改用新端口。

在客户端的日志页面查找 bind、listen 或 address already in use。不同内核与系统的完整措辞会有差异，关键是看错误中出现的地址、端口和协议。例如，下列日志片段说明 TCP 监听 7890 失败，不能据此判断代理服务器是否可用：

listen tcp 127.0.0.1:7890: bind: address already in use

• 127.0.0.1:7890：监听本机回环地址的 7890 端口。
• 0.0.0.0:7890：尝试监听所有 IPv4 接口，可能与已有的回环监听产生冲突。
• [::]:7890：IPv6 通配地址；是否同时影响 IPv4，取决于系统及套接字设置。
• connection refused：通常是连接目标未监听或主动拒绝，不等同于端口占用。

分清 mixed-port 与控制端口

Clash 客户端是管理界面，实际监听通常由内核进程负责。使用 Clash Meta（现称 mihomo）的客户端也遵循这种分工。界面里的“端口”可能对应多种入口，必须按日志中的数字追查，而不是看到 7890 就统一修改所有字段。

例如，mixed-port: 7890 可以同时供 HTTP 与 SOCKS5 调用，不需要再把 port 和 socks-port 也设成 7890。多个独立监听字段使用相同地址与端口，可能产生自身配置冲突。若只需要一个混合入口，可以在确认客户端支持后保留混合端口，移除不使用的独立入口。

external-controller: 127.0.0.1:9090 则是另一类服务。系统代理不应填 9090；修改它也不会解决 7890 的代理监听失败。控制端口涉及管理权限，应保持本机绑定并保留原有认证设置，不要为排查冲突随意开放到局域网。

Windows：用 netstat 定位进程

第一步：查监听记录与 PID

打开 PowerShell 或命令提示符，执行以下命令。第一条会筛出包含 7890 的行，第二条则利用 PowerShell 按本地监听端口精确查询：

netstat -ano -p tcp | findstr ":7890"

powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"

阅读 netstat 输出时，先确认“本地地址”的端口为 7890，再找状态为 LISTENING 的行。只看包含数字的整行容易误把远端端口或 17890 当成目标。最后一列是 PID；例如查到 PID 为 6240，再查询进程名称：

tasklist /FI "PID eq 6240"

这里的 6240 只是命令示例，应换成当前查询结果。若需要核对可执行文件路径与启动参数，可以在 PowerShell 中继续检查；读取其他用户进程的信息可能需要管理员权限：

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine

第二步：按进程归属处理

• 另一个代理客户端：从其托盘菜单退出，确认后台内核已结束，再启动要使用的客户端。
• 同一客户端的残留内核：先正常退出客户端，复查端口；确认进程路径与归属后，再通过任务管理器结束残留进程。
• 需要保留的本地服务：不要强行终止，改用已确认空闲的代理端口。
• 未知进程或系统服务：先核实路径和服务来源，不要仅凭 PID 执行强制终止命令。

如果没有监听记录，却报“以一种访问权限不允许的方式做了一个访问套接字的尝试”，应进一步区分端口保留与权限问题。可以运行 netsh interface ipv4 show excludedportrange protocol=tcp 查看 TCP 排除范围；若候选端口落在范围内，优先换用范围外的空闲端口，不要随意删除系统保留项。

macOS 与 Linux：用 lsof、ss 检查

macOS：只查看 TCP 监听

打开终端执行下面的命令。-nP 保留数字形式的地址和端口，-sTCP:LISTEN 只显示监听状态，便于排除普通连接。需要查看其他用户的进程时再使用 sudo：

lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

关注输出中的 COMMAND、PID 与 NAME。如果占用者是另一个客户端，先从菜单栏退出该客户端；如果退出后很快重新出现，检查是否启用了登录启动、后台服务或自动重启机制。

Linux：区分 TCP 与 UDP

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'

# 已安装 lsof 时也可检查 TCP 监听
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss 中的 -t 查询 TCP，-u 查询 UDP，-p 显示进程信息。TCP 和 UDP 的端口空间分开：看到 UDP 7890 被使用，不能直接判定它就是 TCP 绑定失败的原因。应按日志中的协议分别检查。

如果 mihomo 由 systemd 管理，关闭桌面窗口未必会停止服务。服务单元确实命名为 mihomo.service 时，可用 systemctl status mihomo.service 查看状态，确认需要停用后再执行 sudo systemctl stop mihomo.service。若实际单元名不同，应以部署时的名称为准；否则可能误以为内核已经停止。

修改 mixed-port：以 7893 为例

先把前面的查询命令中的 7890 换成 7893，确认候选端口没有冲突。7893 并不保证在所有机器上都可用；它只是本次配置示例。改端口时应处理客户端最终加载的配置，而不只是编辑一份未启用的 YAML 文件。

1. 在客户端当前配置或运行设置中查找“混合端口”“Mixed Port”或 mixed-port。不同客户端的菜单名称不同，以实际字段为准。
2. 如果通过 YAML 管理，修改顶层字段，使用空格缩进，不要把端口写到 proxies 或 proxy-groups 内部。
3. 检查客户端是否另有端口覆盖设置。订阅配置、覆写配置和运行设置可能共同决定最终值。
4. 保存并应用配置；若客户端提示需要重启内核，完成重启后再检查日志和监听状态。

下列内容是端口相关片段，不是完整订阅配置。如果仍有应用需要独立的 SOCKS 入口，可以使用不同的端口：

# 合并到现有配置的顶层；保留其他代理、策略组和规则
mixed-port: 7893
socks-port: 7894
allow-lan: false

# 控制 API 与代理入口分开，已有认证设置保持不变
external-controller: 127.0.0.1:9090

只使用混合端口时，不必为了示例额外新增 socks-port。若原配置还启用了 port: 7890，仅修改 mixed-port 后，该独立 HTTP 入口仍可能继续报错，因此需要逐项检查所有监听字段。

同步系统代理、浏览器与终端

端口修改后，最常见的后续问题是内核已经监听 7893，应用却仍然向 7890 发送请求。此时重新导入订阅通常没有帮助，应该检查流量入口。

如果系统代理由客户端自动管理，可在应用新端口后关闭再开启一次客户端的“系统代理”开关，然后核对系统设置。通过 PAC 自动配置的环境应检查 PAC 返回的代理地址，修改手动代理栏不一定会影响 PAC 路径。

终端环境变量示例

在 macOS 或 Linux 的当前 shell 中，HTTP 代理可以这样设置。https_proxy 的值使用 http://，表示通过 HTTP 代理的 CONNECT 方法访问 HTTPS 站点，并不意味着目标网站改用明文：

export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893

# 需要 SOCKS5 且工具支持时，可单独使用：
export all_proxy=socks5h://127.0.0.1:7893

这些命令只影响当前 shell 及随后启动的子进程，不会自动更新已经运行的应用。若同时设置 HTTP 和 SOCKS 变量，具体优先级取决于工具；排查时优先显式指定代理，避免混合设置干扰结论。还应检查 HTTP_PROXY、HTTPS_PROXY 等大写变量以及 shell 启动文件中的旧值。

TUN 模式接管的是另一条流量路径，并不会自动消除本地代理入口的绑定冲突。应用可能经 TUN 正常联网，但 7890 监听仍然失败；也可能设置了错误的显式代理，连接尚未进入正常的转发路径就已失败。两种情况应分开验证。

验证修复：监听、请求与重启

1. 确认监听：再次查询 7893，确保 PID 属于预期的内核进程，同时检查日志中不再出现该入口的绑定错误。
2. 验证代理请求：使用显式代理参数发出一次请求，不先依赖系统代理或浏览器配置。
3. 验证日常应用：再打开浏览器和实际使用的工具，检查它们是否仍引用旧端口。
4. 验证持久性：重启客户端并更新一次订阅，确认端口没有被覆盖，另一个客户端也没有自动抢先启动。

以下命令通过新的混合端口发送 HTTP 代理请求。Windows 使用 curl.exe，可以避开部分 PowerShell 环境中同名命令别名的差异：

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

# Windows
curl.exe --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

收到 HTTP 响应说明这次请求已经得到回应，但不等于一定经过远端代理节点：在规则模式下，目标仍可能匹配直连规则。若出现 Failed to connect，优先检查本地监听与端口；若本地代理已经接受连接，随后出现上游超时或 TLS 错误，再检查节点、DNS、规则与网络环境，不要继续盲目更换本地端口。

常见剩余问题

• 退出后端口仍被占用：检查后台服务、其他用户会话以及客户端残留内核。
• 改完立刻恢复旧值：检查端口覆写功能和订阅更新行为，确认编辑的是当前启用配置。
• 端口空闲仍无法启动：区分权限、系统排除端口、无效绑定地址和 YAML 解析错误，按新的日志处理。
• 面板离线但网页正常：单独核对控制 API 的地址、端口与认证设置，不要把代理入口当成面板接口。

完成排查后，建议只保留一个负责日常代理的客户端自动启动，并记录“混合端口 7893、独立 SOCKS 端口是否启用、控制端口 9090”等实际配置。后续再次发生冲突时，从监听进程开始核查，通常比反复重装客户端更容易找到原因。字段的完整说明可继续查看配置大全，安装与首次启用流程见快速上手。