Clash 故障排查手册

开始之前:排查思路与信息收集

排查这件事,方法比运气重要。这一章不解决任何具体问题,但它决定了你后面每一章能不能查得又快又准。花三分钟读完,能省掉后面反复试错的一小时。

三条排查原则

一次只改一个变量。很多人一出问题就同时换节点、换模式、重启客户端、重启电脑,最后问题好了也不知道是哪一步起了作用,下次复发只能重新抓瞎。正确做法是:改一处,验证一次,记一笔。

从离自己最近的一端往外查。整条链路是"应用 → 系统代理 / TUN → 客户端 → 节点 → 目标网站",越靠左越容易自查,越靠右越依赖第三方。先确认本机这半截没问题,再去怀疑节点和订阅服务商,顺序反了就是白忙。

每一步都要有验证动作。"感觉好像好了"不算数,要有一个明确的验证手段:一条 curl 命令、一次延迟测试、一个固定网站的访问结果。本手册每章都会给出对应的验证方法。

动手前先收集这几样信息

• 客户端名称与所在平台(比如 Clash Plus / Windows、Clash Verge Rev / Linux),不同客户端设置项位置不同,但排查逻辑通用;
• 当前代理模式:规则 / 全局 / 直连,以及是否开了 TUN(虚拟网卡)模式;
• 订阅来源:链接是订阅服务商直发的,还是经过转换服务处理过的;
• 客户端日志里最近的报错行——几乎每个客户端都有日志面板,先把等级调到 info 复现一次;
• 问题是"一直如此"还是"某次改动之后出现"。后者直接回滚那次改动,往往比排查快得多。

症状速查表

不确定该看哪章的,先对着下面这张表找症状,点章节名直达。

症状一:开了代理,完全无法上网

先给结论:这类问题九成出在两处——流量根本没进客户端(系统代理没设上、被别的软件抢了),或者进了客户端但出不去(模式选错、规则命中拦截、节点全挂)。用一条命令就能把这两类切开,别急着重装。

第一步:用 curl 直接打客户端端口

打开客户端设置页,记下混合端口(常见默认是 7890,但一定以你客户端里显示的为准,别抄网上教程)。然后在终端 / 命令提示符里执行:

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

这条命令绕开系统代理,强制流量走客户端端口。结果只有两种走向:

• 返回 204 或任何 HTTP 响应头:客户端和节点这半截是通的,问题出在"流量没进来"——跳到下一小节查系统代理;
• 报连接被拒绝 / 超时:流量进了客户端但出不去,问题在客户端配置或节点——跳到"流量出不去"小节。

流量没进来:查系统代理与浏览器插件

确认客户端里"系统代理"开关处于开启状态,再去系统设置里核对代理确实被写上了(各平台检查位置见系统代理章的对照表)。写上了还不行,重点排查三个"抢流量"的嫌疑人:

• 浏览器代理插件:SwitchyOmega 之类的插件优先级高于系统代理,如果插件里配了一个已失效的代理,浏览器就全断。把插件切到"系统代理"或直接停用再试;
• 其他代理软件残留:之前装过的代理工具卸载不干净,退出时没把系统代理还原,或者开机自启后跟当前客户端互相覆盖。任务管理器里搜一遍,把不用的彻底退出;
• 安全软件与企业策略:部分安全软件会锁定代理设置,公司电脑可能有组策略强制代理,这类环境需要先解除锁定。

流量出不去:查模式与规则

1. 看代理模式。直连模式下所有流量都不走节点,误开了就等于白开;新手误触这个开关的概率相当高。
2. 规则模式下,打开客户端的连接 / 日志面板,访问一次打不开的网站,看这条连接被哪条规则命中、分到了哪个策略组。命中 REJECT 就是规则把它拦了,命中的策略组里如果选中的节点已失效,换一个节点即可。
3. 做一次"全局测试":切到全局模式,手动选一个刚测过延迟正常的节点,再访问。全局能通、规则不通,基本可以锁定是规则或策略组选择的问题。

TUN 与系统代理叠加的坑

TUN 模式和系统代理同时开着,流量路径会变得很难推理:有的连接走虚拟网卡,有的走系统代理,日志看起来自相矛盾。排查期间只留一条通路——要么关 TUN 只用系统代理,要么开 TUN 关系统代理,定位到问题之后再恢复日常组合。

症状二:节点延迟测试超时

延迟列一片"超时"确实吓人,但先分清楚两件事:延迟测试超时不完全等于节点不能用。延迟测试是让节点去访问一个固定的测试地址,个别节点对测试地址不友好但实际访问正常;反过来,也有延迟数字好看、真用起来打不开网页的。最终以实际访问为准,延迟只是参考。

全部超时:先查本地和订阅,别怪节点

