Clash 端口被占用怎么处理：进程定位与端口修改

先确认报错是否属于端口冲突

Clash 启动内核时，需要在本机地址上建立一个或多个监听端口。浏览器、系统代理或其他应用把请求送到这些端口，内核再按代理组和规则处理流量。如果同一网络协议、同一监听地址与同一端口已经被另一个进程占用，新的监听通常会失败。

常见表现包括：客户端界面能够打开，但内核立即停止；系统代理按钮可以切换，网页却无法访问；日志出现 address already in use、bind、listen tcp 或“端口已被占用”等信息。部分图形客户端会反复尝试启动内核，因此日志中可能连续出现相同错误。

不要仅凭“无法联网”就直接修改端口。配置解析错误、订阅内容失效、代理节点不可用、系统代理没有启用，以及防火墙限制，都可能产生相似现象。判断端口冲突时，应先找到日志里的具体地址，例如 127.0.0.1:7890、0.0.0.0:7890 或 :9090。冒号后的数字才是需要检查的端口。

端口冲突与权限错误的区别

“地址已被使用”通常指已有监听者；“权限不足”或 permission denied 则不一定是端口被占用。低位端口、系统保留端口、安全软件策略或操作系统的端口排除范围，都可能阻止绑定。日常配置建议从未被占用的高位端口中选择，并避免随意使用常见服务端口。

分清 mixed-port、port 与 socks-port

处理冲突前，应先确认报错对应哪个配置字段。不同字段面向不同协议，修改后需要同步的应用也不同。Clash 与 mihomo 常见监听项如下。

桌面客户端最常见的冲突是 mixed-port。例如客户端甲仍在后台占用 7890，客户端乙也尝试使用 7890，后启动的内核就无法建立监听。另一个容易忽略的情况是代理端口正常，但 external-controller 使用的 9090 被占用，结果表现为图形界面无法连接内核或无法读取运行状态。

不要同时保留用途重叠且端口数字相同的字段。例如把 mixed-port 与 port 都设为 7890，会让同一个内核内部发生绑定竞争。若主要使用普通桌面系统代理，保留一个 mixed-port 通常更容易维护；只有明确需要分离 HTTP 与 SOCKS5 入口时，才分别设置 port 和 socks-port。

在 Windows、macOS 与 Linux 定位监听进程

日志确定端口后，下一步是查出谁正在监听。检查时应先完全退出当前 Clash 客户端，等待数秒，再执行命令。如果端口仍处于监听状态，说明占用者可能是另一套代理客户端、残留内核进程、开发服务器、容器映射或系统服务。

Windows：从端口找到 PID

在命令提示符中检查 TCP 端口 7890：

netstat -ano | findstr :7890

结果末列是 PID。重点查看状态为 LISTENING 的记录，再用 PID 查询程序名称：

tasklist /FI "PID eq 1234"

PowerShell 也可以直接列出拥有该监听端口的进程：

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

Get-Process -Id 1234

如果命令提示权限不足，可使用具备相应权限的终端重试。看到多个记录时，要比较本地地址。有些程序分别监听 IPv4 与 IPv6，任务管理器中看起来只有一个进程，但命令会展示两条监听记录。

macOS：使用 lsof 查看监听者

lsof -nP -iTCP:7890 -sTCP:LISTEN

输出中的 COMMAND 是进程名称，PID 是进程编号。如果普通权限无法显示完整信息，可在确认命令内容后使用：

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

macOS 上关闭窗口不一定等于退出客户端。应检查菜单栏状态项，并通过客户端的退出命令结束主程序。若主程序退出后内核进程仍存在，再根据 PID 和程序路径判断它属于哪一套客户端。

Linux：同时核对 TCP 与 UDP

sudo ss -ltnp | grep ':7890 '
sudo ss -lunp | grep ':7890 '

第一条检查 TCP，第二条检查 UDP。普通 HTTP、SOCKS5 与控制接口主要关注 TCP；DNS 监听和部分透明代理场景还应检查 UDP。若系统提供 lsof，也可以使用与 macOS 相近的命令。

决定结束旧进程还是为 Clash 更换端口

查到占用者后，有两种处理路线。选择依据不是“哪一步更快”，而是谁应该长期拥有这个端口。

适合退出旧进程的情况

• 占用者是已经不用的另一套 Clash 或代理客户端。
• 同一客户端异常退出后留下了独立运行的旧内核。
• 客户端被设置为开机启动，但当前准备改用另一套客户端。
• 测试程序临时占用了代理端口，确认结束后不会影响其他工作。

优先使用应用自己的退出功能或服务停止命令，让它完成状态保存与网络设置恢复。若确认是失去界面控制的残留进程，才考虑按 PID 结束。结束后重新执行端口检查命令，确认监听记录已经消失，再启动 Clash。

适合修改 Clash 端口的情况

• 原端口属于需要持续运行的服务。
• 两套代理内核确实需要同时启动，并承担不同测试任务。
• 组织或设备策略固定保留了某一端口范围。
• 客户端每次启动都与容器映射、开发工具或虚拟机服务发生冲突。

新端口应满足三个条件：当前没有监听者，没有与配置内其他字段重复，并且调用方可以同步修改。可以先选择诸如 7891、17890 之类的高位端口，再用系统命令确认其空闲状态。端口上限为 65535，不能填写负数、文字或超出范围的值。

修改 YAML 配置并避免订阅更新覆盖

