Clash 故障排查大全

一、排查总则:先定位环节,再对症下药

故障排查最怕东改一处、西改一处,最后不知道是哪一处起了作用。动手之前先建立一张地图:一次代理请求从发出到返回,要经过下面这些环节。任何一环出问题,表现出来的都是「上不了网」四个字,但解法完全不同。

应用程序 → 系统代理 / TUN 模式 → Clash 核心(本地端口) → 规则匹配(策略组) → 节点 → 目标网站

逐段说明:第一段,应用是否把流量交给了系统代理——部分应用(一些游戏、命令行工具)默认不读系统代理设置;第二段,系统代理是否真正写入、指向的端口与 Clash 核心的监听端口是否一致;第三段,核心收到请求后按规则集逐条匹配,决定走直连还是交给某个策略组,策略组再选出具体节点;第四段,节点是否存活、协议是否被内核支持、途中是否被运营商阻断。故障在哪一段,就去哪一章。

问诊三条规矩

1. 先定位环节,再动手改。先判断故障发生在链路的哪一段,再去对应章节找解法;不定位就改配置,等于蒙眼抓药,改对了是运气,改错了添新病。
2. 一次只改一个变量。改一处、测一次。同时改三处,好了不知道哪处起效,坏了不知道哪处闯祸,排查会变成无底洞。
3. 先看日志,再下结论。日志是 Clash 的病历本:请求有没有进来、命中了哪条规则、报了什么错,都写在里头。排查前把日志级别从默认的 warning 调到 info 或 debug,复现一次故障,再回头读日志。error 级别只记致命错误,info 能看到每条连接的去向,debug 最细、也最吵,定位完记得调回去。

三个基础测试

下面三个测试贯穿全册,后面各章会反复让妳回到这里:

测试一,本地端口测试——验证核心到节点这一段是否通畅:

能返回 HTTP 响应头,说明核心、规则、节点这一整段是通的,问题在系统代理或应用层;超时或直接报错,说明核心到节点这一段出了问题。端口 7890 是常见默认值,以客户端里显示的混合端口(mixed-port)为准。

测试二,延迟测试——客户端面板里的延迟测试,只反映节点能否建立 TCP 连接,不代表速度快慢。全部 timeout 与个别 timeout 是两种病,走第三章的两条不同路线。

测试三,直连对照——暂时关闭系统代理(或退出客户端),确认本地网络本身能上网。本地就不通,先修本地网络,Clash 治不好它。

二、连接后无法上网

症状客户端显示运行中、系统代理开关已打开,浏览器却打不开任何网页;或只有部分网站能开,其余转圈到超时。

排查顺序

1. 看日志有没有新连接。打开客户端的日志面板,刷新一次打不开的网页。日志里一条新记录都没有,说明请求根本没到 Clash,是系统代理没生效,直接去第七章;有记录,往下走。
2. 切全局模式测一次。把代理模式从「规则」切到「全局」,再刷新网页。全局模式下能开,说明核心与节点都没问题,是规则把请求送去了直连或错误的策略组,看本章「规则误伤」一节;全局也打不开,往下。
3. 换节点测一次。在策略组里手动换一个节点,再刷新。换节点后能开,说明原节点故障,去第三章;连换几个节点都不行,往下。
4. 查 TUN 与系统代理是否打架。同时开着 TUN 模式和系统代理,个别系统上会出现回环:流量在两层接管之间打转,表现为一切请求超时。关掉其中一层再测。
5. 查安全软件拦截。部分杀毒软件、防火墙会拦截本地代理端口的回环连接,或直接拦 Clash 核心的出站。临时关闭后复测;确认是它,把客户端加入白名单再恢复防护。

规则误伤:全局能用、规则模式不行

规则模式下,每个请求按规则集从上往下逐条匹配:命中 DIRECT 走直连,命中某个策略组走代理,一条都不中走兜底规则。目标网站能不能开,取决于它命中了哪一条。常见误伤有三种:

• 规则集太旧:新出现的域名还没被收录,被兜底规则送去直连。更新订阅或规则数据(GeoIP / GEOSITE)再试。
• 自定义规则写错:手动加的规则拼错了域名后缀,或位置太靠前把请求提前截走。规则是从上往下匹配的,把怀疑的自定义规则临时注释掉再测。
• 策略组指向异常:目标网站命中了某个策略组,而该组当前选中的节点已死。换组内节点,或把该组改成 url-test 自动选优。

只有个别应用不能上网

浏览器正常、某个应用死活不走代理,多半是它不读系统代理设置——部分游戏、命令行工具、一些桌面应用都是如此。解法有二:开 TUN 模式,让流量在网卡层被接管,与应用是否配合无关;或在该应用的网络设置里手动填代理 127.0.0.1:7890。TUN 模式的开启条件与代价见第七章末。

