先看监听失败的是哪个端口

Clash 客户端启动时出现 address already in use，通常表示内核准备监听的本地地址与端口已被占用。这发生在本机建立代理入口的阶段，不等于订阅失效，也不能据此判断远端节点不可用。此时反复更新订阅或切换节点，通常不会解除本地端口冲突。

先打开客户端的日志页面，找到包含 listen、bind 或 in use 的完整错误行，记下地址、端口和协议。下面是错误格式示例，不是设备上的实际检测结果：

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

这里需要排查的是本机 TCP 7890。若日志显示的是 127.0.0.1:9090，应检查外部控制接口，而不是直接修改代理端口。0.0.0.0:7890 表示监听所有 IPv4 接口，可能与同端口的单地址监听冲突；看到 [::]:7890 时，还要结合系统的 IPv6 双栈行为判断。

配置字段 用途 修改后的同步位置
mixed-port 在同一端口提供 HTTP 与 SOCKS 代理入口 系统代理、浏览器代理及命令行代理变量
port 独立的 HTTP 代理入口 使用该入口的 HTTP 代理设置
socks-port 独立的 SOCKS 代理入口 应用内 SOCKS 代理设置
external-controller 供客户端或面板访问的控制 API 客户端或面板的控制接口连接设置

Windows：用 netstat 找到占用进程

核对本地地址、监听状态与 PID

打开 Windows 终端或命令提示符，执行以下命令。普通权限通常可以查看连接；读取部分进程信息或执行服务管理操作时，可能需要管理员权限。

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

输出各列依次包含协议、本地地址、外部地址、状态与 PID。必须检查本地地址这一列，并确认端口确实为 7890；文本过滤也可能匹配到外部地址或更长的端口数字。对于 TCP 代理入口，重点看状态为 LISTENING 的行，而不是只看到某行含有 7890 就结束进程。

也可以在 PowerShell 中使用精确端口筛选，减少人工辨认：

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

假设查询结果中的 PID 为 4321，再执行下面的命令查看程序名称。这里的 4321 仅演示命令格式，操作时应换成刚查到的实际 PID。

tasklist /FI "PID eq 4321"

确认进程来源，再决定退出还是保留

  • 另一个代理客户端：从它的托盘菜单正常退出，再重新查询端口。只关闭窗口可能仍会留在后台。
  • 当前客户端的旧内核：先退出客户端，再通过任务管理器核对残留进程的路径与命令行。确认是残留内核后再结束。
  • 服务模式启动的内核：窗口退出后服务可能仍在运行。使用该客户端提供的服务管理入口停止对应服务，避免结束后立即被重新拉起。
  • 其他仍需使用的程序：保留该程序，为 Clash 选择另一个空闲端口，不要为了释放端口盲目停用系统服务。

可在任务管理器的「详细信息」页核对 PID，并通过列标题右键的「选择列」显示命令行。如果占用者是系统进程，不能只凭端口号强制结束；应继续查明关联服务或改用其他端口。

macOS 与 Linux：用 lsof 或 ss 核对监听者

macOS 可在「终端」执行下面的命令。-nP 保留数字地址和端口，-sTCP:LISTEN 将结果限制为 TCP 监听套接字：

lsof -nP -iTCP:7890 -sTCP:LISTEN

重点看 COMMAND、PID 和 NAME。如果怀疑监听进程属于其他用户，而普通查询没有显示完整信息，可以在有相应权限时加 sudo 重试。Linux 如果没有安装 lsof，可使用通常由 iproute2 提供的 ss：

sudo ss -ltnp 'sport = :7890'

需要进一步确认进程的启动命令时，可根据实际 PID 查询：

ps -p 4321 -o pid,ppid,command

先通过应用菜单或服务管理方式正常停止占用者。如果确认是失去管理界面的残留进程，可发送正常终止信号，例如 kill -TERM 4321。不要直接把强制终止作为第一步：它无法解释进程为何重复出现，也可能跳过正常清理。

修改 mixed-port：先确认哪一层配置生效

确认 7890 被其他必要程序占用后，可以改用 7892，但必须先用前面的命令检查 7892 是否空闲。换一个数字只是选择新的监听入口，并不会自动修正浏览器、终端或控制面板的连接设置。

对于 Clash Meta（mihomo）类内核，下面是一个局部配置示例。它不是包含节点与规则的完整配置，应合并到现有配置中，保留原来的订阅、策略组、规则与访问认证设置。

mixed-port: 7892
allow-lan: false
external-controller: 127.0.0.1:9090

这个例子只将混合代理入口改为 7892，并保留控制接口 9090。若日志没有显示控制端口冲突，就没有必要同时改动它。allow-lan: false 用于限制局域网访问；个人设备只需本机使用时，不应为了处理端口占用而把监听范围扩大到整个网络。

图形客户端的端口设置可能覆盖订阅文件

  1. 记录当前代理端口、控制端口和正在使用的配置名称，并保存可恢复的配置副本。
  2. 检查客户端设置中是否有「混合端口」「代理端口」或「内核设置」等项目。不同客户端菜单不同，应优先使用其管理全局监听参数的入口。
  3. 如果客户端支持覆写或合并配置，把本地监听参数放在它实际支持的持久化层中。不要假定任意订阅文件都会接受同样的覆写机制。
  4. 应用更改并重新加载或重启内核，再检查日志。端口监听变更是否需要重启，由客户端与内核的实际行为决定。

