Clash 故障排查手册

排查前准备:先固定变量,再动手

代理链路上的可变环节非常多:本地网络、客户端、内核、配置文件、订阅、节点服务器、目标网站,任何一环出问题表现都可能是「打不开网页」。排查的第一原则是一次只改一个变量,否则问题消失了也不知道是哪一步起了作用,下次复发只能从头再来。

动手前先记录四项基础信息

• 客户端与内核:用的是哪个客户端(Clash Plus、Clash Verge Rev、FlClash 等),内核是 Meta/mihomo 还是原版。内核差异会直接决定某些配置字段是否被识别,详见博客文章三种内核区别对比。
• 运行模式:当前是系统代理还是 TUN,分流模式是规则(Rule)、全局(Global)还是直连(Direct)。大量「时好时坏」的问题根源是模式选错。
• 配置来源:订阅链接导入、本地 YAML 文件,还是经过订阅转换服务处理过。转换过的配置要额外考虑转换模板引入的问题。
• 问题范围:是所有网站都打不开,还是只有部分网站异常;是所有设备都有问题,还是只有一台。范围越清晰,后面能跳过的章节越多。

把日志级别调到 debug

各客户端都提供日志面板,默认级别通常是 info,只记录连接建立与规则命中。排查阶段建议临时调到 debug:DNS 查询过程、规则逐条匹配、握手失败原因都会打出来。本地配置文件里对应字段:

log-level: debug   # 排查完记得改回 info,debug 日志量很大

二分定位法

拿不准问题在哪一层时,按「代价从小到大」的顺序逐层替换:先换节点(排除单节点故障)→ 再切全局模式(排除分流规则问题)→ 再换一份已知可用的配置(排除订阅问题)→ 最后换客户端或换网络环境(排除本机与本地网络问题)。每换一层测一次,问题在哪一层消失,故障就在哪一层。

↑ 回到目录

无法上网:开启代理后所有网站打不开

症状定义:客户端显示已连接,但浏览器访问任何网站都失败,包括原本直连就能打开的网站。这一类问题的关键是先分清「流量根本没进代理」还是「进了代理但出口不通」,两者的修法完全不同。

第一步:用 curl 直接测本地代理端口

绕过浏览器与系统代理设置,直接向本地端口发请求,可以立刻判断内核本身是否工作:

# 测国内可达地址(验证内核与直连规则)
curl -I -x http://127.0.0.1:7890 https://www.baidu.com

# 测 204 探测地址(验证代理出口)
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

结果分三种:两条都通,说明内核正常,问题在系统代理层,直接跳到第 7 章;第一条通、第二条超时,说明直连正常但代理出口不通,跳到第 3 章排查节点;两条都拒绝连接(connection refused),说明内核没在监听这个端口,继续往下。

第二步:端口没被监听的三种原因

• 配置解析失败,内核根本没启动。日志里会有 error 级别的 YAML 解析报错,常见于手改配置时缩进错位、或原版内核读到了 Meta 专有字段。修复配置或换用支持该语法的内核。
• 端口被其他程序占用。日志报 bind: address already in use。Windows 用 netstat -ano | findstr 7890、Linux/macOS 用 lsof -i :7890 找到占用进程,要么结束它,要么在配置里改 mixed-port 后重启。
• 端口只监听了 IPv6 或防火墙拦截。检查配置里是否写了非常规的 bind-address;Windows 首次运行时如果拒绝了防火墙授权弹窗,需要到「Windows 安全中心 → 防火墙 → 允许应用通过防火墙」里手动放行客户端。

第三步:排查「关闭代理也上不了网」的残留

客户端异常退出(崩溃、被强杀)时可能来不及还原系统代理,导致系统仍指向一个已经不存在的 127.0.0.1 端口,表现为「不开 Clash 反而没网」。修法:重新启动客户端并正常退出一次让它还原设置;或手动清理——Windows 在「设置 → 网络和 Internet → 代理」里关闭手动代理,macOS 在「系统设置 → 网络 → 详细信息 → 代理」逐项取消勾选。TUN 模式异常退出偶尔会残留虚拟网卡路由,重启系统即可清空。

↑ 回到目录

节点超时:延迟测试全部失败或大面积飘红

客户端里的延迟测试并不是 ping,而是通过该节点向一个探测 URL(通常是返回 HTTP 204 的地址)发起完整请求并计时。因此「超时」意味着完整代理链路——本机 → 节点服务器 → 探测地址——中至少一环断了。

全部节点超时的排查顺序