三、节点超时与连接失败

症状延迟测试一片 timeout;或单个节点标红,日志反复出现 connect timeout、connection refused、handshake failure。

先分清「全灭」还是「个别阵亡」

全部节点同时超时,病灶几乎都在本地或订阅这一头——几十个节点同时坏的概率微乎其微;个别节点超时,才轮到节点本身。两者排查路线完全不同,先分清楚再往下。

全部超时:按顺序查四样

1. 本地网络:关代理直连,确认本机网络正常。本地不通,先修本地,后面都不用查。
2. 订阅状态:登录机场后台看套餐是否到期、流量是否用尽。订阅失效后节点列表往往还留在客户端里,但节点已全部不可用——这是「全灭」最常见的原因。确认后去第四章更新订阅。
3. 系统时间:TLS 握手要校验证书有效期,系统时间偏差过大(几分钟以上)会导致所有节点握手失败,表现为全灭。校准系统时间后重试,这一味药常被忽略。
4. 本地端口与防火墙:核心的代理端口被其他程序占用,或被防火墙拦死,表现为一切请求都失败。查端口占用的方法见第八章。

个别超时:按顺序查三样

1. 节点本身故障或被阻断:晚高峰骨干网拥塞、节点 IP 被目标地区运营商阻断,都表现为单节点超时。换一个地区、换一个入口的节点对比。
2. 协议与内核不匹配:订阅里混有多种协议的节点,老 Clash 内核不认识 VLESS、Hysteria2 等新协议,表现为这部分节点全部不可用、其余正常。换用 mihomo 内核的客户端即可识别——下载页所列客户端均为 mihomo 内核。
3. 节点参数变化:机场改了端口、密码或入口地址,而本地订阅未更新,旧参数自然连不上。更新订阅后再测。

四、订阅更新失败

症状点击「更新订阅」报错:下载失败、请求超时、解析失败、配置为空;或更新按钮转了半天的圈,节点列表却毫无变化。

排查顺序

1. 把订阅链接复制到浏览器直接打开。能下载到一个文本文件(YAML 或 Base64 内容),说明链接有效,问题在客户端一侧,走第 2 步;打不开、报 404/403、或跳转到机场公告页,说明链接失效或套餐异常,走第 3 步。
2. 客户端一侧:关掉「通过代理更新订阅」再试。这里有个循环依赖:代理已经挂了,走代理更新订阅必然失败;没有新节点,代理更起不来。更新订阅务必走直连。仍失败,检查 TUN 模式是否把更新请求也接管了进去,必要时退出客户端,用浏览器下载后改本地导入。
3. 链接一侧:回机场后台重新复制订阅地址。后台重置过订阅令牌后,旧链接即作废;套餐到期、流量用尽时,部分机场会让订阅返回空内容或错误页,续费后恢复。使用订阅转换服务的,转换服务本身挂了也会下载失败——换回机场原始订阅链接试一次。

能下载但解析失败

解析失败说明客户端拿到的东西不是它认识的格式。常见三种:

• 返回的是 HTML 错误页:订阅地址被反代或转换服务挡下,返回了一个网页而不是配置。浏览器打开该链接,看一眼内容便知。
• 格式与客户端不匹配:订阅内容是其他客户端的专有格式(有些面板默认输出别的格式)。在机场后台或转换链接的参数里,指定输出 Clash / mihomo 格式。
• 内容被截断:网络抖动导致下载不完整,YAML 结构残缺。重新更新一次,或用浏览器下载完整文件后本地导入。

本地导入兜底

订阅地址一时恢复不了,可用浏览器把能打开的订阅内容另存为 .yaml 文件,在客户端里选择「从文件导入」。本地文件不会自动更新,订阅恢复后记得改回订阅链接方式,否则节点变化永远同步不进来。配置文件(Profile)的更多管理方法——多配置切换、合并、更新策略——见《Clash 配置文件是什么》。

五、速度慢、卡顿与缓冲

症状代理能连通,但网页加载慢、视频反复缓冲、下载速度远低于预期;或白天正常、晚间卡顿,规律性发作。

先分清慢在哪一段

做一次对照:关闭代理直连测速,再开代理测速。直连就慢,是本地宽带或 Wi-Fi 的问题,先修本地;直连正常、代理慢,慢在节点或规则,往下查。

延迟数字不等于速度

客户端里的延迟测试只反映建立 TCP 连接花了多少毫秒,与带宽是两回事:延迟 300ms 的节点可能跑满百兆,延迟 80ms 的节点也可能只有几兆。挑节点别看延迟排名,看实际打开网页、拖视频进度条的手感,或用测速页面实测。

