现象：address already in use 在说什么

操作系统里，同一网卡、同一地址族、同一端口号上只能有一个程序在「监听」时处于占用状态。Clash 启动时要绑定你在配置里写的 mixed-port、或分开写的 port（HTTP）与 socks-port、以及 redir-port / TUN 相关端口（视内核与系统而定）。若该端口已被旧 Clash 进程、其它 Clash 发行版、公司 VPN 组件、本机 Fiddler/Charles 类工具或脚本化的本地服务占用，内核就会报 address already in use，表现即无法启动、面板打不开、或反复重启。

和「能启动但连不上外网、TLS 失败」类问题不同，这类错误发生在监听阶段，与节点质量无直接关系。若你刚在某篇教程里把 mixed-port 改成与另一个常驻代理相同，也极易撞车；可对照 Docker 与终端里 mixed-port、环境变量与 NO_PROXY 的配合 ，理清「一个端口、多处引用」时的维护面。

ℹ 建议顺序：（1）在日志里抄下端口号与协议名；（2）用系统工具查 PID；（3）判断是关旧 Clash/其它软件，还是整段改端口；（4）改完后同步系统代理、终端、WSL/容器、IDE里写死的 7890/7891 等数字。

先锁定 Clash 要绑定的端口

在 Clash / Mihomo 配置中，mixed-port 为常见的二合一入站（同时承载 HTTP 与 SOCKS5 语义，以客户端与内核版本为准），很多图形客户端的「系统代理」或「入站」设置也会与之联动。另有一组常见字段：port 单独 HTTP、socks-port 单独 SOCKS；external-controller 则用于网页控制台与 REST API，若与别的软件冲突，表现为面板上不去但 mixed 可能已起来——两者要分开排查。若你使用 external-controller 与 Yacd 等网页面板 ，记得日志里同时核对 API 口是否可绑定。Windows 上首次用图形版可把 Clash Verge Rev 在 Windows 11 的界面与 TUN 开关 和本文对照，避免在设置页改了一个端口、YAML 里仍是旧值、或需「重载」才生效的错位。

若你开启了 allow-lan 从局域网设备访问，占用仍发生在本机 bind 那一步，思路不变：先本机 查 PID，再决定关进程或换端口。

Windows 11：用 netstat 与 Get-NetTCPConnection 查 PID

以「7890 被谁占用」为例。打开「终端」或 PowerShell，执行：

PowerShell & cmd — list listener PID 
netstat -ano | findstr :7890

输出最后一列为 PID。再用任务管理器「详细信息」或 tasklist | findstr <PID> 看进程名。若确认是旧的 clash/clash-verge 等，可先在托盘完全退出该客户端，再重试；若杀进程后它又被服务拉起，要检查是否装了多份代理或自启项。

PowerShell 上也可用：

PowerShell — Get-NetTCPConnection 
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess,State

OwningProcess 即 PID。需要结束进程时，优先用应用自己的退出；不得已再用「结束任务」并确认不会误伤系统关键进程。

若你同时使用 WSL2 并把流量指回 Windows 上的 Clash，宿主机端口若被别的东西占用，WSL 侧会表现为「环回/代理全挂」；完整拓扑与 WSL2 与 Windows 宿主机 mixed-port 的配合 可单独开一篇对照。此处只要记住：宿主机先能 bind 成功，WSL 里的代理环境变量才有意义。

macOS：用 lsof 查监听与进程

在「终端」中执行（仍假设端口 7890）：

macOS — lsof 
lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iUDP:7890

第一列 COMMAND、第二列 PID 即为占用者。若看到上一个 Clash 没退出干净，可在「活动监视器」中结束相应进程，或在菜单栏用客户端的彻底退出再启动。与 TUN、系统代理同时存在时，冲突有时表现为「能 ping、网页异常」，TUN/扩展细节可与 macOS 上 TUN 与系统扩展、系统代理的排查 一起读；但 端口占用 仍应以 lsof 结论为准，不要把所有启动失败都归因为扩展未授权。