1. 先确认本地网络:关掉代理直接访问一个国内网站。本地断网时所有节点必然超时,这是最容易被忽略的一步。
2. 确认订阅是否到期:服务商到期或流量用尽后,服务端会拒绝认证,所有节点同时超时是典型特征。到服务商的用户面板核对状态,不要在客户端里空耗。
3. 核对系统时间:部分加密协议对时间偏差敏感,设备时间与标准时间相差过大时握手会静默失败。手机与电脑都打开「自动设置时间」。
4. 换探测地址再测:探测 URL 本身被墙或抽风时,好节点也会显示超时。在客户端设置里把测试地址换成另一个 204 端点再测一轮。
5. 更新订阅:服务商更换了服务器 IP 或端口后,旧配置里的节点自然全部失效。手动更新订阅拉取最新节点列表,更新失败则转第 4 章。

部分节点超时:正常现象与异常的分界

机场节点存在个体故障是常态,少数节点超时无需处理,切换到可用节点即可。需要警惕的是同一协议的节点集体超时——例如所有某种协议的节点全挂、其他协议正常,通常说明该协议特征在当前网络环境被针对,短期内换协议使用,并反馈给服务商。另一种模式是「有线超时、热点正常」或反之,指向本地网络对特定端口/协议的拦截,常见于公司、校园网环境。

读懂测试数值

还要注意:延迟低不等于速度快,延迟反映的是往返时间,带宽是否充足要看第 5 章的测速方法。自动选择组(url-test)会按周期自动重测并切换,频繁跳节点的问题也在第 5 章一并处理。

↑ 回到目录

订阅失败:导入报错与更新失败对照处理

订阅问题分两个阶段:第一次导入失败,多半是格式问题;之前正常、某次更新开始失败,多半是网络或服务端问题。先看客户端报什么错,再对号入座。

错误提示对照表

格式问题:先分清拿到的是什么

Clash 客户端只认 YAML 结构的配置,而市面上流通的订阅还有 Base64 节点列表与各协议专用格式。把 Base64 订阅直接喂给 Clash 客户端,得到的就是「解析失败」。区分方法很简单:在浏览器里打开订阅链接,返回内容以 proxies:、proxy-groups: 这类字段开头的是 Clash 格式;一大段无空格的字母数字是 Base64。格式差异与转换原理在博客文章Clash 订阅格式详解里有完整展开,包括自建转换服务的做法。

「时好时坏」的更新失败

订阅域名本身在部分网络环境下被干扰是常见情形,于是出现悖论:更新订阅需要代理,代理配置又来自订阅。多数客户端提供「通过代理更新」开关,按当前状态反着试:代理可用时开着更新,代理已失效时关掉直连更新。都失败时,用手机流量开热点给电脑更新一次,拿到可用配置先恢复代理,再切回正常网络。另外,部分客户端支持配置订阅自动更新间隔,设为每 12 或 24 小时一次即可,过于频繁的自动更新在服务端限流时反而容易触发失败。

↑ 回到目录

速度慢:连得上但带宽不达预期

速度问题的排查前提是建立基线:先关闭代理测一次本地裸速,再开代理测一次,两者对比才有意义。本地裸速只有 50 Mbps 时,任何节点都不可能跑出 200 Mbps。

定位瓶颈在哪一段

1. 多换几个不同地区的节点测速。所有节点都慢且慢得一致,瓶颈大概率在本地(路由器性能、运营商国际出口、Wi-Fi 信号);个别节点慢,是节点本身负载或线路问题,高峰期(晚间)尤其明显。
2. 对比协议开销。同一服务器上,带多层传输封装的协议(如 WebSocket + TLS 组合)吞吐低于轻量协议是正常物理开销,不是故障。
3. 检查是否套了双重代理。浏览器插件代理、系统里残留的其他 VPN 与 Clash 叠加时,流量绕两圈,速度砍半起步。排查期间关掉所有其他代理工具。

分流失准导致的「假性慢」

国内网站突然变慢,八成不是节点问题,而是这部分流量被错误地送进了代理。典型原因是 GeoIP/GeoSite 数据库过旧,新增的国内域名与 IP 段不在库里,规则匹配不到只好走了兜底代理。判断方法:开着代理访问国内网站,在客户端的连接面板里看这条连接命中的是 DIRECT 还是代理组。修复方法(更新 Geo 数据库、验证规则生效)在博客文章GeoIP 与 GeoSite 数据库更新方法里有逐步说明。

自动选择组的参数调优

使用 url-test 自动选择时,两个参数直接影响体验:interval 决定重测周期,tolerance 决定「新节点要比当前节点快多少毫秒才切换」。tolerance 不设或设得太小,会因为几毫秒的抖动频繁切换节点,每次切换都会断开现有连接,体感就是「网速一阵一阵的」。参考写法:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300      # 每 5 分钟重测一次
    tolerance: 60      # 新节点需快 60ms 以上才切换
    proxies:
      - 节点A
      - 节点B
      - 节点C