节点侧的三个慢因

• 晚高峰负载:晚间八点到十一点是节点最拥挤的时段,同一节点白天与晚间的速度可能相差数倍。此时段换负载低的节点,或换地区试试。
• 线路绕路:节点到目标网站的线路质量决定体验。访问日本网站却走美国节点,数据要跨两次太平洋。按目标网站的所在地区选就近节点。
• 倍率与限速:部分机场对低倍率节点限速、对单连接限速。大流量任务(系统更新、云盘同步)尽量安排在直连规则里,别占代理带宽。

规则侧的两个慢因

• 目标走了错误策略组:打开日志,看目标域名命中了哪条规则、被分到哪个组。流媒体域名被分到「兜底直连」组,就会又慢又可能看不了区域限定内容。
• 自动选择组失灵:url-test 组按延迟选节点,可能选中延迟低但带宽小的节点。高峰期把关键策略组改成手动指定,反而更稳。

本机侧的两个慢因

• TUN 模式开销:TUN 在网卡层处理全部流量,大流量下载时有额外开销。追求极限速度时,浏览器走系统代理、下载器直连,是更划算的组合。
• 双重代理:系统代理与 TUN 同时开,或浏览器代理插件与系统代理叠加,流量多绕一层,速度白白打折。保持只有一层接管。

选节点的系统方法——延迟、倍率、地区、协议四个维度怎么权衡——另有一篇:《Clash 节点怎么选》。

六、DNS 解析异常

症状浏览器报「找不到服务器 IP」;部分域名打不开,但对应 IP 能连通;打开网页的首次等待特别长,第二次访问就恢复正常。

先懂 Clash 的 DNS 两种工作方式

Clash 核心内置 DNS 模块,有两种解析策略,表现与兼容性不同,选错了就会出上面的症状:

排查顺序

1. 确认是 DNS 故障。打不开的网站,用其 IP 直连(或换一台设备用蜂窝网络)能开,基本可断定病灶在解析环节,而不是节点。
2. 看当前 DNS 配置。配置里 dns.enable 是否为 true;客户端界面里「DNS 接管」类开关是否被关掉。核心没接管 DNS,污染与劫持就直接打在系统解析上。
3. fake-ip 兼容排查。故障集中在游戏、局域网服务(打印机、NAS、投屏)、部分政务银行类应用,高度疑似 fake-ip 不兼容。把这些域名加进 fake-ip-filter,或整体改回 redir-host 模式。
4. 运营商劫持排查。家用宽带默认 DNS 常劫持 UDP 53 端口的明文查询,返回被篡改的结果。给 nameserver 配上 DoH / DoT 加密解析,劫持即失效。

一份可直接照抓的 DNS 配置

dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - localhost.ptlogin2.qq.com
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

剂量说明:nameserver 负责解析国内域名,走快的;fallback 负责解析国外域名,走加密通道防污染;fake-ip-filter 里放不认假地址的域名,通配符写法如上。改完配置需重启核心才生效。

验证命令:

返回 198.18.x.x 段地址,说明 fake-ip 在工作;返回超时,说明核心的 DNS 没起来,回第 2 步检查 dns.enable 与监听端口。

七、系统代理不生效

症状客户端运行中、节点正常,但日志里始终没有新连接记录;系统设置里看不到代理项,或代理项指向的端口与客户端不一致。

各平台确认系统代理是否写入

写入失败的常见原因

1. 权限不足:写系统代理需要相应权限。Windows 上以普通权限运行的客户端可能被组策略限制;macOS 首次开启会弹授权框,点过「不允许」的,到系统设置的网络代理页里手动打开。
2. 浏览器插件夺权:SwitchyOmega 一类代理插件接管浏览器后,完全无视系统代理,按插件自己的规则走。表现为「系统代理明明开了,浏览器却不走」。停用插件,或把插件切回「使用系统代理」模式。
3. 其他代理软件残留:之前装过的 VPN、加速器退出时没清理系统代理,系统设置里还指着旧端口。手动把系统代理改回 127.0.0.1 与当前客户端端口,或先关掉、让客户端重新写入。
4. 端口对不上:不同客户端的默认端口不同(常见 7890,部分为 7897),配置文件里也可能改过 mixed-port,而系统代理还指着旧值。让两边一致,或在客户端里重新开关一次系统代理,让它按当前配置重写。

手动写入与 TUN 兜底