如果客户端允许在设置界面中修改端口，应优先使用界面提供的端口设置，因为客户端可能会据此同步生成运行配置。直接编辑 YAML 前，要先确认当前文件是实际运行配置、订阅原始配置，还是客户端生成的临时副本。

使用单一混合端口时，可以这样配置：

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9091

如果需要分开提供 HTTP 与 SOCKS5 入口，则给两个字段分配不同端口：

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9091

修改后先进行配置校验，再重启内核。YAML 使用空格表达层级，Tab、缩进错位或重复字段都可能导致新的解析错误。端口值应写成整数。若同一字段在合并配置、覆写脚本和订阅内容中出现多次，最终生效值取决于客户端的配置合并流程，不能只看某一个文件。

同时运行两套内核时，不仅代理端口要错开，控制端口、DNS 监听端口、透明代理端口也要逐项核对。两个实例分别使用 mixed-port: 7890 和 mixed-port: 7891 还不够；如果它们都绑定 external-controller: 127.0.0.1:9090，第二个实例仍可能启动失败。

修改端口后同步系统代理与应用设置

端口冲突修复后仍不能联网，最常见原因是“监听端口已经变化，但请求仍被送往旧端口”。例如 Clash 已改为 mixed-port: 7891，Windows 或 macOS 的系统代理还指向 127.0.0.1:7890，浏览器自然无法连接新的监听入口。

系统代理

如果由 Clash 客户端自动管理系统代理，可以先关闭系统代理开关，再重新开启，让客户端写入新的地址。随后到操作系统网络设置中核对 HTTP 与 HTTPS 代理是否指向 127.0.0.1 和新端口。使用 mixed-port 时，HTTP 代理可以直接填写该端口。

浏览器与独立应用

部分浏览器扩展、下载工具、代码编辑器、聊天程序和远程连接工具不跟随系统代理，而是保存自己的代理地址。应逐项检查其中的 HTTP 或 SOCKS5 端口。若应用配置的是 SOCKS5，而当前仅保留 port，协议也会不匹配；可改用 mixed-port，或为应用指定独立的 socks-port。

终端环境变量

命令行工具可能读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。旧会话中的环境变量不会因为 Clash 配置变化而自动更新。以临时环境变量为例，端口需要与实际监听值一致：

HTTP_PROXY=http://127.0.0.1:7891
HTTPS_PROXY=http://127.0.0.1:7891
ALL_PROXY=socks5://127.0.0.1:7891

不同终端设置变量的语法并不相同，上述内容用于说明地址结构。修改启动脚本或系统级环境变量前，应确认没有其他工具依赖旧端口。

局域网设备

如果手机或其他设备通过电脑上的 Clash 代理，除了设置 allow-lan: true，还要使用电脑在局域网中的实际地址和新端口。此时监听地址、防火墙入站规则与网络隔离设置都会影响连接。不要把 127.0.0.1 填到手机上，因为它在手机中指向手机自身。

TUN 模式下继续检查 DNS 与控制端口

TUN 模式启用后，很多应用不再直接读取系统 HTTP 代理，因此用户容易认为 mixed-port 与问题完全无关。实际上，内核仍可能同时启动混合代理端口、控制接口和 DNS 服务，其中任意必需监听项冲突，都可能导致内核启动中断或部分功能异常。

如果日志指向 dns.listen，应检查 DNS 配置，例如：

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

1053 被其他 DNS 转发器占用时，可以改为另一个空闲端口，但同时依赖该监听地址的配置也要更新。若 DNS 由 TUN 自动接管，不应只根据示例盲目修改；应以客户端生成的实际配置和日志为准。

控制接口冲突则常表现为内核可能仍在运行，但图形界面显示“连接失败”“无法获取配置”或状态一直加载。此时检查 external-controller 的端口，并确认客户端连接内核时使用的是同一个地址。修改控制端口后，外部面板书签或客户端内的控制器地址也需要同步。

透明代理场景还可能涉及 redir-port、tproxy-port 和防火墙规则。只改 YAML 而不更新重定向目标，会让流量继续进入旧端口。Linux 用户应同时核对策略路由、防火墙规则和服务启动参数，确认它们没有把固定端口写在独立脚本中。

按顺序完成端口冲突复查

完成修改后，不要只用“客户端界面变绿”作为判断依据。按监听、代理入口、规则处理和实际访问四个层次复查，更容易区分端口问题与节点问题。

1. 完全退出并重新启动客户端。确认旧内核已经结束，避免测试结果来自残留进程。
2. 检查启动日志。确认原来的 bind 或 address already in use 错误不再出现。
3. 查询新端口。用 netstat、lsof 或 ss 确认监听者正是当前 Clash 或 mihomo 内核。
4. 核对系统代理。地址通常为 127.0.0.1，端口必须与 mixed-port 或 port 一致。
5. 检查独立应用设置。尤其是浏览器扩展、终端变量、下载工具与使用 SOCKS5 的程序。
6. 执行本地连接测试。先确认请求能够进入本地代理，再查看日志中是否出现对应连接记录。
7. 区分节点故障。如果日志已有请求并完成规则匹配，但目标连接超时，应继续检查代理节点、策略组和网络环境，而不是再次修改本地端口。
8. 触发一次订阅更新。更新后重新检查端口值，确认本地设置没有被订阅内容覆盖。

端口冲突的处理主线可以归纳为：从日志提取端口，查询实际监听进程，判断端口归属，修改唯一的冲突项，再同步所有请求入口。把这几步按顺序完成，比反复重装客户端或随机更换多个端口更容易留下可维护的配置。