Clash 故障排查大全

通用排查思路与工具

Clash 的数据链路可以拆成四段:应用发出请求 → 系统代理或 TUN 把流量交给客户端 → 客户端按规则匹配出站 → 节点把流量送到目标。任何一段断掉,表现出来都是「上不了网」,但成因和修法完全不同。排查的核心动作只有一个:确认问题出在哪一段,然后只修那一段。

排查顺序:从近到远

固定按这个顺序检查,不要凭直觉跳步:先确认客户端进程在运行、配置已加载(界面上能看到节点列表);再确认流量确实进入了客户端(连接面板里有新增连接记录);再确认规则匹配符合预期(连接记录里的出站是你期望的策略组);最后才怀疑节点本身。反过来查——一上来就换节点、换订阅——是最常见的时间浪费方式,因为本机链路没通时换什么节点都一样。

日志是第一手证据

所有 Clash 系客户端都提供日志面板,日志详细程度由配置文件的 log-level 字段控制。排查期间建议临时调到 debug,问题解决后改回 info,否则日志量会很大。

一条命令验证代理链路

不依赖浏览器,直接用 curl 通过本地混合端口发一次请求,是判断「客户端到节点」这一段是否通畅的最快方式。返回 204 或 200 即链路正常;卡住超时说明节点不通;连接被拒绝说明本地端口没监听。

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

如果你的混合端口不是默认的 7890,把命令中的端口号换成配置文件 mixed-port 的实际值。这条命令绕过了系统代理设置,因此它的结果能把「系统代理没配好」和「节点不通」两类问题干净地分开:命令通、浏览器不通,查系统代理章节;命令也不通,查节点超时章节。

缩小变量:一次只改一个条件

遇到不确定的问题,依次做三个对照试验:换一个节点(排除单节点故障)、切到全局模式(排除规则问题)、临时退出其他代理/加速/安全类软件(排除多个程序抢流量)。每次只改一个条件并记录结果,三次试验之后,问题范围通常已经缩小到一个明确的章节。

开启后完全无法上网

症状定义:客户端开启后,所有网站(包括国内网站)都打不开;或者关闭客户端后网络恢复正常。这一类问题几乎都出在本机链路,而不是节点。

第一步:确认物理网络本身正常

先完全退出客户端(注意是退出进程,不是最小化到托盘),然后打开一个国内网站。如果此时也打不开,问题与 Clash 无关,先解决本机网络;如果退出后能打开、开启后打不开,继续往下查。有一种例外情况需要留意:退出客户端后仍然打不开任何网站——这通常是系统代理残留,客户端异常退出时没来得及把系统代理设置改回去,处理方法见系统代理章节的「代理残留」小节。

第二步:确认流量进入了客户端

打开客户端的连接(Connections)面板,刷新一次网页,观察是否出现新的连接记录。有记录说明系统代理这一段是通的,问题在后面;完全没有记录,说明流量根本没走到 Clash——要么系统代理没写入成功,要么这个应用不遵循系统代理(典型如命令行程序),两种情况都转系统代理章节处理。

第三步:用全局模式做对照

把出站模式从「规则」切到「全局」,选一个此前测试可用的节点,再刷新网页。全局模式下能上网、规则模式下不能,说明问题在规则:大概率是规则集缺失导致大量请求落到了错误的出站,或者兜底规则 MATCH 指向了一个不可用的策略组。检查配置文件末尾的兜底规则,确认它指向的策略组里有可用节点:

rules:
  # ……前面是具体规则……
  - GEOIP,CN,DIRECT      # 中国大陆 IP 直连
  - MATCH,PROXY          # 其余流量走 PROXY 策略组(确认组内有可用节点)

如果全局模式下也不能上网,规则可以排除,问题在节点或本地端口,转节点超时章节。

第四步:检查国内流量是否被错误代理

另一种「半瘫」形态:国外网站能开、国内网站反而打不开或极慢。这说明国内流量也被送去了节点,而节点回国链路质量差。检查规则里是否包含 GEOIP,CN,DIRECT 与常用国内域名的直连规则;如果订阅提供的配置缺这部分,可以自行在 rules 段靠前位置补充 DOMAIN-SUFFIX 直连条目。规则从上到下匹配、命中即停,顺序很重要——直连规则要放在兜底 MATCH 之前。

节点全部超时或延迟异常