直接修改下载后的订阅 YAML，可能在下次更新时被覆盖。反过来，修改了订阅文件也可能没有效果，因为客户端在启动时又用界面设置覆盖了同名字段。最终判断依据是生效配置、内核日志与系统监听结果，不是编辑器中已经保存的那一行。

同时检查是否还启用了独立的 port 或 socks-port。不要让它们与 mixed-port 使用同一监听地址和端口，也不要在 YAML 顶层重复写两个 mixed-port；重复键可能导致解析错误或不明确的覆盖结果。

控制端口冲突：单独调整 external-controller

如果错误发生在 9090，而代理入口 7890 已正常监听，问题在控制 API。表现可能是图形界面无法读取连接、切换策略失败，或面板显示内核断开；某些客户端也可能因此报告启动失败。此时应先检查 9090 的占用者，再决定是否改成空闲的 9091。

external-controller: 127.0.0.1:9091

更改后，独立面板需要连接新的控制地址；图形客户端若自行管理控制接口，应在对应设置中修改，让界面与内核保持一致。仅编辑内核文件而不调整界面连接参数，可能出现代理能用、界面仍连不上的情况。已有的 secret 认证应保留，并同步给需要访问接口的面板，不要为排错而取消认证。

不要将控制接口改为 0.0.0.0:9091 来尝试解决冲突。这会扩大接口暴露范围，而且不能保证避开已有监听。控制接口与混合代理接口是两项独立配置，只修改发生冲突的部分，通常更容易验证和回退。

同步系统代理与应用代理，避免继续连接旧端口

将混合端口改为 7892 后，仍指向 127.0.0.1:7890 的应用会继续失败。图形客户端通常能在启用系统代理时写入新值，但是否自动更新取决于客户端实现。建议先应用新端口，再关闭并重新开启一次系统代理，随后检查系统显示的实际地址。

  • Windows 11：打开「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「使用代理服务器」的「设置」，核对地址与端口。若使用的是自动配置脚本，还要核对脚本所提供的代理地址。
  • macOS 13 及后续版本：打开「系统设置」→「网络」→当前连接→「详细信息」→「代理」，检查网页代理（HTTP）、安全网页代理（HTTPS）及 SOCKS 代理中实际启用的项目。
  • Firefox：检查「设置」→「常规」→「网络设置」→「设置」。独立的手动代理不会因为操作系统代理改变而自动同步。
  • 终端与开发工具：检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，以及 Git、编辑器和容器内单独配置的代理地址。

混合端口可接收 HTTP 与 SOCKS 请求，但应用侧仍要选对协议。例如，HTTP 代理地址可写为 http://127.0.0.1:7892；需要由 SOCKS 代理解析域名时，可在支持该写法的工具中使用 socks5h://127.0.0.1:7892。HTTPS 网站经 HTTP 代理建立隧道，并不意味着本地代理地址必须写成 https://。

TUN 模式通过虚拟网络接口接管流量，不等同于系统 HTTP 代理。某些 TUN 场景下浏览器还能访问，并不能证明旧的 7890 配置已修好；反过来，普通混合端口冲突也不要求卸载 TUN 设备。验证代理入口时应显式指定新端口，减少路径混淆。

验证修复结果与重启后的持久性

先验证监听，再验证一次真实请求

重新查询 7892，确认它由预期的内核进程监听，并检查日志中是否仍出现绑定失败。随后用 curl 显式连接新入口；Windows PowerShell 下使用 curl.exe，可避开部分环境中同名命令别名的影响。

curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7892 https://example.com/

macOS 或 Linux 使用同样参数，将命令名换成 curl。这里的 5 秒与 15 秒分别是连接阶段和整次请求的超时上限，不是测速结果。示例假设本地代理未启用认证；若配置了认证，需要按现有方案提供凭据，避免把密码粘贴到公开日志中。

  • 本地连接被拒绝：优先检查新端口是否监听、地址是否一致、内核是否已退出。
  • 请求进入内核但出站超时：结合连接记录核对规则命中、节点和 DNS；端口监听恢复不代表后续链路一定正常。
  • curl 成功但浏览器失败：检查浏览器的独立代理、代理扩展、自动配置脚本及旧连接，不必立即再次改端口。
  • 浏览器正常但面板失败：回查控制接口地址与认证，不要把控制接口错误当作代理入口故障。

退出重开后再检查一次

完成测试后，正常退出并重新启动客户端，确认监听端口仍是 7892；若问题常在开机后出现，再检查登录启动项和服务模式。只保留确实需要的自动启动入口，避免旧客户端与新客户端同时争抢同一个端口。

如果 TCP 查询没有监听者却仍无法绑定，先重新确认日志时间、地址与协议。Windows 中，address already in use 与 access permissions 指向的排查方向不同；后者还可能涉及保留端口或安全策略。可用下面的命令查看 TCP 排除端口范围，但不要直接删除系统保留项：

netsh interface ipv4 show excludedportrange protocol=tcp

最终应同时满足四项：内核成功监听预期端口、系统与应用指向新入口、控制界面能够连接、重启后配置仍然保留。若需要回退，先确认原端口已经释放，再恢复原设置并同步系统代理。准备暂时退出客户端时，也应关闭由它设置的系统代理，避免系统继续向已经停止的本地端口发送请求。