Clash 故障排查大全

本页与使用指南分工明确:指南覆盖从安装到首次成功连接的主线操作,适合第一次配置的用户跟着走;本页面向「已经装好、但某个环节出了问题」的场景,按症状定位章节,自上而下执行排查步骤即可。每章的步骤按命中概率排序,前几步解决大多数情况。还没安装客户端的先去下载页取安装包(全平台首推 Clash Plus),再按指南完成初始配置,遇到问题再回到本页查阅。

一、排查总则与日志读法

动手改任何设置之前,先建立两个习惯:分层定位,和一次只改一个变量。代理链路从上到下可以拆成五层——客户端界面、内核进程、配置与订阅、远端节点、本机系统环境。症状出在哪一层,决定了该往哪个方向查。乱序尝试「重装、换订阅、改 DNS」三板斧,经常把原本单一的问题改成叠加故障。

分层定位的基本顺序

• 客户端层:界面是否正常打开、开关状态是否与预期一致、有没有报错弹窗。
• 内核层:内核进程是否在运行、监听端口是否可连(见第二章的 curl 验证法)。
• 配置层:订阅是否加载成功、规则模式(Rule/Global/Direct)选的是哪个、规则是否命中了预期出口。
• 节点层:节点是否可用、延迟测试结果如何、订阅是否过期。
• 系统层:系统代理/TUN 是否真正写入系统、防火墙与其他网络软件是否干扰。

日志页与日志级别

日志页是排查的主要信息来源。多数客户端默认级别是 info,能看到每条连接的目标域名、命中的规则与最终出口,足以回答「这条流量到底走了哪个节点」。定位 DNS 或握手层面的问题时临时切到 debug,排查完改回来,否则日志量会明显拖慢界面。

最小复现配置

当怀疑「问题出在订阅里的复杂配置」时,用一份最小配置验证内核与节点本身是否正常。把下面的示例存成 minimal.yaml,替换成任意一个可用节点的参数,在客户端里作为本地配置加载。最小配置能通、完整订阅不通,问题就锁定在订阅的规则或 DNS 段;最小配置也不通,问题在节点或系统层。

mixed-port: 7890
log-level: info
mode: rule
proxies:
  - name: test-node
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
proxy-groups:
  - name: PROXY
    type: select
    proxies: [test-node]
rules:
  - MATCH,PROXY

二、开启代理后无法上网

症状定义:开启客户端后所有网页打不开,或者关闭客户端后网络也回不来。这是最常见也最容易误判的一类问题,关键是先把「代理链路坏了」和「系统代理设置残留」区分开。

第一步:确认本机基础网络

退出客户端,直接访问一个国内网站。打不开说明本机网络本身有问题,与代理无关,先处理路由器或运营商侧。打得开再继续下一步。如果退出客户端后仍然全网打不开,大概率是系统代理残留,直接跳到本章「系统代理残留清理」小节。

第二步:用命令绕过浏览器验证代理端口

浏览器有自己的代理缓存与扩展干扰,不适合当测试工具。用 curl 直接对内核端口发请求,结果干净可信:

# 验证内核代理端口是否可用
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

# 返回 HTTP 204 → 内核与节点链路正常,问题在系统代理层,看第七章
# connection refused → 内核没在监听,看第八章(进程/端口问题)
# 长时间无响应超时 → 节点不可用,看第三章

第三步:检查规则模式与出口

代理页顶部的模式开关误切也会造成「全网打不开」:Global 模式指向了一个已失效的节点,所有流量都会跟着失效;Direct 模式在某些网络环境下则表现为部分网站不可达。日常保持 Rule 模式,并确认策略组当前选中的节点延迟测试为绿色。另外检查订阅里是否有 MATCH,REJECT 之类的兜底拦截规则被意外启用——日志页里如果大量连接显示命中 REJECT,就是这类规则在拦。

系统代理残留清理

客户端异常退出(崩溃、强杀进程)时来不及恢复系统代理设置,系统仍然把流量指向已经不存在的 127.0.0.1:7890,表现为「关了客户端反而全网断」。处理办法:重新打开客户端再正常退出一次,通常会自动恢复;不行就手动清:Windows 在「设置 → 网络和 Internet → 代理」里关闭「使用代理服务器」;macOS 用命令:

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

三、节点全部超时或延迟测试失败

先区分「全部超时」和「部分超时」,两者的原因几乎不重叠。

全部节点超时

