先看报错：是端口占用，还是监听权限问题

Clash 界面能够打开，不代表代理内核已经正常监听。日志出现 listen tcp 127.0.0.1:7890: bind，并伴随“通常每个套接字地址只允许使用一次”或 Only one usage of each socket address，通常表示同一监听地址与端口已有进程使用。此时反复点击系统代理开关，不能释放端口。

7890 是常见的本地代理端口，不是所有客户端都必须使用的固定值。实际端口以当前生效配置和内核日志为准。HTTP 端口、SOCKS 端口、混合端口以及控制接口端口用途不同，不能看到数字相近就互相替换。

日志或现象优先检查
地址已被使用、Only one usage查监听进程，确认是否同时运行了两个内核。
访问权限不允许、forbidden by its access permissions检查 Windows 排除端口范围、系统策略和安全软件限制。
内核监听正常，但浏览器连接被拒绝检查浏览器或系统代理是否仍指向旧端口。
日志报错的是 9090 等其他端口按日志中的实际端口排查，不要只修改 mixed-port。

用 netstat 查找 7890 的监听进程

第一步：筛选 TCP 监听记录

打开 Windows 终端中的 PowerShell 或命令提示符，执行下面的命令。普通权限通常就能查看监听端口；遇到权限提示时，再以管理员身份打开终端。

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

-a 显示连接与监听端口，-n 用数字显示地址，-o 显示 PID。筛选字符串中，7890 后面保留了一个空格，可以避免把 78900 一类端口也算进去。以下是格式示例，最后一列的 12480 仅用于演示：

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    12480
  • 127.0.0.1:7890 表示只在 IPv4 回环地址监听。
  • 0.0.0.0:7890 表示监听所有 IPv4 本地地址，可能与回环地址上的监听发生冲突。
  • [::]:7890 是 IPv6 通配监听，需要结合实际套接字设置判断冲突。
  • 同一 PID 出现多行，不一定是多个程序，可能是同一个进程监听多个地址。

第二步：根据 PID 核对程序身份

按 Ctrl + Shift + Esc 打开任务管理器，进入「详细信息」，按 PID 找到对应进程。若看不到 PID，可在列标题处右键选择显示该列。对目标进程使用「打开文件所在的位置」，确认它属于哪个客户端或服务。

tasklist /FI "PID eq 12480"

执行时，把命令中的示例数字换成刚才查到的真实 PID。常见原因是旧客户端仍驻留在托盘、另一个客户端已经启动，或者服务模式运行的内核尚未退出。不要只凭进程名含有 Clash 或 mihomo 就结束它，先确认路径和所属客户端。

PowerShell 的替代查法

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

输出中的 OwningProcess 就是 PID。命令没有返回监听记录时，应结合当时的日志再判断；短暂启动后退出的内核，可能在查询前已经释放端口。

处理冲突：退出重复客户端，或改用空闲端口

如果占用者是另一个不再使用的客户端，优先从它的托盘菜单正常退出。若它启用了独立服务，关闭窗口可能只隐藏界面，不会停止服务内核；应在该客户端的服务管理入口停止对应服务，再查询一次端口。

  1. 记录原有系统代理地址与端口，临时关闭系统代理，避免排查期间应用继续访问失效入口。
  2. 正常退出重复客户端，必要时通过 services.msc 核对其对应服务。
  3. 再次运行 netstat，确认旧监听已经消失。
  4. 启动需要保留的客户端，查看日志是否成功监听 7890。

如果占用者是必须保留的程序，不必强行结束它。给 Clash 换一个空闲端口通常更直接。本文以 7897 为例，但这个数字并不保证在每台电脑上都可用，修改前先检查：

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "

修改 mixed-port：改的是本地代理入口

mixed-port 让同一个本地监听端口接受 HTTP 和 SOCKS 代理连接。它不是节点服务器端口，也不是订阅链接端口。配置中代理节点的 port 属于远端连接参数，不能用来解决本机 7890 的监听冲突。

先确认客户端实际使用哪一份配置

不同客户端对端口设置的入口和保存方式不同。先在设置中查找「端口」「混合端口」或 mixed-port；如果有图形化入口，优先在那里修改。使用 mihomo 内核的客户端还可能通过覆写、合并配置或运行时配置管理端口，直接编辑订阅缓存文件，下一次更新时可能被覆盖。

需要编辑 YAML 时，先备份原文件，再把生效配置中已有的 mixed-port 修改为目标值。下面只展示需要调整的字段，不是完整配置文件，不能用它覆盖整份订阅：

