Clash 端口被占用怎么办：定位进程与修改监听端口

Clash 启动时需要在本机建立一个或多个监听端口。浏览器、操作系统和其他应用把代理请求发送到这些端口，再由 Clash 按配置文件中的规则与策略组处理流量。如果目标端口已经被另一个进程监听，系统会拒绝第二次绑定，核心通常会报告地址已被使用、监听失败或端口占用。

常见情形包括：旧的 Clash 进程退出不完整、同时启动两个客户端、其他代理工具使用相同端口、配置里把多个监听器写成同一个端口，以及控制接口或 DNS 服务撞上本地开发服务。正确处理方式不是反复点击启动，而是先确认冲突发生在哪个地址和端口，再查出对应进程，最后决定关闭占用者还是修改 Clash 配置。

一、从报错文本识别端口冲突

不同客户端对核心日志做了不同程度的整理，但底层报错通常包含 bind、listen、address already in use 或“端口被占用”等关键词。日志中最有价值的是协议、监听地址和端口号。例如 127.0.0.1:7890 表示只在本机回环地址监听 7890；0.0.0.0:7890 表示尝试在全部 IPv4 网络接口上监听该端口。

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

第一条通常对应 HTTP、SOCKS 或 mixed 代理入口，第二条更可能对应外部控制接口。端口号并不能单独证明是哪项配置，因为用户可以修改默认值。应当同时检查日志上下文以及当前生效配置。

如果日志没有出现绑定失败，而是提示 TUN 设备创建失败、权限不足、路由设置失败或网络接口不存在，那么问题不一定与代理端口有关。此时更换 7890 一类端口通常不会解决故障，应转向检查管理员权限、虚拟网卡、TUN 驱动和系统路由。

二、确认 Clash 正在使用哪些监听端口

Clash 与 mihomo 配置中可以存在多个本地监听器。实际字段取决于客户端能力和当前配置，最常见的几项如下。

配置项	用途	冲突时的影响
`mixed-port`	在同一端口接收 HTTP 与 SOCKS5 代理连接	系统代理和手动代理可能同时失效
`port`	HTTP 代理监听端口	使用 HTTP 代理的应用无法连接
`socks-port`	SOCKS5 代理监听端口	使用 SOCKS5 的应用无法连接
`redir-port`	接收重定向流量，主要用于特定系统网络方案	透明代理链路无法建立
`tproxy-port`	接收 TPROXY 流量，常见于 Linux 路由环境	透明代理规则无法把流量交给核心
`external-controller`	为客户端界面或外部面板提供控制 API	界面可能无法读取核心状态或修改策略
`dns.listen`	提供本地 DNS 服务	域名解析请求无法进入 Clash DNS 模块

mixed-port 已经可以同时处理 HTTP 和 SOCKS5 请求。若配置采用 mixed 模式，通常不需要再把 port 或 socks-port 设置成相同数值。两个监听器不能在同一地址上占用完全相同的传输协议和端口组合。

还要区分“订阅配置”和“客户端运行设置”。一些桌面客户端会在运行时生成最终配置，把界面中的端口、控制接口和 TUN 选项合并到订阅内容中。此时直接编辑订阅文件，可能在更新订阅或重启客户端后被覆盖。优先在客户端的常规设置、端口设置或覆写配置中修改；只有确认客户端直接读取 YAML 时，才编辑对应字段。

三、在 Windows、macOS 与 Linux 定位占用进程

Windows：查询 PID 与进程名称

以 7890 端口为例，在命令提示符中运行：

netstat -ano | findstr :7890

结果中的 LISTENING 表示进程正在监听端口，最后一列是 PID。继续查询该 PID 对应的程序：

tasklist /FI "PID eq 1234"

也可以在 PowerShell 中使用结构化命令：

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

如果命令提示权限不足，可使用管理员终端重新查询。任务管理器的“详细信息”页也能按 PID 查找进程。发现另一个 Clash 客户端或旧核心时，应先从对应界面正常退出，确认托盘区进程结束，再考虑终止进程。

macOS：使用 lsof 查看监听程序

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

输出会列出进程名、PID、用户和监听地址。若检查的是 DNS 服务，还需要查询 UDP，因为本地 DNS 监听可能同时涉及 UDP 和 TCP：