所有节点同时超时,节点集体故障的概率反而最低,更可能是你这一侧的问题:

1. 确认本地网络正常:关掉代理(或切直连模式),打开一个国内网站。本地都不通,先修本地网络,这不是客户端的锅;
2. 确认订阅还活着:订阅服务到期、流量用尽、或服务商重置了链接,都会让整份节点集体失效。直连状态下登录服务商官网核对状态,然后在客户端里手动更新一次订阅;
3. 检查测试地址:部分客户端允许自定义延迟测试 URL,如果被改成了一个本身就不可达的地址,那测出来自然全超时。恢复成默认的 generate_204 类地址再测;
4. 换客户端交叉验证:同一份订阅导入另一个客户端(获取客户端页五个平台都有备选),如果另一个客户端一切正常,问题在原客户端的设置,重点回查端口、TUN、DNS 三处。

部分超时:节点侧问题的判断

只有部分节点超时,处理起来反而简单:

• 按区域成片超时:某条国际线路故障或维护,换其他区域的节点先顶着,过几个小时再回来看;
• 固定几个节点长期超时:大概率这几个节点已下线但订阅没清理,反馈给订阅服务商;
• 晚高峰集体变慢、偶发超时:线路拥堵的典型表现,属于速度慢那一章的范畴,换冷门区域节点缓解;
• 换了网络环境后成片超时:某些网络(校园网、企业网)会拦截特定端口或协议,试试同一订阅里不同协议、不同端口的节点。

症状三:订阅导入或更新失败

订阅问题的好处是报错信息通常很直白,坏处是很多客户端把报错折叠在日志里不弹出来。导入 / 更新失败后,第一件事是打开日志面板找到那行红字,然后对着下表按图索骥。

报错信息对照

用命令手动验证订阅链接

拿不准是链接坏了还是客户端的问题,用 curl 模拟客户端拉一次订阅(示例链接是假的,换成你自己的):

curl -A "clash" -I "https://example.com/api/sub?token=xxxx"

返回 200 且响应头里能看到 subscription-userinfo 之类的字段,说明链接本身健康,问题在客户端侧;返回 404 / 403,直接去服务商后台换新链接。注意 -A "clash" 这个参数:不少订阅服务按 User-Agent 下发不同格式,浏览器直接打开看到的内容和客户端拉到的可能不一样,验证时要带上 clash 系 UA 才有参考价值。

导入成功但节点列表是空的

这种"假成功"通常是格式问题:订阅返回的是通用分享格式而不是 Clash 配置,老内核客户端遇到新协议节点也可能整段跳过。两个处理方向:一是找服务商要 Clash 格式的专用订阅入口;二是确认你用的是 mihomo 内核的客户端(获取客户端页在架的主力客户端都是),新协议支持齐全,老格式兼容也更好。

更多订阅相关的单点问答(自动更新间隔、多订阅共存、流量信息不显示),集中在常见问题的"安装配置"分类里。

症状四:能连上,但速度慢

"慢"是最难查的症状,因为瓶颈可能在链路的任何一段。这一章的核心方法就一句话:先用交叉测试把瓶颈定位到某一段,再动手优化那一段,别一上来就换订阅。

三段交叉定位法

1. 同节点测不同目标:当前节点下打开三四个不同的网站。全都慢,怀疑节点或本地;只有某个网站慢,那是目标站本身或它对这条线路不友好,换节点区域就好;
2. 同目标换不同节点:换两三个不同区域的节点访问同一个网站。换谁都慢,重点查本地;换个区域就快,是原节点拥堵;
3. 直连测本地底速:切直连模式跑一次本地测速。直连都慢,先解决宽带和 Wi-Fi 的问题,代理不可能比底速更快。

节点侧:拥堵、倍率与协议

晚高峰变慢是共享线路的常态,冷门时段快、热门时段慢,基本可以确认是拥堵,换冷门区域节点是最直接的缓解。另外留意订阅里的流量倍率标注——高倍率节点通常走更贵的线路,速度体验往往也不同,值不值得用自己权衡。同一服务商如果提供多种协议入口,也可以互相切换对比,不同协议在不同网络环境下的表现差异不小。

客户端侧:模式与设置

• 日常用规则模式,别挂全局:全局模式下访问国内网站也要绕道节点,等于所有流量都排队走窄门。规则模式让直连流量走直连,是速度和体验的最优解;
• 日志等级调回 info:debug 等级会记录海量日志,长期开着对性能有拖累,排查完记得调回来;
• 检查有没有套了多层代理:策略组里选了"中转 / 链式"类分组,或者客户端外面又套了一层别的代理工具,每多一跳都要付出速度代价;
• 规则集过大:自定义规则堆了几万条且写法低效(大量正则),匹配开销会上来,精简规则或改用规则集(rule-provider)按需加载。

