先读报错：冲突的是哪个监听入口
Clash 图形客户端能打开，但内核启动失败，日志出现 address already in use，通常意味着准备绑定的地址和端口已被其他监听器占用。先记录日志里的协议、地址和端口，再查进程；不要看到“启动失败”就重新导入订阅。
listen tcp 127.0.0.1:7890: bind: address already in use这是一条报错示例，不是实测记录。它指向本机 TCP 7890 端口，不能据此认定节点失效。Windows 上还可能出现“通常每个套接字地址只允许使用一次”等对应提示。若日志写的是 access denied 或“访问权限不允许”，还应检查端口保留范围与安全策略，不能直接按普通占用处理。
| 字段 | 用途 | 排查重点 |
|---|---|---|
mixed-port | 同一端口接收 HTTP 与 SOCKS 代理请求 | 例如 7890；同步检查系统代理和手动代理应用 |
port / socks-port | 分别提供 HTTP、SOCKS 代理入口 | 不能与其他已启用的监听器争用同一地址和端口 |
external-controller | 提供内核控制 API | 例如 127.0.0.1:9090；不是浏览器代理端口 |
dns.listen | 提供内核 DNS 监听入口 | 例如 127.0.0.1:1053；注意日志里的 TCP 或 UDP |
Windows：查监听 PID，再确认进程路径
使用 PowerShell 查 TCP 监听
右键开始菜单，打开“终端”或“Windows PowerShell”。先执行下面的命令；查询受限或需要读取其他用户进程信息时，再以管理员身份打开终端。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcessOwningProcess 是进程 ID。假设结果为 1234，继续查看进程名、路径与启动参数。这里的 1234 仅为说明用途，必须换成实际查询值。
Get-Process -Id 1234 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 1234" |
Select-Object ExecutablePath, CommandLine路径和启动参数比进程名更有用。两个不同客户端可能都启动名为 mihomo.exe 的内核；命令行中的配置路径能帮助判断它属于哪一个客户端。不要因为进程名里有 Clash 或 mihomo，就直接强制结束。
命令提示符的替代查法
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 1234"使用 netstat 时，要核对“本地地址”列的端口和 LISTENING 状态。findstr 只是文本筛选，可能同时匹配远端地址或更长的端口数字；TIME_WAIT 记录也不等于当前有进程正在监听。
没有监听结果，却仍提示无法绑定
先确认客户端是否在反复重启内核，导致查询时监听已经消失。如果日志属于访问权限错误，可在管理员终端检查 Windows 的 TCP 排除端口范围：
netsh interface ipv4 show excludedportrange protocol=tcp若目标端口落在排除范围内，优先换一个不在范围内的空闲端口。不要为此随意删除系统保留项；Hyper-V、容器或其他网络组件可能依赖这些设置。若报错明确指向 IPv6 地址，还需要检查对应的 IPv6 情况。
macOS 与 Linux：区分普通进程和后台服务
macOS：使用 lsof 查看监听者
打开“终端”，查询 TCP 7890 的监听进程。-nP 避免地址和端口被转换成名称，便于与日志逐项核对。
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
ps -p 1234 -o pid,ppid,user,command第一条命令返回的 PID 才是第二条命令要使用的数字。若发现另一个代理客户端仍驻留在菜单栏，先从它的菜单中正常退出，再重新查询。有些客户端关闭窗口后仍在运行，窗口消失并不代表内核已经停止。
Linux：使用 ss 检查套接字
sudo ss -ltnp 'sport = :7890'
ps -p 1234 -o pid,ppid,user,args-l 表示监听，-t 表示 TCP，-n 保留数字，-p 显示进程信息。若发行版未安装 ss，可以在已有 lsof 的环境中使用 macOS 部分的查询命令。
如果进程由 systemd 管理，直接杀进程可能触发自动重启。可以执行 systemctl status 1234 辅助定位所属服务，再对已确认的实际服务单元执行停止操作。用户级服务还需要使用 systemctl --user 查询；不要猜服务名后批量停用。
DNS 冲突要按 UDP 重新查
前面的命令只检查 TCP。如果日志指向 UDP 1053，应改用下列命令；检查其他端口时替换数字。一个端口号上的 TCP 与 UDP 是不同的传输协议，TCP 查询为空不能证明 UDP 也空闲。
# macOS，或已安装 lsof 的 Linux
sudo lsof -nP -iUDP:1053
# Linux
sudo ss -lunp 'sport = :1053'判断冲突来源：重复内核、其他软件或配置重叠
拿到进程路径后，再选择处理方式。端口占用本身通常不需要卸载软件，也不需要先修改节点协议、规则模式或订阅地址。
- 旧客户端仍在后台。例如一个客户端提供 7890 代理，另一个客户端启动时也申请 7890。保留当前要使用的客户端，正常退出另一个，并检查它是否配置了开机启动。
- 图形界面之外还有服务实例。手动运行的内核、系统服务或计划任务可能加载另一份配置。先辨认进程归属，再停止对应实例，避免停止后马上被服务管理器拉起。
- 端口属于其他必要程序。如果占用者有明确用途，保留它，给 Clash 换监听端口。不要为腾出端口而结束系统进程或未知服务。
- 同一配置启用了重叠监听。检查是否让
port、socks-port和mixed-port使用相同的地址与端口。混合入口已经能接收两类请求，不需要再为同一个端口叠加独立入口。
还要看绑定地址。127.0.0.1:7890 只面向本机回环接口，0.0.0.0:7890 则覆盖所有 IPv4 接口，两者可能发生冲突。IPv6 的 [::]:7890 是否同时覆盖 IPv4，与系统和套接字设置有关。不要把切换到全接口监听当作通用修复，它还会扩大代理入口的可达范围。
更换监听端口：修改真正生效的配置来源
先查 7897，再改 mixed-port
将前文查询命令中的 7890 换成 7897，确认当前没有冲突。如果需要长期保留两套客户端，应给每套客户端分配不同的代理入口；控制 API 等其他监听入口也要分别检查。
# 仅展示需要核对的字段，不是完整配置
mixed-port: 7897
allow-lan: false
mode: rule这段示例适用于仅供本机使用的混合代理入口。合并到现有 YAML 时应修改已有字段，不要在文件末尾重复追加第二个 mixed-port。如果原来还有独立的 port 或 socks-port，应根据实际用途停用或分配不同端口。不要把整份订阅替换为这三行，节点、策略组与规则仍需保留。
图形客户端设置与订阅文件谁优先
Clash 是内核与配置生态的统称，不同图形客户端的菜单和覆盖机制不同。先在当前客户端的“设置”中查找“端口”“混合端口”或“Mixed Port”，记录原值再修改；本文不把某一客户端的菜单路径当作所有版本通用的路径。
- 客户端提供端口设置：优先在该设置中修改，并按界面要求重启内核。它可能会覆盖订阅里的同名字段。
- 直接运行内核：修改启动参数指定的配置文件。确认编辑的是正在加载的文件，而不是另一份下载副本。
- 订阅自动更新：使用客户端提供的持久化覆写或合并功能。直接改下载后的订阅文件，更新时可能被覆盖。
保存后重启内核，再查看启动日志与实际监听结果。配置编辑器里显示 7897，不代表运行中的内核已经切换。若改完仍报 7890，占用排查之外还要检查设置优先级、配置路径和是否重启了正确实例。
若冲突的是 external-controller，只修改它对应的控制地址，例如从 127.0.0.1:9090 改为已确认空闲的 127.0.0.1:9097，并同步面板连接设置。控制 API 不应作为普通代理端口填写，也不应为了排错而暴露到公网。
改完端口后，哪些位置必须同步
内核在 7897 启动成功，但浏览器仍连接 7890，表现往往是“端口报错消失了，网页还是打不开”。这时应检查调用代理的应用，而不是继续更换节点。
| 使用位置 | 需要同步的内容 |
|---|---|
| 系统代理 | 确认端口已变为 7897；可通过客户端关闭后重新开启系统代理，再检查系统设置 |
| 浏览器代理扩展 | 更新手动配置的 HTTP 或 SOCKS 端口，地址通常仍为 127.0.0.1 |
| 终端环境变量 | 检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 及对应小写变量 |
| Git、下载器、开发工具 | 更新各自单独保存的代理地址，不要只改系统代理 |
| 局域网设备 | 原本使用电脑代理的手机或电视，需要同步电脑局域网地址对应的新端口 |
| 外部控制面板 | 仅在控制 API 端口变化时更新连接地址；与代理入口分开处理 |
Windows 11 可在“设置”→“网络和 Internet”→“代理”→“手动设置代理”检查地址与端口。macOS 可在“系统设置”→“网络”→当前网络连接的“详细信息”→“代理”检查。系统版本可能改变入口名称，客户端管理的设置也可能在启动时重新写入。
终端中的 HTTPS_PROXY=http://127.0.0.1:7897 表示通过 HTTP 代理访问 HTTPS 目标，并不要求本地代理入口本身使用 TLS。若应用使用 SOCKS，则要选择对应协议；例如 socks5h 通常表示由代理侧解析目标域名，具体支持情况以该应用为准。
TUN 模式通过虚拟网卡接管符合路由条件的流量，不等于所有应用都在使用 mixed-port。但应用里残留的手动代理仍可能把请求发往旧端口。TUN 能否启动、路由是否正确和代理监听端口冲突，是需要分别核对的问题。
复查结果：监听恢复，再验证实际请求
- 重新查看日志，确认原来的绑定错误不再重复出现，且没有新的控制 API 或 DNS 端口冲突。
- 查询新端口，确认监听进程属于当前使用的客户端，而不是另一份旧内核。
- 用显式指定代理的请求测试入口，排除系统代理尚未同步的影响。
- 再使用浏览器访问目标网站，查看客户端连接记录和规则命中情况。
# macOS / Linux
curl -I --proxy http://127.0.0.1:7897 --connect-timeout 5 --max-time 15 https://example.com
# Windows PowerShell：明确调用 curl.exe
curl.exe -I --proxy http://127.0.0.1:7897 --connect-timeout 5 --max-time 15 https://example.com这里的 example.com 是测试地址示例，可换成需要验证的网站。收到目标响应头说明这次请求已完成相应访问过程；若出现 Connection refused，优先查地址、端口与监听状态。若本地代理接受连接后出现超时、认证失败或上游连接错误，则转向节点、DNS、网络连通性与规则排查，不再把所有问题归为端口占用。
端口修复的完成标准是：目标内核稳定监听、系统及应用使用新端口、重启客户端或更新订阅后设置仍保留。按照“读日志 → 查进程 → 判断归属 → 修改生效来源 → 同步应用 → 验证请求”的顺序处理，通常能把端口冲突与其他网络故障清楚分开。后续配置可继续参考Clash 配置教程，常见连接现象可查看常见问题。