sudo lsof -nP -iUDP:1053
sudo lsof -nP -iTCP:1053 -sTCP:LISTEN

Linux：使用 ss 或 lsof

sudo ss -lntp 'sport = :7890'
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss 的 -l 表示只看监听套接字，-n 避免把端口转换成服务名，-t 查询 TCP，-p 显示进程。检查 UDP 监听时可以使用：

sudo ss -lnup 'sport = :1053'

四、关闭占用进程，还是修改 Clash 端口

定位占用者后，处理方法取决于进程用途。若占用者是此前遗留的 Clash 核心，正常退出旧客户端通常最合适。若两个客户端都需要保留，则必须给它们分配不同的代理端口、控制端口和 DNS 监听端口。仅修改 mixed-port，而保留相同的 external-controller，第二个核心仍可能启动失败。

如果端口属于长期运行的开发服务、容器映射或局域网服务，修改 Clash 端口通常更稳定。选择新端口时，应先用系统命令确认没有进程监听。端口范围必须在 1 到 65535 之间，并避免把 HTTP、SOCKS、控制接口和 DNS 服务重复设置到同一个地址与端口。

若占用进程已退出，但端口查询仍显示监听状态，可能存在以下情况：

客户端界面关闭后仍驻留在系统托盘，核心进程没有结束。
服务管理器自动重启了该进程，例如系统服务或容器重启策略。
同时安装了多个客户端，其中一个设置为开机启动。
查询的是另一个网络协议，例如只检查了 TCP，而冲突来自 UDP DNS 监听。
配置同时在 IPv4 和 IPv6 地址上监听，需要结合日志中的具体地址检查。

强制结束进程应作为确认身份后的处理手段。Windows 可以使用任务管理器结束任务，macOS 与 Linux 可以先发送常规终止信号，让程序有机会保存状态。若进程持续自动出现，应关闭它的开机启动、后台服务或容器重启配置，而不是反复结束 PID。

五、修改 mixed-port、HTTP 与 SOCKS 监听配置

只需要一个统一代理入口时，可以保留 mixed-port，并移除重复的 HTTP 与 SOCKS 独立监听项。以下示例把统一入口改为 7893，并把控制接口放在 9091：

mixed-port: 7893
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

需要让不同应用分别使用 HTTP 与 SOCKS5 时，可以设置两个不同端口：

port: 7893
socks-port: 7894
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

不要把配置写成 mixed-port: 7893、port: 7893 和 socks-port: 7893 的组合。即使某些客户端在生成配置时会忽略部分字段，也不应依赖这种不明确的行为。每个实际启用的独立监听器都应有清晰且不重复的端口。

修改 YAML 时还要保持缩进和数据类型正确。端口通常写为整数。保存后应在客户端中重新载入配置或重启核心，并查看日志确认新端口已经进入监听状态。如果客户端提供“混合端口”“HTTP 端口”“SOCKS 端口”等界面选项，应优先通过界面修改，避免运行配置与界面显示不一致。

端口修改后同步更新系统代理

核心成功监听新端口，不代表应用已经自动改用该端口。系统代理仍可能指向旧的 127.0.0.1:7890。在客户端中关闭并重新启用系统代理，通常可以重新写入当前端口。若浏览器、命令行工具、下载工具或开发环境使用手动代理，也要逐项更新。

例如，应用原来使用 HTTP 代理 127.0.0.1:7890，而新的 mixed-port 是 7893，则应改为 127.0.0.1:7893。使用 SOCKS5 的应用也可以连接 mixed-port，但代理类型仍要在应用中选择 SOCKS5。只改端口而选错代理协议，可能出现连接失败或认证格式错误。

六、TUN 模式、DNS 监听与局域网地址的特殊情况

TUN 模式通过虚拟网络接口接管流量，应用不一定直接连接 mixed-port。不过，只要配置中启用了 mixed、HTTP、SOCKS 或控制接口，核心启动时仍会尝试建立对应监听。因此，TUN 已开启并不代表可以忽略普通代理端口冲突。

排查 TUN 时要先看错误发生在哪一步。如果日志明确指向 127.0.0.1:7890 或 0.0.0.0:9090 的绑定失败，按端口冲突处理。如果日志指向虚拟网卡、路由表、权限或防火墙，则应检查 TUN 环境。两类问题可能同时存在，需要按日志逐项解决。