若你使用 沙盒/签名版 客户端，更新或重装后可能短暂存在双进程，表现为同一端口被「同名不同路径」的实例争抢，可重启会话或只保留一个安装来源。

改 mixed-port 与 external-controller 的推荐顺序

当不方便结束占用进程时（例如公司统一装的本地服务），改 Clash 的入站端口 往往最省事。在配置中把 mixed-port 改为未占用的数（如 7892），若单独配置了 port / socks-port 也要一并改并避免互相冲突。API 用 external-controller: 127.0.0.1:#### 时，若 9090 等常见口被占，可改为 127.0.0.1 上其它空闲口，与 网页面板与 secret 文档中的绑定建议一致。

改完后在客户端执行重载/重启内核，并看日志中是否已出现 listening 或等价成功信息。若你同时用 Merge/覆写，注意个别 GUI 以界面为准覆盖 YAML 中的入口端口，避免「文件里改了 7892、UI 里仍 7890」的二次冲突。

改端口后必须同步的地方：系统代理、环境变量、其它工具

只改 Clash 配置、不改系统代理，浏览器会仍去连旧端口，表现像「代理坏了」。在 Windows「代理」设置、macOS「网络 - 代理」或第三方开关里，把 HTTP/HTTPS 与 SOCKS 的地址端口改成新 mixed-port 对应项。终端里若设过 ALL_PROXY、HTTP(S)_PROXY，也要与 ALL_PROXY/NO_PROXY 与 Docker/CLI 一篇 的写法一起更新；IDE、Git、npm、pnpm 里写死的 7890 同样要手改或改用脚本从环境读取。

与「退出 Clash 后系统仍指向代理而断网」不同，那是残留代理或 TUN 未清理，处理步骤见 退出后断网、清理系统代理与 TUN ；而本文场景是 进程占端口导致本端根本未监听，两者症状相似（都上不了网），根因不同，不要混用同一套仅清代理的操作。

验证：本机与浏览器是否仍走代理

端口与系统代理都改对之后，在终端对某一 HTTPS 站探测（请替换为可访问的测试 URL）：

curl through proxy (example) 
curl -x http://127.0.0.1:<NEW_PORT> -I https://www.example.com

能返回 200/301 等头则入站与转发链路基本通。再打开 Clash 的连接日志，访问网页时应能看到对应连接；若只有 timeout/TLS 问题，再转向 连接日志与 TLS 文 的分层法。这样可以把「端口 → 本机入站 → 节点与规则」拆清楚，少在错误层级上调参。

和「关闭 Clash 后断网」不是一回事

再强调一次：本文解决「起不来/绑定失败」；若 Clash 能启动、退出后本机却上不了网，多半是系统级代理、PAC 或 TUN 未恢复，与端口抢占无关。上段给出的「断网专文」按步骤做即可。若你遇到的是「能启动、订阅拉不下来」，应回到「404/403、UA、缓存」路径。

⚠ 企业环境：若 443/常用端口或本地策略禁止自建监听，可能并非单纯 Clash 配置问题。请先确认有权在本机开代理，再与文档中的命令，避免与合规/安全要求冲突。

结语

Clash 端口占用 类问题在社群提问里极常见，但落点往往就两件事：找出占用 PID 的进程后关掉冲突源，或 把 mixed-port 与整链路引用统一切到新端口。和订阅内容、规则算法相比，它更「底层」、更好验证——netstat / lsof 一锤定音。保持配置里入口端口、系统代理、开发工具与 WSL/容器环境变量 同名同号，你就不需要每次重装系统后再猜 7890 从哪来。

相比需要反复试节点的场景，把监听端口、API 口、系统代理、终端代理四者的数字对齐，通常一次到位；在稳定性与可复现上，这是规则代理里最容易被忽视、却最省时间的一环。

→ 立即免费下载 Clash，开启流畅上网新体验，用同一套可验证步骤处理 mixed-port 冲突，让客户端先稳定站住监听，再去折腾分流与策略。