症状定义:延迟测试里所有节点显示超时(timeout);或者节点显示有延迟数字,但实际无法建立连接。先理解延迟测试在测什么,再判断问题层级。

延迟测试的原理与局限

客户端的延迟测试是通过每个节点向一个测试 URL(常见为 http://www.gstatic.com/generate_204)发一次 HTTP 请求,记录完成耗时。它验证的是「本机 → 节点 → 测试站」的完整链路,因此:全部超时通常不是节点全挂了,而是本机到节点这一段被整体阻断;个别超时才更可能是那个节点自身的问题。另外注意,延迟数字只反映一次小请求的往返耗时,和实际下载速度不是一回事——这个误区在速度慢章节展开。

全部超时:按序排除三个原因

其一,订阅已失效。节点服务器信息(地址、端口、密码)会由服务方轮换,本地配置停留在旧信息就会全军覆没。先手动更新一次订阅,再重新测延迟;更新本身报错则转订阅失败章节。

其二,本地网络封锁了节点端口。公司、学校、酒店网络常见只放行 80/443 端口,节点若使用高位端口会全部不通。判断方法:切换到手机热点再测一次,热点下全通而原网络全超时,即可确认是网络环境限制,解决办法是优先选用 443 端口的节点。

其三,系统时间偏差。部分加密协议对时间敏感,本机时钟与真实时间偏差超过一定范围(通常约 90 秒)会导致握手全部失败,表现和节点全挂一模一样。检查系统时间是否开启了自动同步,手动校准后重测。这是最容易被忽略、也最容易修的一个原因。

有延迟数字但连不上

延迟测试走 HTTP 小包,实际业务可能走 UDP 或长连接,两者通道不同。典型场景:网页能开但语音/视频通话不通——节点不支持 UDP 转发。这属于节点能力问题,换用标注支持 UDP 的节点即可,客户端侧无法修复。

让自动选择替你容错

与其在节点故障时手动切换,不如用 url-test 类型的策略组让客户端自动选择当前最快节点、故障时自动切走:

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [节点A, 节点B, 节点C]
    url: http://www.gstatic.com/generate_204
    interval: 300        # 每 300 秒重测一次
    tolerance: 50        # 新旧节点延迟差小于 50ms 时不切换,避免频繁抖动

订阅更新失败

症状定义:点击更新订阅后报错,或长时间无响应。订阅更新本质上就是客户端对订阅 URL 发一次 HTTP 请求并把返回内容解析为配置文件,因此排查也分「请求失败」和「解析失败」两类。

先读错误信息:常见报错对照

请求链路问题:先绕开客户端验证

用命令行直接请求订阅地址,把客户端因素排除在外:

curl -v -o sub.yaml "https://订阅地址"

命令能正常下载而客户端更新失败,多半是客户端的更新请求走了不可用的代理:很多客户端默认「通过代理更新订阅」,当节点全部失效时就会陷入「更新订阅需要可用节点、获得可用节点需要更新订阅」的死锁。解决方法是在客户端订阅设置里临时改为「直连更新」,更新成功、节点恢复后再改回。首次导入订阅时同理——此时本机还没有任何可用节点,必须允许直连请求。

命令也下载不了,则订阅服务器本身在当前网络下不可达,与客户端无关:换网络环境(如手机热点)重试,或联系服务方确认订阅地址是否更换。

解析问题:返回的不是配置

报 YAML 解析错误时,用文本编辑器打开上一步保存的 sub.yaml 看内容:如果是一段 HTML(错误页、验证页),说明订阅服务器把这次请求当成了浏览器访问,或订阅已失效;如果是 Base64 或其他编码的节点列表而非完整 YAML,说明该订阅格式面向的是其他内核,需要在获取订阅时选择「Clash 格式」,或使用服务方提供的格式转换地址。

User-Agent 被服务端区分对待

部分订阅服务按请求的 User-Agent 返回不同格式,甚至拒绝陌生 UA。Clash Verge Rev、FlClash 等客户端允许自定义订阅请求的 UA,遇到 403 或格式不对时,尝试把 UA 设置为 clash 或服务方指定的值,往往立刻解决。

能连上但速度慢

症状定义:网络可用,但网页加载慢、视频清晰度上不去、下载速率远低于预期。速度问题的变量最多,必须先建立基准,再逐项归因。

第一步:建立本地带宽基准

先关闭代理直连测一次本地带宽,记下数字。代理后的速度不可能超过这个上限;如果直连本身只有 20 Mbps,那么代理后 15 Mbps 已经是正常损耗,不必再折腾。基准之上,再对比不同节点的实际速度。

第二步:破除「延迟 = 速度」的误区

延迟测试反映的是小包往返时间,速度取决于节点的带宽与承载人数。一个 60ms 的节点完全可能比 200ms 的节点慢得多——前者可能是公用的拥挤线路,后者可能是空闲的大带宽线路。选节点看延迟只适合对交互敏感的场景(如远程终端);下载、视频类需求应实测吞吐,方法是通过该节点实际下载一个大文件观察稳定速率。

第三步:检查国内流量是否绕行节点

规则缺失时,国内网站流量出国再回来,速度断崖式下降且延迟翻倍。打开连接面板,访问一个国内网站,观察这条连接的出站是否为 DIRECT。不是的话,补充直连规则:

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

注意 GEOIP 规则依赖本地 GeoIP 数据库,客户端一般会自动下载;若日志提示数据库缺失,在客户端设置里手动触发一次数据库更新。

第四步:高峰期与线路类型

晚间集体变慢、深夜恢复,是国际出口拥塞的典型特征,属于线路问题而非配置问题:换用不同落地区域的节点(如就近的港/日/新节点通常好于远距离节点),或选择服务方标注的优质线路。所有节点全天都慢,则回头检查是否有下载类软件在后台占满上行,以及路由器上是否开着限速或 QoS 策略。

第五步:客户端与内核层面的因素

仍在维护的客户端(见选型指南)内核较新,对新协议与多路复用的支持更好;长期停留在停止维护的旧客户端上,速度和兼容性都会逐渐吃亏。另外,TUN 模式与系统代理模式在不同系统上的吞吐表现有差异,速度敏感的场景可以两种模式各测一次,择优使用。

DNS 相关问题

症状定义:部分网站打不开而其他正常;域名解析到明显错误的 IP;开启 TUN 后所有域名解析失败;或某些应用显示的 IP 是 198.18.x.x 开头的地址。这类问题都指向 DNS 配置。

理解 enhanced-mode:fake-ip 与 redir-host

Clash 的 DNS 模块有两种工作方式。fake-ip 模式下,客户端对每个域名先返回一个 198.18.0.0/16 段的虚构 IP,让应用立刻建立连接,真实解析推迟到流量出站时进行——好处是解析零等待、域名信息完整保留给规则匹配;副作用是有些程序会把这个虚构 IP 缓存或上报,产生困惑。redir-host 模式则老老实实解析出真实 IP。当前主流配置默认 fake-ip,一般不需要改;看到 198.18.x.x 地址本身不是故障。

可直接套用的 dns 段模板

dns:
  enable: true
  listen: 0.0.0.0:53          # TUN 模式下建议监听 53 端口
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"                  # 局域网主机名不使用 fake-ip
    - "+.stun.*.*"             # STUN 探测需要真实 IP
    - "time.*.com"             # 时间同步类服务
  nameserver:                  # 常规解析:国内 DoH,快且稳定
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                    # 兜底解析:境外 DoH,防污染
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN             # 解析结果为中国大陆 IP 时信任 nameserver,否则采用 fallback

各字段的分工:nameserver 负责日常解析,选国内 DoH 保证国内域名解析又快又准;fallback 是并发的第二路解析,当 fallback-filter 判断 nameserver 的结果可疑(例如境外域名却解析出了异常结果)时采用 fallback 的答案,以此对抗解析污染。逐项原理与更多写法见博客《Clash DNS 配置逐项拆解》。

典型故障与对症处理

个别网站打不开、其余正常:在连接面板搜索该域名,看它的解析与出站是否符合预期;若域名被错误直连且解析结果异常,为它补一条走代理的域名规则(DOMAIN-SUFFIX,example.com,PROXY)通常即可解决。

开启 TUN 后解析全部失败:TUN 模式会把系统 DNS 请求也接进客户端,此时 dns 段必须 enable: true 且监听 53 端口(如上模板),否则系统发出的解析请求无处应答。检查客户端 TUN 设置里的「DNS 劫持」选项是否开启,配置文件方式则确认 listen: 0.0.0.0:53 存在。

局域网设备(打印机、NAS)访问异常:局域网主机名被 fake-ip 接管所致,把相应域名模式加进 fake-ip-filter,如模板中的 *.lan。

游戏或通话类应用行为异常:这类应用常用 STUN 探测公网地址,fake-ip 会干扰探测,模板中 +.stun.*.* 一类的过滤条目就是为此准备的,按应用实际使用的探测域名补充即可。

系统代理不生效

症状定义:客户端运行正常、第 1 章的 curl 验证命令能通,但浏览器或某些应用的流量就是不走 Clash;或客户端退出后系统仍处于代理状态。

确认系统代理是否写入

客户端的「系统代理」开关做的事情,是把 127.0.0.1:7890 写进操作系统的代理设置。开关打开后,到系统里亲眼确认一次:

开关开了但系统里没写入:检查是否有其他软件(浏览器代理插件、加速器、另一份代理客户端)在反向覆盖设置;macOS 上还要注意代理写入的是「当前活跃的网络服务」,连接了多个网卡时可能写到了另一张网卡上。

不吃系统代理的应用:环境变量与 TUN

系统代理只是一个「建议」,应用可以不理会。命令行工具(git、包管理器、各类 SDK)大多默认忽略系统代理,需要显式设置环境变量:

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

这条命令只对当前终端会话生效,适合临时使用;需要长期生效可写入 shell 的配置文件。而对于既不认系统代理也没有代理设置项的应用,根治方案是 TUN 模式:客户端创建一张虚拟网卡,在网络层接管全部流量,任何应用都绕不开。配置文件方式开启:

tun:
  enable: true
  stack: system          # 兼容性问题多时可改 gvisor 对照测试
  auto-route: true       # 自动接管路由
  auto-detect-interface: true

注意 TUN 需要管理员/root 权限,并要求 DNS 段按上一章模板正确配置;主流客户端(Clash Plus、Clash Verge Rev、FlClash)在设置界面都提供了 TUN 开关与所需的权限引导,优先用界面开关而不是手改配置。

代理残留:退出后仍无法上网

客户端被强制结束(崩溃、任务管理器结束进程、系统断电)时,来不及恢复系统代理设置,重启后浏览器仍尝试连接已不存在的 127.0.0.1:7890,表现为「什么都打不开」。修复方法:按上表位置进入系统代理设置,手动关闭代理;或重新启动一次客户端、正常退出,让它自己收回设置。日常养成从托盘菜单正常退出的习惯即可避免。

客户端启动失败与崩溃

症状定义:双击无反应、启动即闪退、内核反复重启、或日志停在某条错误上。这类问题的错误信息指向性很强,优先把日志里的原话找出来。

端口被占用:bind: address already in use

启动日志出现 bind: address already in use,说明配置要监听的端口(常见 7890/7891/9090)已被其他进程占用——可能是上一次没退干净的旧内核,也可能是别的软件。三平台定位命令:

占用者是残留的旧内核,结束它即可;是其他常驻软件,则改自己这边的端口更省事——在配置文件里换一个不冲突的端口:

mixed-port: 7893           # HTTP 与 SOCKS5 共用的混合端口
external-controller: 127.0.0.1:9097   # 控制接口端口一并避开冲突

改完端口后,记得系统代理与环境变量里的端口号同步更新。完整的逐步操作见博客《Clash 提示端口被占用怎么办》。

配置文件语法错误

日志出现 yaml: line N: 一类报错,说明配置文件在第 N 行附近有语法问题。YAML 对格式极其敏感,三个高频错误:用了 Tab 缩进(必须用空格)、冒号后面漏了空格(port:7890 错,port: 7890 对)、包含特殊字符的字符串没加引号(节点名含 @、# 等字符时要用引号包住)。手工编辑过配置的,按报错行号逐一核对;订阅下发的配置报错,先重新更新订阅覆盖本地改动。

权限不足

开启 TUN 或监听低位端口(如 DNS 的 53)需要提升权限:Windows 上右键以管理员身份运行,或使用客户端提供的服务模式;macOS 上按客户端提示完成授权;Linux 上给内核文件授予能力位(setcap cap_net_admin,cap_net_bind_service=+ep)或以 systemd 服务方式运行。日志中出现 operation not permitted 即属此类。

干净重装:最后的兜底

反复崩溃且日志无明确指向时,做一次干净重装:导出订阅地址备份 → 卸载客户端 → 手动删除残留的配置目录(各客户端数据目录位置见其设置页「打开配置目录」入口)→ 从下载页重新安装当前维护中的版本 → 重新导入订阅。注意旧配置目录不删,重装往往等于没装,问题会原样回来。仍在使用已停止维护的客户端(如 Clash for Windows)且频繁崩溃的,建议直接换用维护中的客户端,迁移对照见选型指南。

移动端专项(Android / iOS)

移动系统对后台进程与网络接口的管控远严于桌面,很多「桌面上从没见过」的问题都源于此。本章按平台分列。

Android:VPN 授权与后台存活

Android 上的 Clash 客户端(首选 Clash Plus,其余见下载页 Android 区)通过系统 VPN 接口接管流量,首次启动必须同意「创建 VPN 连接」的系统弹窗;误点拒绝后客户端只能空转,到系统设置 → 应用 → 该应用 → 权限里无法找回,需在系统「VPN」设置项里重新发起连接授权。状态栏没有钥匙图标,就说明 VPN 通道没有建立。

第二大类问题是后台被杀:锁屏一段时间后网络断开、回到应用发现内核已停止,是系统电池优化把进程清理了。处理三件事:在系统电池设置里把该应用设为「不受限制/允许后台运行」;在最近任务里锁定该应用;国产定制系统(MIUI、ColorOS、HarmonyOS 等)还需在各自的「自启动管理」里放行。三处都设置后,后台存活率会显著改善。

此外,Android 客户端普遍支持「分应用代理」:只让指定应用走代理,或排除指定应用。银行类应用对代理敏感时,把它加入排除名单即可共存,不必整机关闭代理。

Android:配置与订阅的差异点

移动端更新订阅同样受「经代理更新」死锁影响(见订阅失败章节);流量敏感用户注意自动更新间隔,订阅文件本身不大,但频繁的后台延迟测试会产生持续的小流量。多设备之间保持配置一致的几种做法,见博客《Clash 多设备配置同步方案对比》。

iOS:安装渠道与常见问题

iOS 侧通过 App Store 安装 Clash Plus(官网 clashplus.io,商店链接见下载页 iOS 区)。安装后首次启动同样需要在系统弹窗中允许添加 VPN 配置,对应的配置会出现在系统设置 → 通用 → VPN 与设备管理中。常见问题两类:一是开关打开后立刻弹回——多为订阅未导入或配置无可用节点,先在应用内确认节点列表非空、延迟测试有结果,再开启连接;二是切换 Wi-Fi 与蜂窝网络后短暂断流——属于系统网络切换时 VPN 通道重建的正常过程,数秒内自动恢复,持续不恢复时在应用内手动重连一次。

iOS 系统限制单一时刻只能有一个活跃 VPN 配置,装有多个代理类应用时互相顶替是预期行为,保留一个常用的即可。另外,iOS 应用在后台被系统回收后,VPN 通道由系统网络扩展维持,正常情况下不影响连接;若频繁掉线,优先检查订阅有效性与节点质量,而不是反复重装应用。

移动端通用自检清单

1. 状态栏是否有 VPN 图标(Android 钥匙 / iOS「VPN」标识)——没有则通道未建立,回到授权环节。
2. 应用内延迟测试是否有可用节点——全超时按节点超时章节处理,蜂窝与 Wi-Fi 各测一次以区分网络环境因素。
3. 订阅最近一次更新是否成功——失败按订阅失败章节处理。
4. 问题是否只出现在特定应用——是则考虑分应用代理名单与该应用自身的网络策略。

仍未解决时的建议路线

按本页流程走完仍未定位的问题,通常剩下三种可能。其一,问题在服务侧:订阅服务的节点、线路、配额状态只有服务方能确认,带着你在排查中收集的证据(报错原话、哪些节点通哪些不通、什么时间开始)去询问,沟通效率远高于一句「用不了」。其二,问题在客户端实现:同一份订阅换一个维护中的客户端交叉验证,若新客户端一切正常,按选型指南完成迁移即可,不必恋战。其三,问题在基础环节的疏漏:回到使用文档把主线流程重新走一遍,大量「查了很久的怪问题」最终被证明是某个基础开关没有打开。

最后,保持客户端与订阅的更新习惯、优先使用维护中的客户端、把常用出站交给 url-test 自动选择——这三件事能预防本页七成以上的故障。工具的价值在于稳定可预期,配置一次、长期安静地工作,才是排查的最终目标。