DNS 模块是另一个容易遗漏的冲突来源。示例配置可能包含：

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

如果 1053 已被本地 DNS 转发器占用，Clash DNS 服务会启动失败。应同时查询 TCP 与 UDP 占用情况，再决定调整 Clash 的 dns.listen，还是修改另一项服务。更换 DNS 监听端口后，还要检查系统、路由脚本或其他转发程序是否仍把请求发送到旧端口。

开启局域网访问时，监听范围可能从回环地址扩展到网络接口。某个程序只监听 127.0.0.1:7890，另一个程序尝试监听 0.0.0.0:7890，也可能产生冲突，因为后者希望覆盖全部 IPv4 接口。判断时必须连同地址一起看，不能只比较端口号。

七、验证端口修复是否完整

修复完成后，建议按固定顺序验证，避免把系统代理残留、配置未切换或节点故障误认为端口问题。

重新启动核心，确认日志中不再出现 bind 或 address already in use。
使用 netstat、Get-NetTCPConnection、lsof 或 ss 检查新端口，确认监听进程确实是当前 Clash 核心。
在客户端确认当前 Profile 已选中，规则模式、全局模式或直连模式符合测试目标。
重新启用系统代理，确认代理地址与修改后的端口一致。
检查控制界面能否读取节点、策略组和连接信息，排除控制端口仍冲突的情况。
使用浏览器或指定代理的命令行请求进行测试，再查看连接日志是否出现对应请求。
若使用 TUN，额外检查虚拟网卡、DNS 解析和路由是否正常。

端口已经监听但网页仍无法访问时，问题通常已从“监听冲突”转移到其他层面。此时应检查配置是否成功载入、节点是否可用、规则是否把目标交给正确策略组、DNS 是否返回有效结果，以及应用是否确实使用了新代理地址。端口监听成功只说明本地入口建立完成，不代表上游代理链路一定可用。

也可以先把模式临时切换到便于判断的测试状态，观察连接日志中是否出现请求，但测试后应恢复日常规则模式。若日志完全没有新连接，重点检查系统代理和应用代理；若连接出现但失败，重点检查节点、DNS、规则和网络连通性。

八、端口占用常见问题

7890 被占用后，可以直接改成任意数字吗？

可以选择 1 到 65535 范围内尚未被占用的端口，但应避开系统服务和已有应用。修改前先查询监听状态，修改后同步更新系统代理、浏览器和其他手动代理设置。

为什么关闭 Clash 窗口后端口仍被占用？

部分桌面客户端关闭窗口后会继续在托盘运行，核心进程也会保留。应从托盘菜单完整退出，再通过 PID 查询确认进程结束。若进程自动恢复，还要检查开机启动或后台服务。

mixed-port 和 socks-port 能使用同一个端口吗？

不应这样配置。mixed-port 本身已经接收 HTTP 与 SOCKS5 请求。若还需要独立 socks-port，应分配另一个端口；否则两个监听器会争用同一地址和端口。

修改端口后，Clash 显示运行但系统不能联网怎么办？

先检查系统代理是否仍指向旧端口。关闭并重新启用客户端中的系统代理，再核对当前 Profile、运行模式和连接日志。使用固定代理地址的应用也需要单独修改。

9090 冲突会影响代理流量吗？

9090 常被用作外部控制接口。冲突后，核心可能无法启动，或者客户端界面无法连接核心、读取策略组和连接记录。即使 mixed-port 没有冲突，也应给控制接口分配独立可用端口。

使用 TUN 模式后还需要保留 mixed-port 吗？

取决于使用场景。TUN 可以接管系统流量，但浏览器调试、命令行工具或其他设备仍可能需要显式代理入口。如果保留 mixed-port，它就必须能够正常监听；不需要时则通过客户端支持的设置停用。

端口冲突的核心判断标准很明确：某个监听地址与端口已经被进程占用，而 Clash 又尝试绑定相同组合。记录日志、查询 PID、确认进程用途、调整配置并同步系统代理，可以把问题限制在具体环节。处理完成后再验证 Profile、规则、DNS 与 TUN，能够避免把后续网络故障继续归因于端口。