Clash 7890 端口被占用:查找占用进程与修改 mixed-port 的方法
用系统命令找出占用 7890 等端口的进程,判断该结束进程还是改端口,并说明修改 mixed-port 后系统代理与浏览器设置的同步方法。
先确认：是监听失败，还是代理地址填错
处理顺序是：查占用进程 → 决定退出旧实例或换端口 → 同步代理设置 → 验证监听与请求。不要一看到网页打不开就重装客户端。端口冲突发生在本机监听阶段，通常与订阅是否过期、节点延迟高低没有直接关系。
7890 是常见配置值，不是 Clash 或 mihomo 必须使用的端口。客户端可以把它用作 HTTP 代理端口，也可以用作混合端口，具体取决于当前生效的字段。先打开客户端的日志页面，找包含 listen、bind 和端口号的错误。
listen tcp 127.0.0.1:7890: bind: address already in use上面是典型错误片段，表示该地址上的 TCP 端口无法再次绑定。Windows 也可能显示“通常每个套接字地址只允许使用一次”。如果日志是 permission denied 或“访问权限不允许”，则还要检查端口保留、系统策略等限制，不能直接认定已有进程占用。
- 日志明确提示绑定失败：先执行下面的系统命令，找监听者。
- 内核正常监听，但浏览器提示代理连接失败：优先核对浏览器和系统代理是否还指向旧端口。
- 只有个别网站打不开：继续检查规则、DNS 和节点，不要反复更换本地端口。
Windows：用 PID 找出占用 7890 的程序
方法一：PowerShell 精确查询监听端口
在 Windows 10 或 Windows 11 打开 PowerShell，执行以下命令。查询结果为空时，表示本次查询未发现该 TCP 端口的监听者；若提示权限不足，再使用管理员终端。
Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess记录 OwningProcess 列的进程号。假设结果为 6420，再查看进程名称、路径和启动命令。这里的数字仅用于演示，实际操作必须使用本机查询到的 PID。
Get-Process -Id 6420 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6420" |
Select-Object ExecutablePath, CommandLine不要只看名称是否含有 Clash。桌面界面和内核经常是两个进程；同一个 mihomo.exe 也可能分别由托盘客户端、Windows 服务或手动命令启动。可执行文件路径与启动参数能帮助判断它究竟属于哪一份安装。
方法二：命令提示符查询
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6420"netstat 的结果需要人工核对：关注“本地地址”列端口恰好为 7890 且状态为 LISTENING 的行。远程地址带有 7890、状态为 ESTABLISHED，或者本地端口为 78901，都不是同一回事。
macOS 与 Linux：检查监听者和后台服务
macOS：使用 lsof 查看 TCP 监听
打开“终端”，查询监听 7890 的程序。普通用户权限下看不到完整信息时，再加 sudo。
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN结果中的 COMMAND 是程序名，PID 是进程号，NAME 是监听地址。退出托盘应用后重新运行一次。如果监听还在，可能存在独立运行的内核或后台服务，不代表刚才的退出操作完全没有效果。
Linux：使用 ss 查看端口和进程
sudo ss -ltnp 'sport = :7890'其中 -l 只看监听套接字，-t 只看 TCP，-n 保留数字端口，-p 显示关联进程。需要查询 UDP 时可另行执行下列命令；TCP 与 UDP 是不同的传输协议，不能仅凭 UDP 查询结果推断 TCP 已被占用。
sudo ss -lunp 'sport = :7890'若程序退出后又立即出现，检查是否由 systemd、用户服务或其他进程管理工具自动拉起。应先确认实际服务单元，再停止对应服务，而不是循环执行强制结束。容器部署还要检查宿主机的端口映射：两个容器各自监听内部 7890 可以共存，但不能同时把同一个宿主机地址的 7890 映射出去。
结束旧进程，还是把 mixed-port 改成 7891
判断依据是占用者是否仍然需要运行，不是“谁先启动谁就一定正确”。如果旧客户端只是重复启动，优先从托盘菜单退出它；如果是必须保留的其他代理或开发服务，则给当前 Clash 实例换一个端口。
| 发现的情况 | 建议操作 | 需要留意 |
|---|---|---|
| 旧客户端重复运行 | 正常退出旧客户端 | 检查开机启动是否重复 |
| 界面退出，服务仍在运行 | 确认后通过所属客户端或服务管理停止 | 服务可能自动重启内核 |
| 另一个必要程序监听 7890 | 将当前 mixed-port 改为 7891 | 先查询 7891 是否空闲 |
| 没有监听者，但仍提示禁止访问 | 检查端口保留和权限限制 | 不要盲目删除系统保留项 |
只有确认程序身份、保存必要工作后，才考虑结束进程。优先尝试程序自身的退出功能；命令行启动的内核可在对应终端按 Ctrl + C。Windows 的 taskkill /PID 6420 /F 属于强制结束，应作为普通退出失败后的手段，不要照抄示例 PID。
如果 Windows 没查到监听者，却持续出现访问权限错误，可以查看 TCP 排除端口范围。虚拟化或容器相关组件有时会影响可用端口，看到保留项后换用空闲端口通常比修改系统保留范围更稳妥。
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp修改 mixed-port：字段要改对，也要持久生效
mixed-port 在同一个监听端口接受 HTTP 与 SOCKS 代理连接。它不是订阅地址，不是节点服务器端口，也不是面板控制接口端口。若当前实际使用的是独立 port 或 socks-port，只修改 mixed-port 不一定改变原有入口。
先查询 7891 是否空闲，再备份当前配置。下面是可合并到配置文件顶层的片段，不是包含节点和规则的完整订阅配置。对于只供本机使用的代理，保留本地访问范围即可。
config.yaml：顶层监听字段
mixed-port: 7891
allow-lan: false
bind-address: 127.0.0.1- 保持顶层缩进：
mixed-port不要放进dns:、tun:或某个节点定义里。 - 替换已有键：不要在文件末尾再追加一份同名字段，重复键可能引发解析错误或不一致行为。
- 检查独立端口：如果仍有
port: 7890，原来的 HTTP 监听冲突可能继续存在。按实际需要修改或移除旧监听字段。 - 区分控制端口：
external-controller用于客户端或面板控制内核，不能当作浏览器 HTTP 代理入口。
为什么保存后又变回 7890
图形客户端可能通过全局端口设置、覆写配置或合并配置生成最终 YAML。订阅文件中的本地修改也可能被下一次更新覆盖。因此，优先使用客户端提供的持久端口设置或覆写机制；具体菜单名称随客户端版本而异，不能把某一款客户端的“设置”路径套用到所有 Clash 客户端。
修改后执行客户端提供的配置重载或内核重启，并检查日志是否报告新的监听地址。界面输入框显示 7891，只能证明设置已保存，不能证明内核已经成功绑定。更多字段含义可对照YAML 手册。
同步系统代理、浏览器和终端的旧端口
端口从 7890 改为 7891 后，内核只负责新入口，外部应用不会全部自动跟着变化。最常见的遗漏是内核已经正常启动，Windows 系统代理仍为 127.0.0.1:7890，于是所有遵循系统代理的浏览器都提示连接失败。
系统与浏览器检查位置
- Windows 11：「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「使用代理服务器」旁的「设置」，核对地址和端口。客户端管理系统代理时，通常应先关闭再开启客户端的“系统代理”，然后回到这里确认结果。
- macOS：「系统设置」→「网络」→ 当前网络连接的「详细信息」→「代理」，分别检查已启用的网页代理、安全网页代理或 SOCKS 代理。端口应与实际监听入口一致。
- Firefox：「设置」→「常规」→「网络设置」→「设置」。选择“使用系统代理设置”时跟随系统；选择“手动配置代理”时，需要单独修改端口。
- Chromium 类浏览器：通常跟随系统代理，但启动参数和代理扩展可能覆盖它。若只有一个浏览器异常，检查这些独立入口。
若使用自动代理配置脚本，即 PAC，还应检查脚本返回的 PROXY 127.0.0.1:7890 是否仍为旧值。HTTP 代理也可以承载 HTTPS 网站的 CONNECT 隧道，不要因为访问的是 HTTPS 网站，就把本地代理地址擅自改成 https://127.0.0.1:7891。
终端环境变量需要另行更新
终端程序可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，而不是桌面系统代理。PowerShell 当前会话可这样更新 HTTP 代理入口：
$env:HTTP_PROXY = "http://127.0.0.1:7891"
$env:HTTPS_PROXY = "http://127.0.0.1:7891"macOS 或 Linux 的常见 shell 可使用以下写法。若原先还设置了大小写不同的代理变量、ALL_PROXY 或工具自身配置，也要检查是否仍残留 7890；不同程序的优先级并不完全一致。
export http_proxy=http://127.0.0.1:7891
export https_proxy=http://127.0.0.1:7891最后验证：监听、请求与重启后三步检查
- 查新监听：把前面的查询命令中的 7890 换成 7891，确认监听进程属于当前客户端。旧端口若仍有监听，判断它是否为计划保留的程序。
- 显式指定代理发起请求：不要只依赖浏览器缓存页面，使用下面的命令确认请求能连接到新入口。
- 验证持久性：正常退出并重新启动客户端，再检查端口。订阅更新后也检查一次，确认持久覆写没有被覆盖。
Windows 使用 curl.exe 可避免部分 PowerShell 环境中 curl 别名的差异；macOS 和 Linux 直接使用 curl。
curl.exe --noproxy "" --proxy http://127.0.0.1:7891 --connect-timeout 5 --max-time 15 -I https://example.comcurl --noproxy "" --proxy http://127.0.0.1:7891 --connect-timeout 5 --max-time 15 -I https://example.com这里的 5 秒连接超时、15 秒总超时是测试上限，不是速度承诺。若提示无法连接 127.0.0.1:7891，继续检查监听与配置是否生效；如果已经建立代理隧道，随后才出现 TLS、上游连接或目标站响应错误，排查重点就应转向节点、规则或目标站。只看到 200 Connection established 也不等于完整请求已成功，还要看后续输出。
显式代理请求成功后，再取消命令中的代理参数，回到浏览器验证系统代理链路。修改本地入口端口不会自动改变规则模式的分流结果，也不会让节点变快。完成这一轮检查，就能区分“本机端口冲突已经解决”和“还有另一项网络故障”，避免把两类问题混在一起反复重装。其他连接问题可继续查看疑难解答。