先看日志：哪个监听地址启动失败
Clash 客户端提示“端口被占用”，通常意味着内核无法在指定地址建立监听。最常见的原因是另一个代理客户端还在后台运行，或者同一套客户端的服务进程与手动启动的内核重复运行。先不要重装，也不要直接结束所有名称里带 Clash 的进程；找到失败的端口和占用者，处理范围会小得多。
在客户端日志中查找 bind、listen、address already in use 等关键词。Windows 也可能出现“通常每个套接字地址只允许使用一次”的提示。下面是用于识别问题的日志示意，具体前缀会随内核版本变化：
listen tcp 127.0.0.1:7890: bind: address already in use这条信息指向本机回环地址上的 TCP 7890，而不是远端节点服务器的端口。修改订阅中的节点端口不能解决本机监听冲突。若日志显示的是 permission denied 或“访问权限不允许”，则还需要检查系统保留端口、权限和安全策略，不能直接认定有进程占用。
| 配置字段 | 用途 | 排查重点 |
|---|---|---|
mixed-port | 在同一入口接受 HTTP 与 SOCKS 代理请求 | 常见示例为 7890，以实际配置为准 |
port / socks-port | 分别提供 HTTP、SOCKS 代理入口 | 检查是否与混合入口重复指定同一监听地址和端口 |
external-controller | 提供控制 API，供界面或面板使用 | 常见示例为 127.0.0.1:9090，不是上网代理端口 |
dns.listen | 接收 DNS 查询 | 若冲突发生在 53 或自定义 DNS 端口，应另查 DNS 服务 |
端口冲突还与监听地址、传输协议有关。0.0.0.0:7890 表示监听所有 IPv4 接口，可能与 127.0.0.1:7890 冲突；IPv6 通配监听是否同时覆盖 IPv4，取决于系统和套接字设置。TCP 与 UDP 的同号端口不是同一个监听资源，排查时要对应日志中的协议。
Windows：用 PID 找到占用 7890 的程序
先查监听，再查进程名称
在 PowerShell 中运行下面的命令。第一条只筛选 TCP 7890 的监听项，第二条用于进一步核对程序路径。若查询结果示例中的 PID 为 6248，就把这个数字带入第二条；实际操作应使用本机返回的 PID。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 6248 | Select-Object Id, ProcessName, Path若习惯使用命令提示符，也可以使用系统自带的 netstat 和 tasklist：
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6248"findstr 是文本筛选，也可能匹配到远端端口或 78900 这样的数字，必须再核对“本地地址”列是否确实以 :7890 结尾，并确认状态为 LISTENING。只有 TIME_WAIT 的记录不能证明某个程序仍在监听；不要把连接记录都当成冲突来源。
- 占用者是另一个代理客户端：先从它的托盘菜单正常退出，再重新查询端口。
- 占用者是当前客户端的内核：检查是否已启用服务模式，又手动运行了一份内核。
- 进程退出后立即以新 PID 出现：打开“任务管理器”→“服务”，或运行
services.msc，核对是否有对应后台服务负责重启它。
查不到监听，但仍提示绑定失败
先确认报错确实是 7890，而不是 9090 或另一个地址。若 Windows 日志指向访问权限问题，可查看 TCP 排除端口范围：
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpHyper-V、容器和相关网络组件可能涉及端口预留。若目标端口落在排除范围内，通常更适合改用一个已确认可用的端口，而不是删除不明来源的系统预留。以管理员身份运行客户端并不必然解除此类限制。
macOS 与 Linux：区分桌面客户端和后台服务
macOS 使用 lsof
打开“应用程序”→“实用工具”→“终端”，查询 TCP 7890 的监听者。-nP 保留数字地址和端口，避免名称解析影响阅读；权限不足看不到完整结果时，再使用 sudo 查询。
lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 6248 -o pid,ppid,command查看输出中的 COMMAND 和 PID，再用第二条命令检查完整启动命令。有些客户端关闭窗口后仍驻留菜单栏，需要从菜单栏选择退出。如果程序随登录自动启动，可在“系统设置”→“通用”→“登录项与扩展”中核对；不同 macOS 版本的末级名称可能略有差异。
Linux 使用 ss
在 Linux 上，ss 可以同时查看监听地址和进程信息。以下两条分别检查 TCP 与 UDP，仅在日志或具体功能涉及 UDP 时才需要第二条。
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'
ps -p 6248 -o pid,ppid,args如果进程由 systemd 管理，仅结束进程可能触发自动重启。可先运行 systemctl status 6248，尝试从 PID 查找所属系统服务；用户级服务则检查 systemctl --user。确认真实单元名以后，再用相应的 stop 操作停止服务，不要假定所有安装方式都使用相同的服务名称。
在 Docker 或其他容器场景下，还要核对宿主机端口映射。容器内监听 7890 与宿主机发布 7890 是两层设置；冲突发生在宿主机时，只修改容器内部配置，未必会改变宿主机的占用情况。
修改 mixed-port：改运行配置，不只改订阅副本
如果占用程序必须保留，可以给 Clash 换一个代理入口。本文以把 7890 改成 7893 为例：7893 只是示例，不保证本机空闲，修改前应先用同样的命令查询它。
先确认客户端最终使用哪份配置
图形客户端往往由“订阅原文、覆写设置、客户端端口设置”共同生成运行配置。只修改下载下来的 YAML，可能在更新订阅后被覆盖，也可能根本不会作用于内核。客户端界面中的入口名称并不统一，应查找“端口”“混合端口”或“Mixed Port”，并优先使用客户端支持的持久设置或覆写机制。
- 图形客户端：记录当前端口值，在设置中修改混合端口，应用后重启内核，并查看启动日志确认最终监听地址。
- 直接运行内核：检查启动命令中的
-f配置文件参数及-d工作目录，编辑实际加载的文件。 - 服务或容器：检查服务启动参数、挂载路径和端口映射，避免改到另一份同名配置。
下面是适用于 mihomo 的顶层配置片段，不是一份完整订阅配置。应合并到现有配置，而不是替换整个文件；如果原来已有同名键，直接修改其值，不要追加重复键。
mixed-port: 7893
allow-lan: false
bind-address: 127.0.0.1mixed-port 同时接受 HTTP 与 SOCKS 请求，不代表它能与独立的 port 或 socks-port 在同一地址重复绑定。检查已有的独立入口，避免把它们也设为 7893。监听地址还可能受客户端生成逻辑影响，因此最终应以系统查询结果为准。
直接管理 mihomo 配置时，可以先做语法和配置检查。以下命令假定终端当前目录中已有真实的 config.yaml：
mihomo -t -f ./config.yaml检查通过不等于端口一定可绑定：配置检查与运行时建立监听是两回事。应用配置后，仍需要查看日志和端口状态。图形客户端也可能需要“重启内核”才能完整应用监听端口变化，不能只看输入框是否保存成功。
控制端口 9090 冲突：不要拿它替代代理端口
external-controller 是控制 API 的监听地址，客户端界面通过它读取连接、切换策略或修改运行状态。它不是 HTTP 上网代理。若冲突发生在 127.0.0.1:9090，单改 mixed-port 不会解决问题；反过来，把浏览器代理设置成 9090，也不能正常转发网页请求。
对于自行维护配置和控制面板的场景，可以在确认空闲后将控制地址改成下面的示例值：
external-controller: 127.0.0.1:9093修改后，要同步更新外部面板的控制地址，并保留原有的 secret 鉴权设置。若控制端口由图形客户端管理，应优先在客户端提供的设置中修改；仅覆写内核字段而不更新界面连接参数，可能出现“内核仍在转发，界面却显示未连接”的状态。
代理端口改完后，哪些设置必须同步
端口从 7890 改为 7893 后，所有仍指向旧入口的应用都会连接失败。客户端显示“内核运行中”，只能说明内核启动状态，不能证明浏览器、终端和其他工具已经换用新地址。
| 使用位置 | 需要同步的内容 |
|---|---|
| 系统代理 | 重新应用客户端的系统代理开关，核对地址是否变为 127.0.0.1:7893 |
| 浏览器代理扩展 | 手动配置的 HTTP 或 SOCKS 端口改为 7893；跟随系统设置的模式另行核对 |
| 终端环境变量 | 更新 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 及实际使用的小写变量 |
| 开发工具 | 检查 Git、包管理器和 IDE 各自保存的代理地址 |
| 局域网设备 | 若原本允许局域网连接，同步更新端口并检查防火墙；不要把 127.0.0.1 当作另一台设备的地址 |
Windows 11 可在“设置”→“网络和 Internet”→“代理”检查手动代理；macOS 可在“系统设置”→“网络”→当前网络连接的“详细信息”→“代理”检查。客户端重新设置系统代理后，也建议在系统页面确认实际值，避免已有工具再次覆盖。
终端只修改当前会话的示例
# macOS / Linux：当前 shell
export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893
# PowerShell：当前会话
$env:HTTP_PROXY = "http://127.0.0.1:7893"
$env:HTTPS_PROXY = "http://127.0.0.1:7893"这里的 HTTPS 代理变量仍使用 http://，表示通过本地 HTTP 代理的 CONNECT 机制访问 HTTPS 目标，并不是把目标网站降为 HTTP。如果原来用 SOCKS，可将支持它的应用指向 socks5h://127.0.0.1:7893；应用是否读取这些环境变量，需要分别确认。
TUN 模式通过虚拟网卡接管流量，和应用主动连接混合端口不是同一条入口路径。因此，TUN 下某个应用仍能上网，不能证明旧的 7890 代理设置已经修复；手动配置了代理的工具仍可能访问旧端口。
按三层验证：监听、代理请求、应用实际连接
- 验证监听者：重新查询 7893，确认存在预期内核的监听记录，且没有新的绑定失败日志。
- 验证代理协议：显式指定新端口发出一次请求，不依赖系统代理是否已更新。
- 验证常用应用：打开浏览器或开发工具，并在客户端连接列表中检查对应请求及规则命中情况。
# macOS / Linux
curl -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com
# Windows PowerShell：显式调用 curl.exe
curl.exe -I --connect-timeout 5 --max-time 15 --noproxy "" --proxy http://127.0.0.1:7893 https://example.com上述测试将连接超时设为 5 秒、总时长限制为 15 秒，并清空该次请求的代理绕过列表。若提示无法连接 127.0.0.1:7893，优先回查监听是否成功。若已经建立代理连接，随后出现 TLS 错误、上游超时或策略错误，排查重点就应转向节点、DNS 和规则，而不是继续换本地端口。
收到目标 HTTP 响应能够帮助确认请求链路，但不代表节点带宽、所有网站或所有应用均正常。某些站点也可能拒绝 HEAD 请求，应结合响应信息判断。测试时一次只改一个变量，保留修改前的端口记录，会比同时调整规则、DNS 和 TUN 更容易定位问题。
常见疑问：重启、双客户端与反复占用
电脑重启后恢复了，是否还需要排查？
如果只发生一次，可以先观察；若每次登录后复发，应核对自启动客户端和后台服务。重启可能暂时改变启动顺序，却没有消除两个程序竞争同一端口的原因。保留一次冲突时的 PID、程序路径和日志，比反复重启更有帮助。
两个 Clash 客户端能同时运行吗？
可以分配不同的代理端口和控制端口，但系统代理设置、TUN 路由和 DNS 接管仍可能互相影响。日常使用通常保留一个负责流量接管的客户端更容易维护。只更换 7890，并不能自动隔离两个客户端的所有系统级设置。
端口刚改好，更新订阅后又回到 7890，怎么办？
这通常说明修改发生在会被重新生成的配置层。检查客户端的端口设置或持久覆写功能，更新订阅后再查看最终运行配置与监听记录。不要仅凭订阅编辑器里显示的内容判断内核当前值。
处理这类故障的顺序可以保持固定：先读日志确认地址与协议，再找监听进程，随后决定退出重复实例还是调整端口，最后同步应用设置并测试。需要了解客户端的基础导入与接管流程，可查看Clash 使用指南；核对配置字段时，可参考协议与配置参考。