↑ 回到目录

DNS 问题:解析失败、污染与 Fake-IP 副作用

DNS 是代理链路里最隐蔽的一层:症状经常表现为「部分网站打不开」「第一次打开很慢之后正常」「显示的 IP 地址很奇怪」,而不会直接报 DNS 错误。理解 Clash 的两种 DNS 增强模式是排查前提。

fake-ip 与 redir-host 的区别

fake-ip 模式下,内核对每个域名查询立即返回一个保留网段(默认 198.18.0.0/16)内的假 IP,真实解析推迟到流量实际发出时在链路远端完成——延迟低、无污染,是当前主流客户端的默认;代价是本机拿到的 IP 不是真实地址,少数依赖真实 IP 的程序(局域网发现、部分游戏联机、某些银行客户端)会异常。redir-host 则先在本地完成真实解析再匹配规则,兼容性好但解析结果可能被污染。两种模式没有绝对优劣,按症状切换。

典型症状与修法

• 切换网络后大量网站打不开,重启客户端恢复:fake-ip 映射缓存与新网络环境不一致。多数客户端提供「清除 fake-ip 缓存」按钮,或直接重启内核。
• 局域网设备(打印机、NAS)访问异常:局域网域名被 fake-ip 接管了。在 fake-ip-filter 里排除本地域名,见下方示例。
• 关闭代理后 DNS 仍异常:TUN 模式接管过系统 DNS,异常退出未还原。重启系统网络服务或重启设备。
• 某些域名解析到明显错误的地址:上游 DNS 被污染,把 nameserver 换成加密 DNS(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"
    - "+.msftconnecttest.com"   # 系统联网探测走真实解析
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

这份基线的思路:国内加密 DNS 做主解析保证速度,境外 DoH 做 fallback,fallback-filter 按 GeoIP 判断解析结果归属——结果不在 CN 段时采用 fallback 的答案,规避污染。注意 fallback-filter 依赖 GeoIP 数据库,库过旧同样会误判,与第 5 章提到的 Geo 更新是同一件事。

↑ 回到目录

系统代理不生效:浏览器正常但部分应用不走代理

症状定义:客户端工作正常、浏览器一切正常,但某些应用(命令行工具、商店应用、游戏客户端)的流量完全没有经过代理。根源在于「系统代理」只是操作系统层面的一个建议值,应用可以读也可以不读,而不同类型的应用行为差异很大。

三类不读系统代理的应用

命令行程序:环境变量写法

# Windows PowerShell(当前会话有效)
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# Linux / macOS(写入 shell 配置文件可持久化)
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 验证
curl -I https://www.gstatic.com/generate_204

UWP 应用:解除回环限制

Windows 商店应用默认被禁止访问 127.0.0.1,系统代理指向本机端口时这类应用直接失联。用管理员权限执行 CheckNetIsolation LoopbackExempt -a -n=<包族名> 逐个豁免,或用图形化工具批量勾选。完整操作步骤、包族名查询方法与验证手段,见博客文章Windows UWP 应用不走代理怎么办。

一劳永逸:TUN 模式

TUN 通过虚拟网卡在网络层接管全部流量,应用读不读系统代理都无所谓,是解决「部分应用不走代理」的根本手段。启用要点:桌面端需要授予管理员/root 权限安装虚拟网卡服务;启用后建议同时开启内核的 DNS 劫持,否则应用自行指定 DNS 时分流会失准;与其他 VPN 软件的虚拟网卡互斥,同时只能开一个。Linux 环境下的 TUN 部署细节可参考博客文章Linux 安装 Clash 全流程。

↑ 回到目录

客户端崩溃:启动失败、闪退与资源异常

崩溃类问题先区分三种形态:一启动就退出、运行中随机闪退、以及没退出但内存/CPU 占用异常。三者的排查入口不同。

一启动就退出:几乎都是配置问题

客户端 GUI 启动依赖内核成功加载配置,配置解析失败时部分客户端会直接退出而不是报错。排查方法:先把配置目录里的活动配置换成一份最小可用配置(只留一个 DIRECT 规则),能正常启动就证明是配置问题,再逐段加回内容定位出错字段。最常见的触发点:

• YAML 缩进错误——手工编辑后多打或少打了空格,YAML 对缩进零容忍;
• 内核不匹配——配置里用了 Meta/mihomo 专有字段(如部分规则类型与出站协议),而客户端跑的是原版内核。字段支持范围对照见内核区别对比;
• 规则集/Geo 资源下载不完整——首次启动需要拉取外部资源,网络不通时部分内核会报错退出,先直连网络完成初始化。

运行中随机闪退

1. 查客户端日志与系统日志:Windows 看事件查看器的应用程序日志,macOS 看控制台的崩溃报告,定位是 GUI 崩了还是内核崩了。GUI 崩、内核还活着(端口仍可 curl 通)时,多为界面层问题,重装或换客户端;内核崩则重点查配置与资源。
2. 排查超大订阅:数千节点的订阅在低配设备上解析与延迟测试时内存压力很大,精简订阅或关闭自动测速后观察。
3. 与安全软件冲突:代理软件的行为特征容易被误报,把客户端目录加入安全软件白名单后复测。

内存/CPU 占用异常

连接数是占用的第一影响因子:P2P 下载这类会瞬间打开数千连接的场景,内存上涨是正常现象,连接释放后应回落。持续不回落时,检查是否开启了过密的自动测速(多个 url-test 组 × 短 interval × 大量节点 = 持续的测试风暴),把 interval 放宽到 300 秒以上。桌面平台若长期驻留,优先选择维护活跃的客户端——各客户端的维护状态与资源占用横向对比见横向评测页,已停止维护的客户端(如 Clash for Windows)遇到崩溃没有修复渠道,建议迁移到 Clash Plus 或 Clash Verge Rev。

↑ 回到目录

Android 专项:后台被杀、VPN 冲突与系统设置干扰

Android 端的代理客户端以系统 VpnService 形式运行,故障模式与桌面端有明显差异:桌面端的问题多在配置层,Android 端的问题一半出在系统对后台服务的管控上。本章以 Clash Plus、Clash Meta for Android、FlClash 等客户端的通用行为为准。

连接频繁自动断开:后台被系统回收

锁屏一段时间后代理断开、通知栏图标消失,是国产 ROM 激进省电策略杀掉 VPN 服务的典型表现。逐项设置:

1. 系统设置 → 电池 → 找到客户端 → 改为「不限制/允许后台运行」,关闭「自动管理」;
2. 最近任务界面给客户端上锁(多数 ROM 支持下拉或长按锁定),防止一键清理误杀;
3. 系统设置 → 应用 → 客户端 → 允许「自启动」与「关联启动」;
4. 在客户端内开启「开机自启动」并配合系统的 Always-on VPN(设置 → 网络 → VPN → 齿轮 → 始终开启的 VPN),被杀后系统会自动拉起。

VPN 通道冲突

Android 同一时刻只允许一个应用持有 VPN 通道。另一个 VPN 类应用(包括某些「加速器」「过滤广告」类工具)启动时,系统会静默掐断 Clash 的通道,客户端这边只看到「连接断开」。排查:设置 → 网络 → VPN 里查看当前活跃的 VPN 是谁,停用冲突应用。同理,「私人 DNS」(Private DNS)设置为指定主机名时,DNS 查询会绕开客户端的 DNS 模块,导致分流失准,排查 DNS 类问题时先把私人 DNS 设为「自动」或「关闭」。

安装与更新问题

• 提示「解析软件包出错」:下载的 APK 与设备架构不符。近几年主流机型一律选 arm64-v8a 版本,极老设备才需要 armeabi-v7a,各架构安装包在下载页 Android 区按客户端列出;下载中断导致文件不完整也会报同样的错,重新下载即可。
• 覆盖安装失败:签名不一致(例如从不同来源下载的同名应用)无法覆盖,需卸载后重装。重装前在客户端里导出配置,避免订阅丢失。
• 安装后 VPN 授权弹窗没出现:部分 ROM 会拦截授权弹窗,到系统 VPN 设置里手动为该应用完成一次授权。

抓日志:adb logcat

界面上看不出原因时,用 adb 抓运行日志。电脑安装平台工具并对手机开启 USB 调试后:

# 只看错误级别输出,观察断开瞬间的报错
adb logcat *:E

# 按应用包名过滤(包名以实际安装的客户端为准)
adb shell pidof com.github.metacubex.clash.meta
adb logcat --pid <上一步输出的进程号>

日志里出现 VpnService revoked 说明通道被其他应用抢占;出现内存相关的 kill 记录则回到本章开头处理省电策略。移动端如需系统化的初次配置流程,回到配置教程按步骤执行一遍,大部分「装完就不对」的问题在教程主线里已经规避。

↑ 回到目录

没有找到你的症状?

本页覆盖的是有明确复现路径的八类故障。如果问题不在其中:属于「第一次配置就没跑通」的,回到配置教程从头核对;怀疑是客户端本身能力限制的,对照横向评测确认所用客户端是否支持对应特性;需要更换或补装客户端的,前往下载页——全平台首推 Clash Plus,Android 端另有 Clash Meta for Android 与 FlClash 可选。协议、内核、订阅相关的背景知识与专题排查,持续更新在技术笔记。