本机与网络环境侧

Wi-Fi 信号差、2.4G 频段拥挤、路由器性能不足,都会成为整条链路的地板。特别提一句在路由器上直跑内核的方案:软路由 / 旁路由性能不够时,跑代理的开销会直接压低全屋网速,选型思路见博客路由器直跑 mihomo 内核部署概览。此外看一眼有没有下载工具、云盘同步在后台占满上行——上行一满,所有连接的表现都会雪崩。

症状五:DNS 解析异常

DNS 是最隐蔽的一类故障,症状五花八门:节点延迟一切正常但网页转圈打不开、某些直连网站被解析到奇怪的地区、局域网设备突然找不到。如果你排除了节点和系统代理的问题还是不对劲,八成就是 DNS。

先搞懂 fake-ip 和 redir-host

Clash 系内核的 DNS 有两种增强模式:fake-ip 给每个域名先返回一个保留段的假 IP,连接进来后再按域名做规则匹配,速度快、规则命中准,是当前的主流默认;redir-host 返回真实解析结果,兼容性场景下使用。两者的详细差异和适用场景,术语手册里有对应词条,博客的 DNS 配置详解一文拆得更细,这里只讲排查。

典型症状对照

• 网页转圈打不开,但节点延迟正常:多半是 nameserver 里填的上游 DNS 不可用,解析这一步就卡死了。换成可达的 DoH 地址再试;
• 某些国内网站被解析到境外、加载异常:分流参考了 fallback 的境外解析结果,检查 fallback-filter 是否配置了 geoip 兜底;
• 局域网设备、NAS、打印机找不到了:fake-ip 把局域网域名也劫持了,把 *.lan、+.local 之类加进 fake-ip-filter;
• 关掉客户端后一段时间上网仍异常:系统里缓存了 fake-ip 段的解析结果,清一次系统 DNS 缓存即可恢复。

一份可直接套用的 DNS 段

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

思路很简单:nameserver 负责日常解析,选直连可达、响应快的;fallback 负责兜底境外域名,配合 fallback-filter 的 geoip 规则——解析结果落在国内 IP 就信 nameserver,否则采用 fallback 的结果,防止污染。

改完怎么验证

重载配置后,直接向客户端的 DNS 监听端口发一次查询(对应上面配置的 1053 端口):

nslookup -port=1053 www.gstatic.com 127.0.0.1

fake-ip 模式下返回 198.18 开头的地址就是正常工作。另外记得清一次系统缓存,别让旧结果干扰判断:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

症状六:系统代理不生效

先讲清楚原理,后面的怪现象就都能解释了:客户端开"系统代理",本质只是在操作系统的网络设置里登记一个 HTTP/SOCKS 代理地址,应用是否读取这个登记,完全是自愿的。浏览器读,所以浏览器走代理;很多命令行工具和部分桌面应用不读,所以它们照旧直连。这不是故障,是机制如此。

各平台检查系统代理的位置

客户端里开关是开着的、系统设置里却是空的,说明写入失败了:检查客户端有没有获得修改网络设置的权限,以及是不是有别的软件在反复把它改回去(残留的代理工具、某些安全软件都干这事)。Linux 桌面环境的坑更多一些,GNOME 和 KDE 各有一套代理设置,终端还认环境变量,三套互不相通,部署细节可参考博客Linux 两条部署路线。

命令行与开发工具:要单独喂

终端里的 curl、pip、npm 之类默认不读系统代理,要靠环境变量(端口换成你客户端的实际端口):

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7891

Git 则有自己的配置项,常用写法是 git config --global http.proxy http://127.0.0.1:7890,不用了记得 --unset 掉。桌面应用里如果有"网络设置"或"使用系统代理"的开关,优先在应用内打开,比全局折腾干净得多。

实在不想逐个配:上 TUN 模式

TUN 模式创建一块虚拟网卡,在网络层接管全部流量,不依赖任何应用配合,系统代理管不到的命令行、游戏、UWP 应用统统能覆盖。代价是需要管理员 / 系统扩展授权,并且 DNS 配置要正确(配合上一章的 fake-ip 方案)。开启入口与授权步骤各客户端不同,使用指南里有对应小节;概念层面的解释见术语手册的 TUN 词条。开 TUN 之后建议关掉系统代理,理由见症状一里说过的"只留一条通路"。

症状七:客户端崩溃或无法启动

崩溃闪退看着吓人,实际上是原因最集中的一类:配置文件语法错误和端口冲突,两个加起来能覆盖绝大多数案例。按下面的顺序查,一般十分钟内见分晓。

第一嫌疑:配置文件语法

