先确认是不是端口冲突
Clash、Clash Meta（mihomo）内核启动时，需要在本机监听一个或多个端口。常见配置会把 mixed-port 设为 7890，让同一个端口同时接受 HTTP 与 SOCKS5 代理连接。如果该端口已经被另一个进程监听，新启动的内核就无法再次绑定，客户端可能停在“启动中”，也可能直接显示内核启动失败。
日志中出现下面一类信息时，通常可以优先检查端口。不同内核版本和操作系统的措辞略有差异，但关键字一般包含 bind、address already in use、Only one usage 或具体端口号。
listen tcp 127.0.0.1:7890: bind: address already in use
listen tcp 0.0.0.0:7890:
bind: Only one usage of each socket address is normally permitted不要只看 7890。配置中还可能存在单独的 HTTP 端口、SOCKS 端口、透明代理端口和外部控制端口。例如，某份配置可能同时使用 port: 7890、socks-port: 7891 与 external-controller: 127.0.0.1:9090。日志指出哪个地址绑定失败，就检查哪个端口。
端口冲突与连接失败不是一回事
- 端口冲突：内核不能启动，日志显示监听或绑定失败。
- 节点连接失败：内核已经启动，但代理节点超时，日志通常指向远端地址。
- 系统代理未更新：内核监听正常，但浏览器仍连接旧端口，表现为网页无法打开。
- 控制端口冲突：代理端口可用，但图形界面无法连接内核，常见涉及
external-controller的 9090 或其他自定义端口。
先在客户端日志里找到完整报错，再检查对应端口，可以避免把节点故障误判为本地端口问题。若日志显示的是配置解析错误，例如 YAML 缩进错误或字段类型错误，修改 7890 不会解决启动失败。
Windows：用 netstat 定位占用进程
Windows 10 与 Windows 11 都自带 netstat。先完全退出 Clash Nyanpasu，再以普通权限打开“终端”或“命令提示符”，执行以下命令：
netstat -ano | findstr :7890如果端口正在被监听，结果可能类似下面这样。最后一列 18432 是进程 PID，不是端口号。
TCP 127.0.0.1:7890 0.0.0.0:0 LISTENING 18432
TCP [::1]:7890 [::]:0 LISTENING 18432然后把查到的 PID 交给 tasklist，确认进程名称：
tasklist /FI "PID eq 18432"如果返回的是另一个代理客户端、旧版 Clash 内核或仍在后台运行的桌面客户端，应先从该程序自身的退出菜单正常关闭。若只是异常残留进程，可以在确认名称和 PID 后结束：
taskkill /PID 18432 /F用 PowerShell 查看更清晰的结果
PowerShell 可以直接返回拥有该监听端口的进程 ID。Windows 11 的“终端”默认通常就是 PowerShell：
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess拿到 OwningProcess 后继续查询进程：
Get-Process -Id 18432如果 Clash 配置还启用了 UDP 监听，TCP 查询为空并不能完全排除冲突。可以补充检查 UDP：
Get-NetUDPEndpoint -LocalPort 7890 |
Select-Object LocalAddress, LocalPort, OwningProcess根据监听地址判断影响范围
| 监听结果 | 含义 | 排查重点 |
|---|---|---|
127.0.0.1:7890 |
仅本机 IPv4 回环地址 | 检查本机代理程序与旧内核 |
[::1]:7890 |
仅本机 IPv6 回环地址 | 同一进程可能同时监听 IPv4 与 IPv6 |
0.0.0.0:7890 |
监听所有 IPv4 网络接口 | 检查开启局域网访问的代理或开发工具 |
[::]:7890 |
监听所有 IPv6 网络接口 | 检查双栈监听与端口复用情况 |
同一个 PID 同时出现两行通常不代表两个冲突程序，而是该程序分别监听 IPv4 与 IPv6。真正需要确认的是拥有端口的进程是否为当前准备启动的内核，以及系统中是否残留另一份实例。
macOS 与 Linux：用 lsof、ss 查端口
macOS 可以在“应用程序”→“实用工具”→“终端”中运行 lsof。下面的命令只查看 TCP 7890，并筛选监听状态：
lsof -nP -iTCP:7890 -sTCP:LISTEN输出中的 COMMAND 是进程名，PID 是进程编号。例如：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mihomo 4217 user 11u IPv4 0x01 0t0 TCP 127.0.0.1:7890 (LISTEN)先回到菜单栏检查是否还有 Clash 客户端正在运行。确认是已经失去界面控制的残留进程后，可以先发送正常终止信号：
kill 4217等待两秒后再次执行 lsof。只有进程未退出且身份已经核对清楚时，才考虑强制结束：
kill -9 4217Linux 优先使用 ss
多数现代 Linux 发行版预装 ss。查看 TCP 7890 的监听者可以执行：
sudo ss -lptn 'sport = :7890'检查 UDP 时使用：
sudo ss -lpun 'sport = :7890'如果系统装有 lsof，也可以使用跨平台写法：
sudo lsof -nP -i :7890Linux 上还要留意 systemd 服务。手动运行的图形客户端退出后，系统级 mihomo 服务可能仍在后台监听。可以先查询服务状态，再决定是否停止：
systemctl status mihomo
sudo systemctl stop mihomo服务名称取决于实际安装方式，也可能是 clash 或自定义单元名。不要在没有确认服务用途时直接禁用。若这项服务就是日常使用的代理核心，更合适的做法是保留它，并让图形客户端使用另一组端口。
在 Clash Nyanpasu 中修改混合端口
如果占用 7890 的程序必须继续运行，可以为 Clash Nyanpasu 换一个未被使用的端口。常见操作路径是「设置」→「Clash 设置」→「常规」→「混合端口（Mixed Port）」。界面名称会随版本调整，但应在内核或 Clash 参数区域查找 mixed-port。
- 先用 netstat、lsof 或 ss 检查计划使用的新端口，例如
7893。 - 把混合端口从
7890改为7893。 - 保存设置，并执行一次内核重启或完全退出后重新打开客户端。
- 回到日志，确认出现监听
127.0.0.1:7893的记录。 - 重新开启系统代理，让操作系统中的代理地址同步到新端口。
建议优先选择 1024 以上、当前未监听的端口。端口号最大为 65535。不要为了避开冲突改成 80、443 等低位端口，这些端口可能需要额外权限，也更容易与 Web 服务发生冲突。
为什么改完端口仍然打不开网页
端口修改成功只代表内核已经能监听。浏览器、终端和其他应用还需要连接新的端口。如果系统代理仍保存为 127.0.0.1:7890，请求会继续发往旧地址。最直接的处理方式是关闭一次“系统代理”，再重新开启，让客户端写入 127.0.0.1:7893。
终端中的环境变量不会总是随系统代理自动更新。若此前手动配置过代理，需要同步修改：
export HTTP_PROXY=http://127.0.0.1:7893
export HTTPS_PROXY=http://127.0.0.1:7893
export ALL_PROXY=socks5://127.0.0.1:7893使用混合端口时，同一个 7893 可以接受 HTTP 代理和 SOCKS5 代理连接，因此上面的写法可以共用端口。若配置采用独立的 port 与 socks-port，则应分别填写对应端口，不能全部照搬 7893。
直接修改配置文件中的 mixed-port
使用 mihomo 命令行、容器或自行管理配置文件时，可以直接编辑 YAML。最简写法如下：
mixed-port: 7893
allow-lan: false
mode: rule
log-level: infomixed-port 是 HTTP 与 SOCKS5 共用的入站端口。已经使用该字段时，通常不需要再同时设置相同数值的 port 和 socks-port。重复或重叠的监听配置可能再次触发绑定失败，也会增加排查难度。
如果确实需要分开提供 HTTP 与 SOCKS5 端口，可以使用不同数值：
port: 7893
socks-port: 7894
allow-lan: false
mode: rule
log-level: info外部控制接口也必须使用独立端口。例如：
mixed-port: 7893
external-controller: 127.0.0.1:9091
secret: "change-this-controller-secret"这里把代理入口设为 7893，把控制接口设为 9091。两者用途不同：7893 接收应用的代理流量，9091 供图形界面或控制面板调用内核 API。若日志明确显示 9090 被占用，只改 mixed-port 没有作用，应修改 external-controller 并同步更新客户端的控制器连接设置。
修改后先验证配置，再重启内核
命令行运行 mihomo 时，可以先使用内核提供的配置检查参数。实际可执行文件名取决于安装方式：
mihomo -t -f config.yaml检查通过后再按原方式启动。若依然失败，读取完整日志并确认报错中的端口是否已经变成 7893。日志仍显示 7890，通常说明当前启动的不是刚才编辑的配置文件，或者图形客户端在启动时重新生成了运行配置。
改端口后仍启动失败的五项检查
1. 新端口也被占用
不要仅凭感觉选择 7891 或 7892，这些也是代理工具常用端口。修改前先运行查询命令。Windows 可执行 netstat -ano | findstr :7893，macOS 可执行 lsof -nP -iTCP:7893 -sTCP:LISTEN。没有输出通常表示当前没有 TCP 监听者，但启用 UDP 入站时还要检查 UDP。
2. 客户端同时启动了两个内核
自动启动、服务模式和手动启动可能形成重复实例。先完全退出客户端，确认 7890、7893 与控制端口都已释放，再只启动一次。如果端口在客户端退出后立刻重新出现，应检查系统启动项、计划任务、登录项或 systemd 服务。
3. 配置覆写没有实际生效
订阅中的 mixed-port: 7890 可能被客户端全局设置覆盖，反过来也可能由启动参数覆盖配置文件。判断依据应是运行日志和实际监听结果，而不是只看编辑器中的 YAML。启动后再次查询端口，确认内核究竟监听了哪个地址。
4. 外部控制端口冲突
代理端口空闲并不代表所有监听都能建立。检查日志是否指向 127.0.0.1:9090、9091 或其他控制端口。修改控制端口后，图形界面连接地址也要同步，否则内核可能已经运行，但面板会显示“未连接”。
5. 监听地址或权限不合适
启用 allow-lan 后，配置可能监听 0.0.0.0 或指定局域网地址。如果该地址已经失效，日志可能显示“cannot assign requested address”，这不是普通的端口占用。把监听地址恢复为有效接口，或仅监听 127.0.0.1 后再试。使用 1024 以下端口时还可能遇到权限不足，应改用更高端口。
避免 7890 再次冲突的配置习惯
- 只保留一个自动启动入口：图形客户端、后台服务与计划任务不要同时负责启动内核。
- 为不同客户端分配不同端口：例如主客户端使用 7890，测试实例使用 7893，容器实例使用 7895。
- 记录控制端口：代理端口与
external-controller分开记录，排错时按日志逐项查询。 - 退出后检查托盘：关闭窗口不一定结束进程，升级或切换客户端前应使用完整退出操作。
- 让客户端管理系统代理：修改混合端口后重新切换系统代理，减少旧端口残留。
- 把本地端口放在持久化设置中：订阅负责节点和规则，本机监听端口由客户端覆写或全局设置管理。
如果同一台设备需要同时运行多个 mihomo 实例，还应为每个实例分配不同的混合端口、控制端口和运行目录。仅修改 7890 不足以隔离全部资源；缓存、数据库、Unix socket 或命名管道也可能需要独立路径，具体取决于启动方式和客户端实现。
快速排查顺序
- 打开客户端日志，记下绑定失败的完整地址和端口。
- 完全退出 Clash Nyanpasu，观察端口是否随之释放。
- Windows 用 netstat 或 PowerShell，macOS 用 lsof，Linux 用 ss 查询 PID。
- 确认进程名称，正常退出重复客户端或停止重复服务。
- 占用程序必须保留时，把
mixed-port改为已确认空闲的 7893 等端口。 - 同时检查
external-controller，避免只解决代理端口冲突。 - 重启内核，并以日志和监听结果确认新配置生效。
- 重新开启系统代理，更新终端环境变量及手工填写端口的应用。
端口被占用本质上是本机监听资源冲突。排查关键不是反复重装客户端，而是从日志中找到端口，用系统命令定位 PID，再决定退出占用进程还是调整配置。完成修改后，别忘了同步系统代理和终端环境变量，否则内核虽然恢复运行，应用仍会继续访问旧端口。