mixed-port: 7897
  • 字段放在 YAML 顶层，不放进 proxies、proxy-groups 或 rules 列表。
  • 同一份最终配置不要出现重复的 mixed-port 键。
  • 若还启用了 port: 7890 或 socks-port: 7890，旧端口冲突仍可能存在，需分别检查这些独立监听。
  • external-controller 是客户端管理内核的控制接口，不应被当作浏览器代理端口。

重载后用监听结果确认生效

保存后使用客户端提供的重载配置或重启内核功能。只保存文件而不重载，旧进程可能仍在使用原端口。随后查看日志，并再次查询 7897：应当能看到目标内核的 PID 正在监听。若界面显示 7897、日志却还是 7890，优先检查配置是否被覆写，以及当前启用的配置是否就是刚才修改的那份。

同步 Windows 系统代理与应用内代理

端口修改成功后，系统代理不会在所有客户端中自动同步。如果内核监听的是 7897，而 Windows 仍然指向 127.0.0.1:7890，浏览器就可能报代理连接失败。应在新端口监听成功后，重新开启客户端的系统代理功能，再检查 Windows 保存的地址。

  1. Windows 11：进入「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「使用代理服务器」旁的「设置」。
  2. Windows 10：进入「设置」→「网络和 Internet」→「代理」，检查手动代理设置。
  3. 地址使用 127.0.0.1，端口应与当前混合端口一致，本例为 7897。若使用代理脚本，则还需核对脚本实际返回的代理入口。

Firefox、开发工具、Git 和终端环境变量可能有独立代理配置，不一定跟随 Windows。终端中可以先查看当前会话的代理变量：

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

如果结果仍指向 7890，需要同步修改对应应用或变量。只修改当前 PowerShell 会话，可以使用下面两行；这不会自动更新已经打开的其他终端，也不会修改所有程序的设置。

$env:HTTP_PROXY = 'http://127.0.0.1:7897'
$env:HTTPS_PROXY = 'http://127.0.0.1:7897'

HTTPS_PROXY 中使用 http:// 表示通过本地 HTTP 代理建立隧道，并不是把目标 HTTPS 网站降级为 HTTP。排查时也不要随意执行 WinHTTP 重置命令：WinHTTP 代理与浏览器常用的 Windows 用户代理设置不是同一个配置入口。

端口没有监听进程，却仍然无法绑定

如果 netstat 查不到占用者，日志却提示“访问权限不允许”，可以在管理员终端查看 Windows 的 TCP 排除端口范围。Hyper-V、WSL、容器或其他网络组件可能影响这些保留范围，但不能只凭安装过某项功能就认定原因。

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

检查 7890 或准备使用的 7897 是否位于输出的起始端口与结束端口之间。如果命中，优先选择一个不在范围内、也没有被监听的端口。不要为了释放单个代理端口直接删除系统保留范围，这可能影响虚拟网络服务。

注意日志中的协议与地址

本文主要排查 TCP 代理监听。若报错明确写着 UDP，应检查对应的 UDP 端点，而不是只查 TCP 的 LISTENING。UDP 输出没有同样的监听状态列，可以这样查看：

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

若日志显示绑定的是一个已经不存在的局域网地址，还需检查 bind-address。只供本机使用时，不要为了绕过报错随意开放局域网访问；启用 allow-lan 会改变可访问范围，与解决本地端口冲突不是同一件事。

验证恢复：监听、入口、出口分别检查

看到网页重新打开，还不足以判断所有设置都已同步。建议按下面三层检查，能更快区分端口问题、代理规则问题和节点连接问题。

  1. 确认监听：查询 7897，核对 PID 属于目标客户端的内核，日志不再出现绑定失败。
  2. 确认入口：用显式指定代理的请求绕开系统代理设置，测试本地入口。
  3. 确认出口：在客户端连接记录中检查该请求匹配的规则、策略组与实际出口，确认是否符合预期。
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7897 https://www.microsoft.com/

上面的命令显式连接本地 HTTP 代理。若立即提示无法连接 127.0.0.1:7897，继续检查监听和端口；若已建立代理连接但目标请求超时，则应转向节点可用性、DNS、规则或远端网络排查。收到 HTTP 响应也不等于请求一定通过了代理节点：Rule 模式仍可能让目标直连，具体以连接记录为准。

最后重新打开浏览器和需要代理的应用，再重启一次客户端，确认端口设置能保留。若每次重启或更新订阅后又变回 7890，应修正客户端的持久化设置或覆写配置，而不是反复手动修改临时文件。TUN 模式也不是释放端口的工具；即使部分流量已被虚拟网卡接管，失效的本地 HTTP 代理入口仍需单独修复。