自动写入始终失败时,可手动在系统设置里填:地址 127.0.0.1,端口与客户端 mixed-port 一致。手动写入的缺点是客户端退出后系统代理不会自动清除,关机前需手动关,否则下次开机不启动客户端时全网不通。

更彻底的解法是 TUN 模式:在网卡层接管全部流量,不依赖系统代理,不读系统代理的应用(游戏、命令行)也能被接管。代价是需要安装服务模式或授予管理员 / root 权限,且与系统代理同时开可能回环——二者取其一。Windows 上以管理员身份运行客户端后开启 TUN;macOS 上按客户端提示授权安装助手工具;Linux 需 root 或配置 capabilities。

八、客户端崩溃与启动失败

症状双击客户端没反应、启动即闪退、弹出「核心启动失败」、界面卡死无响应、开机自启后悄悄退出。

先拿到真实报错

图形界面闪退时,用命令行启动客户端,或单独启动内核,报错会直接打印在终端里。报错文本是本章一切解法的入口——先拿到它,再对照下文四类高发病因。图形界面把错误吞掉了,盯着图标猜是猜不出来的。

四类高发病因

配置文件语法错误

YAML 对缩进极敏感:必须用空格、同层级对齐、不能用 Tab,冒号后面必须跟一个空格。手动编辑配置后核心起不来,九成是缩进或标点问题。把改动撤回,或把配置贴进 YAML 校验工具过一遍再启动。

端口被占用

代理端口(默认 7890)或外部控制端口(默认 9090)被其他程序占用,核心启动即退出。查占用:

第一条用于 Windows,第二条用于 macOS / Linux。占用者若是上一个没退干净的 Clash 进程,结束它再启;若是别的软件,改客户端端口,或改那个软件的端口。

权限不足

TUN 模式、增强模式需要特权,权限不够时核心启动失败或 TUN 网卡建立失败。Windows 右键「以管理员身份运行」;macOS 按提示输入密码安装助手;Linux 用 sudo 或 setcap 授权。

配置目录损坏

异常断电、强制退出可能写坏缓存或配置索引,表现为客户端能打开、但一点操作就崩。先备份订阅链接与自定义规则,再删除配置目录让客户端重建。配置目录位置:Windows 在 %APPDATA% 下以客户端名命名的目录;macOS 在 ~/Library/Application Support/;Linux 在 ~/.config/。

杀毒软件误伤

部分安全软件把代理核心当作可疑程序拦截或隔离。核心文件突然消失、每次更新后被拦,都是典型表现。把客户端安装目录与配置目录加入白名单,被隔离的核心文件恢复回来,再启动。

九、移动端专项排查(Android / iOS)

症状Android 上锁屏后断流、切应用后代理失效;iOS 上后台一段时间后连接断开;或移动端特有的「VPN 图标消失」「开关自动关闭」。

Android 专项

1. 省电策略杀后台(最高发):国产 ROM 默认激进清理后台,锁屏几分钟就把代理核心收了。进系统设置,把客户端加入电池优化白名单、允许自启动、锁定在最近任务列表。各 ROM 入口不同(小米在「省电与电池」,华为在「应用启动管理」),找不到就在设置里搜「电池优化」。
2. VPN 唯一性冲突:Android 同一时间只允许一个应用持有 VPN 服务。另一个 VPN、加速器、去广告应用抢占了 VPN 位,Clash 的开关就会被顶掉。停掉冲突应用再开。
3. 分应用代理设置:客户端里的「分应用代理」若把目标应用排除在外,该应用表现为不走代理。检查名单,或临时切回「代理全部应用」做对照。
4. 私人 DNS 冲突:系统「私人 DNS」(Private DNS)开启后,会绕过代理的 DNS 接管,部分场景下导致解析异常。代理表现奇怪时,先把私人 DNS 关掉对照一次。

iOS 专项

1. 后台刷新限制:iOS 对后台网络活动限制严格,锁屏或切出应用一段时间后,连接可能被系统挂起,回到应用时自动重连。这属系统机制,不是故障;断流频繁的,检查是否开了低电量模式——它会进一步压缩后台活动。
2. VPN 配置冲突:装过多个代理类应用时,系统里可能残留多个 VPN 配置,互相顶开关。到「设置 → 通用 → VPN 与设备管理」里删掉不用的配置。
3. Wi-Fi 与蜂窝切换:网络切换瞬间,代理隧道要重建,会有几秒断流,属正常重连过程;切换后长期不恢复的,开关一次飞行模式强制重连。

移动端客户端的选择:Android 首推 Clash Plus,另有 Clash Meta for Android、FlClash 可选;iOS 首推 Clash Plus(App Store 上架,官网 clashplus.io)。各平台客户端的详细对比见客户端对比页,安装包在下载页。