Clash 内核报错、浏览器打不开网页、订阅明明更新过却仍不能连接——这类问题的成因通常集中在五个环节:本地端口是否被占用、系统代理开关是否真正生效、当前节点是否可用、DNS 解析是否被劫持或污染、以及防火墙或安全软件是否拦截了内核进程。逐一排查比反复重启客户端更省时间。本清单按照从内到外的顺序编排:先确认内核自身能不能正常监听端口,再确认系统层面是否把流量转发给了内核,然后确认转发出去的流量能否真正抵达目标站点。
本文以 Clash Meta 内核(mihomo)及主流图形客户端(Clash Verge、Clash for Windows 系分支、ClashX Meta 等)为基准,命令行示例区分 Windows、macOS、Linux 三个平台,操作前请确认客户端已完全退出重启一次,排除临时性异常。
第一步:检查本地端口占用
Clash 内核默认会监听混合端口(通常是 7890)、控制面板端口(9090)以及部分客户端使用的 DNS 端口(53 或 1053)。如果这些端口已经被其他程序占用,内核会启动失败或静默降级,表现为客户端界面显示"运行中"但实际没有流量经过。
Windows
netstat -ano | findstr "7890"
netstat -ano | findstr "9090"输出中最后一列是进程 PID,可用任务管理器或 tasklist /FI "PID eq 进程号" 查看该进程是谁。若发现端口被非 Clash 进程占用,可在客户端设置里把混合端口改为 7891 等空闲值,或结束占用进程后重启内核。
macOS / Linux
lsof -i:7890
lsof -i:9090命令会列出监听该端口的进程名与 PID。如果输出为空,说明内核根本没有成功监听该端口,需要回到客户端日志面板查看内核启动报错,常见原因是配置文件里端口字段拼写错误或端口号超出合法范围。
第二步:检查系统代理开关状态
客户端界面上的"系统代理"开关本质是在写入系统的代理设置字段,而不是直接控制内核。开关显示为"已开启"不代表系统真的采纳了这份设置,常见于开关被安全软件重置、或者系统同时存在多套网络配置(如 VPN 与 Wi-Fi 共存)导致代理写入了错误的网络接口。
Windows 校验
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServerProxyEnable 返回值为 0x1 表示系统代理已启用,ProxyServer 应显示为 127.0.0.1:7890 之类的地址。若地址与客户端实际监听端口不一致,需在客户端里重新点击一次系统代理开关刷新写入。
macOS 校验
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi如果当前使用的是有线网络,把 Wi-Fi 换成 Ethernet 或对应接口名(可先用 networksetup -listallnetworkservices 查看接口列表)。
Linux 校验
大部分 Linux 图形客户端不直接改写系统级代理,而是依赖桌面环境或浏览器插件读取环境变量,建议直接检查:
echo $http_proxy
echo $https_proxy若为空,说明系统代理需要手动在网络设置或 shell 配置文件中声明,或改用 TUN 模式接管流量以绕开系统代理这一层。
第三步:检查节点可用性
系统代理生效不代表节点能通,常见于订阅节点到期、机场临时维护、或者当前选中的节点延迟测试显示超时。排查顺序建议为:先看客户端节点列表里的延迟数值,再用控制台单独测一次目标节点。
- 延迟列显示"超时"或"N/A":该节点当前不可用,先切换到延迟正常的备用节点。
- 所有节点延迟均异常:多半是订阅整体失效或本机网络中断,先确认本机能否直连访问境内站点。
- 延迟正常但仍无法访问目标网站:该节点可能被目标站点单独封锁,尝试切换出口地区。
通过控制面板 API 也能验证节点连通性,前提是控制端口已在设置里开放:
curl -x http://127.0.0.1:7890 https://www.google.com -I --max-time 5返回 HTTP/2 200 或 30x 状态码说明代理链路本身是通的;如果命令超时或返回连接拒绝,说明问题出在代理链路而非浏览器或应用本身,应回到节点或订阅层面继续排查,而不是反复检查浏览器设置。
订阅链接对应的机场存在单账户设备数限制,同一订阅在多台设备同时使用时,部分机场会随机拒绝新连接,表现为节点延迟正常但请求依旧失败,遇到此类情况建议先在其他设备上退出客户端再测试。
第四步:检查 DNS 解析
Clash 支持在配置文件里单独定义 DNS 服务器、启用 fake-ip 或 redir-host 模式,如果本机系统 DNS 与 Clash 内置 DNS 出现冲突,常见现象是网页能打开但加载缓慢,或者部分域名始终解析到错误的 IP。
确认当前生效的 DNS
# Windows
nslookup www.google.com
# macOS / Linux
nslookup www.google.com
dig www.google.com +short如果开启了 fake-ip,解析结果通常落在 198.18.0.0/16 这一保留段,这是正常现象,代理会在传输层根据域名重新建立连接,不代表解析出错。若结果落在真实公网 IP 段但网站仍打不开,需要进一步排查是否命中了错误的分流规则,把该域名导向了直连而非代理。
验证 Clash 内置 DNS 是否被正确调用
nslookup www.google.com 127.0.0.1 -port=1053端口号需与配置文件中 dns.listen 字段一致。如果该命令超时,说明内核 DNS 模块没有正常启动,应回到配置文件检查 dns.enable 是否为 true,以及上游 DNS 服务器地址是否可达。
第五步:检查防火墙与安全软件拦截
操作系统自带防火墙、第三方安全软件、企业内网的终端管控软件都可能针对 Clash 内核进程做拦截,这类拦截往往没有明显报错,只是连接请求被静默丢弃,排查时容易被误判为节点问题。
Windows Defender 防火墙
netsh advfirewall firewall show rule name=all | findstr /i "clash"如果没有匹配结果,说明防火墙里不存在为 Clash 内核放行的规则,可在"允许应用通过防火墙"设置里手动为客户端可执行文件及内核进程(常见文件名为 clash-meta.exe 或 mihomo.exe)勾选专用网络与公用网络。
macOS 应用防火墙
路径为"系统设置 → 网络 → 防火墙 → 选项",确认 Clash 客户端及其内核进程状态为"允许传入连接"。部分安全软件(如企业 EDR)会在系统防火墙之外单独拦截,需要在对应软件的信任列表里补充放行。
Linux iptables / ufw
sudo iptables -L -n | grep 7890
sudo ufw status verbose确认没有针对代理端口的 DROP 或 REJECT 规则。若使用 TUN 模式,还需确认虚拟网卡对应的路由表项已正确写入,可用 ip route 查看是否存在指向 utun 或 tun0 的默认路由。
逐项勾选清单
把上述五步压缩成一份可直接对照使用的检查表:
- 混合端口(7890)与控制端口(9090)未被其他进程占用,内核日志无端口冲突报错。
- 系统代理字段(
ProxyServer/networksetup输出)与客户端实际监听端口一致。 - 当前选中节点延迟正常,或已切换到延迟正常的备用节点。
curl -x测试通过代理能正常访问目标站点,返回合法 HTTP 状态码。- DNS 解析结果符合预期(
fake-ip段或正确的真实 IP),未命中错误的分流规则。 - 系统防火墙及安全软件均已为 Clash 客户端与内核进程放行网络权限。
- 若使用 TUN 模式,虚拟网卡路由表项已正确写入且未被其他 VPN 抢占默认路由。
如果以上七项全部通过但依旧无法访问特定站点,大概率是目标站点单独对代理出口 IP 段做了封锁或验证码拦截,属于站点侧策略问题,不应继续在本机网络配置上反复调整。
建议把这份清单保存为本地笔记,每次遇到连接异常时按顺序执行,而不是随机尝试重启、换节点、重装客户端。多数连接失败问题在完成前两步(端口与系统代理)后就能定位,剩下的节点、DNS、防火墙三步用于处理少数顽固场景。