1. 检查本机时间。多数加密协议对时间偏差敏感,系统时间与标准时间差超过一两分钟,握手会全部失败。打开系统的自动时间同步,手动改过时区的重点检查。
2. 检查订阅是否过期。服务商在订阅到期后通常保留节点条目但拒绝连接,表现就是全部超时。登录服务商后台确认有效期,过期续费后更新订阅。
3. 检查防火墙与安全软件。Windows 首次运行内核时如果拒绝了防火墙授权弹窗,出站连接可能被静默拦截。在「Windows 安全中心 → 防火墙和网络保护 → 允许应用通过防火墙」里确认内核进程被放行,第三方安全软件同理。
4. 换一个网络环境交叉验证。手机开热点让电脑连上再测一轮。热点下正常、原网络下全超时,说明当前网络对代理协议有干扰,与客户端和订阅无关。

部分节点超时

个别节点超时属于正常现象:节点服务器故障、线路波动、被目标网络屏蔽都会造成。处理原则很简单——切到延迟正常的节点用,过几小时或订阅更新后再看。如果某个地区的节点长期全灭,向服务商反馈,客户端侧没有可修的东西。

正确理解延迟数字

延迟测试是向 url-test 指定的测试地址发一次请求并计时,数字反映的是「到测试目标的一次往返」,不等于实际浏览体验;测试地址本身不可达时,健康的节点也会显示超时。测试地址可以在策略组里自定义:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [node-a, node-b]

延迟数字与真实体验的差距来源(测试目标、丢包、带宽瓶颈),博客里有一篇专门拆解:Clash 延迟测试原理拆解。

四、订阅导入与更新失败

订阅问题的错误提示信息量很大,先照着错误关键字对表,再看细分小节。

格式不匹配

「链接在别的软件里能用、在 Clash 里导入失败或节点为空」,九成是格式问题:Clash 系客户端吃的是完整 YAML 配置,而有些链接返回的是 Base64 编码的裸节点列表。判别方法是把链接粘到浏览器里打开——看到 proxies:、rules: 这类字段是 YAML,看到一大段无空格字母数字是 Base64。服务商后台通常提供「Clash 订阅」专用链接,优先用它;没有的话经订阅转换工具转成 Clash 格式再导入。各格式的结构差异与转换注意事项见博客:Clash 订阅格式科普。

更新订阅的网络环回问题

订阅服务器在某些网络环境下无法直连,更新请求本身就需要走代理;但代理又依赖订阅里的节点——鸡生蛋问题。多数客户端在订阅设置里提供「通过代理更新」开关:节点还能用时开着它更新;节点全挂时关掉它、换到可以直连订阅服务器的网络(比如手机流量热点)更新一次,恢复节点后再切回来。

手动导入兜底

任何自动更新都失败时,还有一条稳定退路:用浏览器直接打开订阅链接,把返回内容另存为 .yaml 文件,在客户端配置页选择「导入本地文件」。这条路径不经过客户端的下载逻辑,能绕开 UA、代理环回等所有网络侧干扰,也常用于验证「到底是链接坏了还是客户端下载环节坏了」。

五、连接正常但速度慢

先分清延迟与带宽

「慢」有两种:打开网页前的等待久,是延迟高;视频清晰度上不去、下载速率低,是带宽不足。延迟低不代表带宽大——延迟测试只发一个很小的请求,测不出吞吐。两者的排查方向不同:延迟高优先换物理距离更近的节点;带宽低优先排查节点倍率与本地链路。

排查顺序

1. 换节点对比。同一订阅里换三个以上不同地区的节点各测一次。全都慢,继续往下;个别慢,是节点本身拥塞,避开即可。
2. 测直连带宽做基线。关闭代理,对国内测速点跑一次带宽。直连本身只有几十兆,代理速度不可能超过它,预期要先校准。
3. 排查本机占用。下载工具、网盘同步、系统更新都会挤占上传与下载。日志页或连接页按流量排序,揪出吃带宽的进程。
4. 核对分流是否错位。规则配置不当会让国内流量绕道境外节点,表现为「国内网站也变慢了」。在日志页确认国内域名命中的是 DIRECT;不是的话检查规则集顺序,通常是自定义规则把 GEOIP 兜底规则挡在了后面。
5. 晚高峰交叉验证。只在每天固定时段慢,是线路拥塞的典型特征,换非热门地区节点或与服务商确认线路类型。

六、DNS 相关问题