客户端刚导入新订阅、或你手改过配置之后开始闪退,基本可以锁定是配置问题。最干净的验证方法是用内核直接做语法检查——mihomo 内核自带校验参数(内核可在获取客户端页的内核区取得):

mihomo -t -f /path/to/config.yaml

有错它会直接指出行号和原因。手改配置最常见的三种低级错误:YAML 缩进用了 Tab 或层级不对、复制粘贴带进了中文引号、同一层级出现重复键。逐个对照改掉即可。改不明白就先换回上一份能用的配置,让客户端先跑起来。

第二嫌疑:端口冲突与残留进程

上一个客户端实例没退干净、或别的软件占了同一端口,新实例起不来是必然的。先查谁占着端口:

# Windows
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

找到占用进程后,要么结束它,要么在客户端设置里换一组端口。顺带检查开机自启项里是不是躺着两个代理客户端在互相打架——只保留一个。

学会看日志

以上都排除了还在崩,就得靠日志说话。在架的主力客户端(Clash Plus、Clash Verge Rev、FlClash 等)都提供日志页或"打开日志目录"入口。把日志等级调到 debug,复现一次崩溃,看日志最后几行——崩溃前的最后一条记录,通常就是元凶所在的模块。看不懂的报错,拿关键词搜常见问题的"故障排查"分类,常见报错都收了词条。

干净重装的正确姿势

1. 先备份:导出或抄下订阅链接,自定义规则和配置文件复制一份到别处;
2. 卸载并清残留:卸载后手动删掉配置目录(位置见客户端的"打开配置目录"入口),残留的坏配置是"重装了还崩"的头号原因;
3. 重装并逐步恢复:先装好、空配置能启动,再导订阅,再逐步加回自定义内容,每加一步验证一次,坏东西自然会现形;
4. 换客户端交叉验证:同平台换一个客户端(获取客户端页各平台都备了两到四个选择,首推 Clash Plus),同一份配置在别家也崩,那是配置问题;别家正常,再回头深挖原客户端。

症状八:移动端专项(Android / iOS)

手机上的问题有自己的一套逻辑:桌面端的故障多在配置,移动端的故障多在系统权限和后台策略。桌面思路照搬到手机上经常查错方向,所以单独成章。

Android:权限与后台是两大命门

• VPN 权限:Android 客户端靠 VpnService 接管流量,首次启动的授权弹窗必须点允许。之后如果在系统设置里撤销了权限、或装了另一个 VPN 类应用抢走了通道(系统同一时间只允许一个 VPN 活跃),客户端就会静默失效。设置 → 网络 → VPN 里看一眼当前活跃的是谁;
• 电池优化杀后台:国产定制系统的激进省电策略是"用着用着断了"的最大元凶。把客户端加入电池优化白名单、允许后台运行与自启动,部分系统还要在最近任务里给它上锁;
• 分应用代理配错:客户端里的分应用代理(允许 / 排除列表)如果把目标应用排除了,那个应用自然不走代理。出问题先把分应用代理恢复默认再排查;
• 省流量模式与私人 DNS:系统的省流量模式会限制后台联网;系统层的"私人 DNS"设置也可能和客户端 DNS 打架,排查期间设为自动。

Android 端在架客户端(Clash Plus、Clash Meta for Android、FlClash、Surfboard)见获取客户端页 Android 区,同一订阅换个客户端交叉验证的思路在手机上同样好使。

iOS:围绕 VPN 配置那点事

• 安装渠道:iOS 端从 App Store 安装 Clash Plus 即可,入口在获取客户端页 iOS 区;
• VPN 配置冲突:装过多个代理类应用的设备,设置 → 通用 → VPN 与设备管理里会有多份 VPN 配置。切换应用前先把旧的断开,两份配置抢通道是 iOS 上"开了但没流量"的常见原因;
• 切换网络后的短暂断流:Wi-Fi 和蜂窝之间切换时 VPN 隧道要重建,几秒钟的断流属正常现象。频繁掉线不恢复的,检查客户端里的"按需连接 / 自动重连"设置是否开启;
• 后台被系统回收:iOS 内存紧张时会回收后台应用,VPN 隧道一般还在但应用界面要重新加载,重新打开应用即可,不算故障;
• 更新订阅失败:蜂窝网络下留意系统是否禁了该应用使用蜂窝数据(设置 → 蜂窝网络里逐应用开关)。

移动端通用建议

手机的网络环境比桌面复杂得多:Wi-Fi、蜂窝、运营商 DNS、热点各有各的脾气。遇到"时好时坏",先固定在同一个网络环境下复现,别在地铁里边切基站边排查。订阅更新失败时,把链接复制到浏览器验证一下可达性(方法同订阅失败章),能快速区分是链接问题还是应用问题。系统的省电模式、低数据模式在两个平台上都会干扰后台联网,排查期间统统关掉。