两种解析模式的差别

Clash 系内核处理 DNS 有 fake-ip 与 redir-host 两种增强模式。fake-ip 用 198.18.0.0/16 保留网段的假地址应答本机查询,真实解析发生在节点侧,匹配快、泄漏少,是当前的主流默认;redir-host 则在本地完成真实解析。原理层面的完整拆解见博客:Fake-IP 模式原理详解。一份工作正常的 DNS 段大致长这样:

dns:
  enable: true
  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://120.53.53.53/dns-query

典型症状与处理

• 凭 IP 能访问、凭域名打不开:DNS 解析环节故障。检查配置里 dns.enable 是否为 true、nameserver 是否可达;临时把日志切到 debug,能直接看到每条查询发给了谁、答了什么。
• 某软件显示连到 198.18.x.x:这是 fake-ip 的假地址,被不走代理的程序拿到了。把该程序涉及的域名加进 fake-ip-filter,让这些查询返回真实地址。
• 局域网设备连不上(打印机、NAS、投屏):fake-ip 接管了本地域名解析。确认 fake-ip-filter 里有 *.lan、+.local 这类本地后缀;问题设备用固定主机名的,把主机名一并加入。
• 切换网络后全网解析异常:fake-ip 缓存与新网络环境不一致。客户端里执行「清除 fake-ip 缓存」(多数客户端在设置或首页提供按钮),或重启内核。
• 游戏联机、P2P 类应用异常:这类应用对真实 IP 敏感,fake-ip 下容易出问题。要么给相关域名加 filter 例外,要么整体换到 redir-host 模式测试。

七、系统代理不生效

系统代理的能力边界

「系统代理」只是向操作系统登记一个 HTTP 代理地址,只有主动读取这项系统设置的程序才会走代理——浏览器和多数常见桌面软件会读,但命令行工具、部分聊天与游戏客户端、不少后台服务从来不读。这不是故障,是机制边界。判断方法:浏览器走代理正常、某个特定软件不走,基本可以断定是该软件不读系统设置。

让命令行走代理

终端里的 git、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:7890

Windows 的 PowerShell 用 $env:https_proxy="http://127.0.0.1:7890" 等价设置。需要长期生效再写进 shell 配置文件,排查阶段建议只做临时设置,避免忘记清理造成新问题。

顽固程序交给 TUN 模式

TUN 模式创建一块虚拟网卡,在网络层接管全部 TCP/UDP 流量,不依赖程序自觉,是解决「某软件死活不走代理」的通用方案。两种方式的对照:

系统代理开关开了却没写进系统

少数情况下客户端显示已开启、系统设置里却是空的:多为权限不足或被其他软件反向覆盖。以管理员身份运行客户端重试;仍不行就检查是否有安全类、网络加速类软件在开机后重写代理设置,与它们的冲突只能二选一。

八、客户端崩溃与异常退出

启动即退:先查配置解析

点开就闪退、或托盘图标一闪而没,首先怀疑配置文件解析失败。YAML 对缩进与冒号后的空格极其敏感,手动编辑过配置的重点回查。定位方法:找到客户端日志文件(通常在客户端数据目录的 logs 子目录),看最后几行的 error 记录,解析错误会给出行号;或者把订阅切换回未改动的版本、用第一章的最小配置启动,能起来就证明是配置问题。

端口被占用

内核启动时监听端口被其他进程占着(常见于上一个内核进程没退干净、或另一个代理软件在跑),会启动失败或反复重启。查占用:

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

查到占用进程后结束它,或在客户端设置里把 mixed-port 改成一个空闲端口(比如 7891)再启动。改了端口的话,第七章里所有写死 7890 的地方同步替换。

缓存损坏与干净重装

运行中随机崩溃、界面白屏、设置改不动,可尝试清理客户端缓存:退出客户端,进数据目录删除缓存类子目录(名字通常含 cache),保留 profiles(订阅与配置)不动,再启动。仍不稳定就干净重装:先备份 profiles 目录,卸载后手动删掉残留的数据目录,再从下载页取当前版本安装,装好后把备份的订阅文件导回去。不同客户端之间的稳定性与功能差异,可参考选型指南换一个客户端交叉验证。

崩溃规律的记录方法

偶发崩溃最难查,建议记三样东西:崩溃前在做什么操作、当时开没开 TUN、日志文件最后二十行。带着这三样信息,无论是自查还是向社区求助,效率都高一个量级。

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

Android:VPN 授权与后台存活

Android 客户端(首推 Clash Plus,备选见下载页 Android 区)通过系统 VPN 接口接管流量,首次启动必须同意「创建 VPN 连接」的系统弹窗;当时拒绝了的,去「系统设置 → 网络 → VPN」里删除该应用的条目再重新授权。连接图标(状态栏钥匙/VPN 标志)在、但流量不走,则检查客户端内的分应用代理设置——黑名单模式下被排除的应用、白名单模式下没勾选的应用,都不会经过代理。

「用着用着断了」几乎都是系统省电机制杀后台:国内定制系统(MIUI、ColorOS、HarmonyOS 等)默认激进回收后台进程。处理三件套:把客户端加入电池优化白名单(设为「无限制」)、在多任务界面锁定该应用、允许自启动。三项都设置后仍频繁断,在客户端里打开「常驻通知」类选项提高进程优先级。

iOS:Network Extension 的内存约束

iOS 客户端经 App Store 分发,首推 Clash Plus(下载页 iOS 区直接给出商店链接)。iOS 的代理运行在 Network Extension 里,系统对这个扩展进程有严格的内存上限——订阅里节点数量过多、规则集过大时,扩展进程会被系统直接终止,表现为「VPN 图标出现一两秒就消失」或频繁自动断开。处理办法:请服务商提供精简版订阅,或用转换服务裁掉用不到的地区节点与冗余规则集,把配置体积压下来;规则模式下优先用 GEOIP/GEOSITE 这类紧凑规则,少用几万行的明文列表。

另一个 iOS 常见现象:切换 Wi-Fi 与蜂窝网络后短暂无网。这是 VPN 隧道随网络切换重建的过程,等待几秒即可;长期不恢复就在客户端里手动重连一次。

移动网络与 Wi-Fi 的行为差异

同一部手机,Wi-Fi 下正常、蜂窝网络下节点全超时(或反过来),说明其中一个网络对代理流量有干扰,与客户端无关:运营商网络可能屏蔽特定端口或协议,公共 Wi-Fi 可能有强制门户与拦截。用这个差异做交叉验证,可以快速把问题归到「网络环境」而不是浪费时间重装应用。移动端首次安装的完整流程与权限设置顺序,博客里有整篇梳理:Clash 客户端首次安装全流程。

十、规则命中校验与配置回滚

还有一类问题不表现为「断网」,而是「走错了出口」:国内站点绕道境外导致变慢、境外站点被判定直连而打不开、某个应用始终不走代理。这类症状排查的关键不是重装,而是确认某条流量实际命中了哪条规则,以及这条规则是谁写进配置的。

用日志确认实际命中的规则

把日志级别调到 info 后访问目标站点,日志会给出「域名 → 命中规则 → 出口分组」的完整链路。若命中的是兜底规则 MATCH,说明前面所有规则都没匹配上,应检查域名写法是否用了通配符前缀、规则类型是否与实际请求形态对应(浏览器发出的是域名请求,应用直连 IP 时只有 IP 规则能命中)。若命中了一条你并不认识的规则,基本可以确定来自订阅自带的规则集,需要在自定义段落里用更靠前的规则覆盖它——Clash 规则自上而下匹配,先命中者生效,顺序比数量重要得多。

规则不生效的三种常见成因

• 顺序被抢:自定义规则写在订阅规则集之后,前面已经命中,后面的永远不会执行;把自定义段落整体提到规则列表最前端。
• 类型选错:用 DOMAIN-SUFFIX 去匹配一个只有 IP 的连接,或用 IP-CIDR 匹配尚未解析的域名请求;涉及 IP 的规则需要留意 no-resolve 参数是否该加。
• 分组指向错误:规则本身命中了,但目标分组当前选中的节点是「直连」或一个不可用节点;在代理页确认该分组的实际选中项,而不是只看规则文本。

改坏了怎么快速回滚

每次改配置前复制一份原文件并加上日期后缀,这是成本最低的保险。改完先用客户端的配置校验或重载功能确认 YAML 语法通过——缩进错一格、中文冒号混入英文冒号,都会让整份配置加载失败并退回上一次可用状态。若客户端已经处于加载失败、界面空白的状态,直接把备份文件改回原名重载即可;实在没有备份,就删掉自定义段落只保留订阅原始配置,先恢复可用,再逐条加回改动,每加一条验证一次,这样才能定位到究竟是哪一行引起的问题。