Clash 故障排查大全

通用排查流程:先定位故障出在哪一层

「不能用」三个字的信息量太低。Clash 处理一条网络请求要经过四个环节:客户端与内核负责收发流量,系统代理决定哪些流量能进来,节点链路负责把流量送出境,规则与 DNS 决定每条连接具体怎么走。任何一环断掉,浏览器看到的都是同一个「无法访问」。排查的意义就是把故障钉到具体某一层再对症下药——层级判断错了,换十个机场也解决不了系统代理没写进去的问题。

第一层验证:日志与端口

打开客户端的日志页,等级调到 info。内核正常时能看到配置加载与端口监听的记录;日志一片空白或反复刷报错,说明问题出在客户端本身,直接去第八章。日志里几类关键词值得记住:bind 相关多为端口被占用,parse 相关是配置解析失败,dial 相关是节点连接失败。再用一条命令验证端口是否在听:

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

返回 HTTP 204 说明客户端、节点、规则整条链路是通的,故障在系统代理或浏览器层;超时或拒绝连接,则继续往下查节点与规则。这条命令是全手册复用率最高的一步,建议记牢。

这条命令还有几个值得记住的变体:把端口换成 7891 可以单独验证 SOCKS5 端口;把 -I 换成 -v 能看到完整的握手与响应头,TLS 在哪一步断掉一目了然;把目标地址换成一个纯 IP 的 HTTP 站点,可以绕开 DNS 单独验证转发链路。建议把这条命令连同自己客户端的实际端口一起记在笔记里——排查任何「连不上」类问题,它都是第一块试金石。

如果 curl 直接提示「无法连接到 127.0.0.1」,说明客户端的代理端口根本没有在监听:先确认客户端主界面显示的混合端口是多少(不一定是默认的 7890),再确认内核进程是否真的活着——任务管理器或活动监视器里找一下内核进程名,找不到就回到第八章处理启动问题。

二分排除法

三步把问题圈定到最小范围:换节点(排除单节点故障)→ 换网络(切手机热点,排除本地宽带阻断)→ 换设备(手机导入同一订阅,排除本机环境问题)。每步只改一个变量,结果立刻可读。三步全部做完,故障点基本只剩一个候选。

症状速查表

不想读流程的,直接按症状跳章节:

无法上网:代理已开但网页打不开

最高频的症状。客户端开关都开了,浏览器却全部超时。按下面的顺序走,每一步都有明确的「通过 / 不通过」标准,不要跳步。

第一步:验证客户端到节点的链路

用上一章的 curl 命令验证。通过,说明客户端、节点、规则都没问题,直接跳到第三步查系统代理;不通过,继续第二步。

第二步:检查代理模式与节点

客户端一般有三种模式:全局(所有流量走代理)、规则(按规则分流)、直连(全部不走代理)。误触「直连」的表现就是「开了等于没开」。先切到全局模式再测:全局能开网页,说明链路正常,是规则把目标站分流到了直连或失效的节点组,回头整理规则与策略组;全局也不行,换一个节点再测,全部节点都不行就按第三章处理。

第三步:检查系统代理是否真正写入

Windows:设置 → 网络和 Internet → 代理,「使用代理服务器」应处于打开状态,地址 127.0.0.1,端口与客户端混合端口一致(默认 7890)。被安全软件或同类工具改回去的情况很常见。macOS:系统设置 → 网络 → 当前网卡 → 详细信息 → 代理,确认网页代理与安全网页代理的勾选状态和端口。这一项的深入排查见第七章。

第四步:防火墙与安全软件

Windows 防火墙或第三方杀毒可能拦截内核进程联网:首次启动时弹过的「允许访问」如果点了拒绝,客户端看起来在跑、实际一个包都出不去。在防火墙允许列表里放行客户端与内核进程,或者重装一次客户端并在弹窗时点允许。

macOS 上也有同类问题:系统防火墙开启「阻止所有传入连接」时,部分客户端的本地端口会被一并拦掉;企业设备上的 MDM 描述文件可能直接锁定代理设置,普通用户改不动。Linux 桌面用户则要留意发行版自带的防火墙(如 ufw、firewalld)是否放行了本地回环流量——回环接口默认放行,但被自定义规则改写过的环境需要手动确认。

第五步:浏览器自身的代理与扩展

系统代理确认无误之后,问题可能还在浏览器内部。代理切换类扩展(SwitchyOmega 等)会覆盖系统设置,先停用再测;浏览器的「安全 DNS」功能会让域名解析绕过客户端,表现为「能连但内容不对」;个别浏览器支持独立的代理配置,检查是否被设置成了「不使用代理」。换一个从未装过扩展的浏览器(或开访客窗口)测一次,是最快的排除法。

第六步:换网络环境交叉验证

以上全部正常却仍打不开网页时,把电脑切到手机热点再测一次。热点下立刻恢复,说明故障在本地宽带或路由层:部分路由器固件会拦截非常用端口的出站连接,运营商也可能对代理流量做定向干扰。此时优先换协议特征不同的节点,或开启 TUN 模式绕开应用层的种种限制。

节点超时:延迟测试一片 Timeout

延迟测试全红先别慌,「全灭」和「个别超时」是两种完全不同的故障,处理路径也完全不同。

全灭:问题在本地或订阅

所有节点同时 Timeout,大概率不是节点集体宕机,而是:本地网络阻断(宽带、校园网、公司网对代理端口的封锁)、套餐到期或流量用尽、系统时间错误。先切手机热点测一次:热点下全部恢复,就是本地宽带的问题,换协议类型(如从 Trojan 换 Hysteria2)或换端口特征不同的节点。

系统时间偏差是隐形杀手

Trojan、VLESS、Hysteria 等协议都建立在 TLS 之上,握手时校验证书有效期。系统时间与真实时间差几分钟,所有 TLS 节点会集体握手失败,表现与节点全灭一模一样。校准命令:

# Windows(管理员终端)
w32tm /resync

# macOS
sudo sntp -sS time.apple.com

# Linux
timedatectl set-ntp true

校准后重启客户端再测。长期不联网对时的设备(软路由、长期关机的旧机器)尤其容易踩这一条。

个别超时:节点自身问题

只有部分节点超时,通常是节点宕机、被运营商针对性阻断,或该节点的协议特征被本地网络识别。直接换节点;同一地区全部超时再换地区。注意延迟测试的原理:客户端向测试 URL 发起一次 HTTPS 请求并计时,不是 ICMP ping——测试地址本身不可达时也会显示 Timeout,可以在设置里把测试 URL 换成更稳定的地址再确认一次。

套餐与订阅状态

机场套餐到期、流量耗尽时,订阅链接还在、节点列表也还在,但全部不可用。登录机场后台确认套餐状态;部分客户端能显示订阅返回的流量信息头,顺便核对。订阅本身更新不了的情况看第四章。

延迟测试本身的误报

延迟测试依赖客户端内置的测试地址(通常是某个 generate_204 端点)。测试地址被本地网络阻断时,所有节点都会显示 Timeout,但节点其实是通的——直接开全局模式访问一个境外站点验证,能打开就说明是测试误报。在客户端设置里把延迟测试 URL 换成另一个稳定地址,或把超时阈值从默认的 3 秒放宽到 5 秒,都能减少这类误报。高丢包线路上,UDP 类协议(Hysteria2、TUIC)的延迟测试也可能偶发超时,多测两次再下结论。

订阅失败:更新订阅报错

「更新失败」只是外壳,客户端一般会附带更具体的原因:网络错误(timeout、connection refused)、解析失败(yaml、base64)、HTTP 状态码(403、404)。先把报错读全,再对号入座。

验证订阅链接本身

把订阅链接原样粘进浏览器地址栏:能下载到一个文本文件,说明链接有效;403 多为 token 失效或套餐到期,404 是链接拼错或订阅被重置。手动复制容易漏字符、带空格,从机场后台重新复制完整链接。典型的订阅链接长这样:

https://example.com/api/v1/client/subscribe?token=xxxx

token 是访问凭证,泄露等于把套餐送人,排查时不要把完整链接贴到公开渠道。

订阅域名被阻断

订阅服务器域名本身被阻断时,直连更新必然失败。两条路:在客户端设置里开启「通过代理更新订阅」(各客户端叫法略有差异);或者先用一个临时节点连上代理,再更新订阅。更新成功之后,订阅里的节点就可以正常使用了。

格式与解析问题

订阅返回的内容必须是 Clash 可识别的 YAML 配置,或可转换的节点列表。机场如果只提供通用 v2ray 订阅,需要换用其「Clash 订阅」专用链接或订阅转换服务。自己手改过订阅文件的还要注意 YAML 缩进——缩进错了,报的就是解析失败。

自动更新间隔

节点列表会随机场侧调整变化,长期不更新会出现「节点全在但全不可用」的假象。在客户端设置里开启自动更新,间隔建议 24 小时上下,既不会太旧也不会频繁打扰。具体设置路径与更多失败原因的逐项排查,见博客专文《Clash 订阅更新失败的常见原因与自动更新设置方法》。

订阅转换服务的取舍

订阅转换能把 v2ray、SSR 等格式的节点列表转成 Clash 配置,也能合并多个机场的订阅。但转换意味着把订阅链接交给第三方:链接里的 token 会被对方看到,转换服务本身也可能记录节点信息。只在自己信任的转换服务上使用,敏感套餐尽量用机场官方提供的 Clash 专用订阅。转换后配置里的规则是转换模板自带的,未必符合你的分流习惯,导入后检查一遍规则段再启用。

多订阅并存时的冲突

同时导入多个订阅时,客户端一般按「配置」分别管理,切换配置才会切换节点组。新手常见的困惑是「更新了订阅节点却没变」——多半是更新的是 A 配置、当前激活的是 B 配置。养成一个习惯:更新订阅后确认当前激活的配置名,再刷新节点列表。

速度慢:能用但卡顿

慢是一种相对故障:链路是通的,但体验差。先定位瓶颈段,再决定换节点、换协议还是改规则。

三段瓶颈定位

一条连接的速度取决于三段里最窄的一段:本地到节点、节点自身带宽、节点到目标站。判断方法:同一节点下访问不同目标站——只有个别站慢,瓶颈在节点到该站的回程;所有站都慢,换节点对比,换节点后明显改善是节点带宽或本地到节点的链路问题,怎么换都慢就查本地网络与客户端本身。

延迟低不等于速度快

延迟决定「反应快不快」,带宽决定「路宽不宽」。晚高峰时低延迟节点照样拥挤。判断速度要看实际下载或视频加载表现,不要只盯着延迟数字选节点——延迟 50ms 的节点和 150ms 的节点,看视频可能没有任何差别。

策略组的选择

url-test 策略组自动选延迟最低的节点,但可能选中最拥挤的那个;负载均衡把连接分摊到多个节点,适合下载类场景;手动选择最可控——在延迟相近的几个节点里轮换试用,找到当前时段最稳的。目标站被规则分流到绕远路的节点组也会变慢:打开连接面板,看这条连接实际命中了哪条规则、走了哪个节点,必要时调整规则顺序或给该站指定固定节点。

协议与内核差异

基于 UDP 的新协议(Hysteria2、TUIC)在高丢包、高抖动的线路上明显比传统 TCP 协议抗卡;mihomo 内核对这两类协议支持完整,桌面端首推的 Clash Plus 与 Clash Verge Rev、FlClash 均内置 mihomo。内核与协议差异的更多说明,见博客《mihomo(Clash Meta)内核特性与原版 Clash 的区别》。

客户端自身的性能开销

规则数量巨大(几万条)的配置在低配设备上会明显拖慢连接建立速度:每条新连接都要顺序匹配规则,规则越多首包延迟越高。精简规则集、把命中频率高的规则前移,能直接改善「点开网页要转圈一秒」的体验。TUN 模式比系统代理模式多一层虚拟网卡转发,千兆宽带下跑不满速时,可以对比两种模式的实际吞吐再决定常驻用哪个。日志等级长期开在 debug 也会拖累性能,排查完记得调回 info 或 warning。

DNS 问题:解析异常与污染

典型症状

能连代理,但部分网站打不开;打开的网站是「错误的地区版本」;广告过滤规则时灵时不灵;nslookup 返回明显不合理的 IP。这些都指向 DNS 环节,而不是节点。

Clash 的 DNS 模块怎么工作

客户端内置 DNS 模块接管系统的域名解析,按配置的上游服务器查询,并配合规则决定「谁来解析、结果给谁」。两种工作模式:redir-host 返回真实解析的 IP;fake-ip 返回 198.18.0.0/16 段的虚拟 IP,连接建立时内核再按域名转发——解析快、天然抗污染,是多数客户端的默认模式。

配置示例

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com

nameserver 负责直连域名的解析,fallback 负责走代理的域名;fake-ip-filter 列出必须返回真实 IP 的域名(局域网设备、部分对 IP 敏感的应用)。改完 dns 段必须重启内核或重载配置才生效,多数客户端在设置里有一键入口。

改完配置清缓存

系统与浏览器都会缓存 DNS,旧缓存不清,新配置看起来就像没生效:

DNS 泄漏自查

代理开启后访问 DNS 泄漏测试站点:看到的解析服务器应当是代理出口或配置的上游,而不是本地运营商。出现本地运营商 DNS 时,检查系统 DNS 是否被写死、浏览器是否开启了「安全 DNS」绕过系统解析。

IPv6 引入的解析分叉

宽带同时下发 IPv4 与 IPv6 时,系统可能优先走 IPv6 解析与连接,而节点只支持 IPv4 出站——表现是部分站点时通时断、解析结果在两种协议间漂移。两种处理:在客户端 DNS 配置里过滤 AAAA 记录,强制只返回 IPv4 结果;或者在系统网络设置里临时关闭 IPv6 验证猜想。确认是 IPv6 引起后,再决定长期方案,不建议无脑全局关闭 IPv6。

局域网与特殊域名的处理

路由器管理页、NAS、打印机这类局域网域名,必须返回真实内网 IP 才能访问。fake-ip 模式下这些域名会被解析成虚拟段,直接打不开。把 *.lan、*.local 以及路由器的具体域名加进 fake-ip-filter,并确认规则里局域网段(192.168.0.0/16 等)走直连。公司内网域名同理,按实际后缀补充。

系统代理不生效:开关开了流量没走代理

先验证「生效」是什么状态

开启系统代理后,浏览器访问 IP 查询站,出口应显示节点所在地区;仍显示本地运营商,即未生效。验证动作只要十秒,先做了再往下查。

Windows:检查代理项被改写

设置 → 网络和 Internet → 代理:「使用代理服务器」应打开,地址 127.0.0.1,端口与客户端一致。安全软件、其他代理工具会改写这一项;客户端写入系统设置需要权限,必要时以管理员身份运行一次,让客户端拿到写入权限。

macOS:授权与代理项

系统设置 → 网络 → 当前网卡 → 详细信息 → 代理,确认网页代理、安全网页代理的勾选与端口。客户端首次开启系统代理时系统会弹授权请求,点过「不允许」就再也写不进去——在「隐私与安全性」设置里放行后重试。

浏览器层的干扰

SwitchyOmega 一类插件会接管浏览器代理,与系统代理叠加冲突,二选一即可。浏览器的「安全 DNS」会让域名解析绕过客户端的 DNS 逻辑,表现为「IP 变了但内容不对」,排查时先关掉再验证。

终端与开发工具不走系统代理

终端默认无视系统代理,需要显式环境变量:

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

git、npm、pip 另有各自的代理配置项,环境变量不一定全覆盖。浏览器与终端两条线的逐项排查,见博客专文《Clash 系统代理不生效的排查方法》。

终极方案:TUN 模式

TUN 模式用虚拟网卡接管整机流量,不依赖系统代理设置,对不遵守系统代理的应用(游戏、部分命令行工具)同样有效,也能绕开「代理项被改写」这类反复发作的问题。原理与开启步骤见博客《Clash TUN 模式开启教程》。

多代理工具共存的冲突

电脑上同时装着多个代理类工具(加速器、抓包软件、其他 VPN)时,系统代理设置会被反复改写,表现是「明明开了 Clash,代理项却指向别的端口」。只保留一个工具常驻,其余彻底退出(不是关窗口,是退出进程);抓包工具用完随手关代理,加速器不用时退出。企业 VPN 客户端尤其霸道,连接公司 VPN 期间系统代理基本不可用,这种场景直接用 TUN 模式或接受「VPN 期间不走代理」的现实。

验证清单:确认修复有效

修复后按三步确认:系统代理设置页里的地址与端口和客户端一致;浏览器访问 IP 查询站显示节点地区;curl 不带 -x 参数直接请求也能走通(说明系统代理对命令行同样生效,或至少浏览器链路完整)。三步都过,这一章才算真正闭环。

客户端崩溃与无法启动

先分清是谁崩了

界面闪退与内核启动失败是两回事。内核失败时客户端一般会给出明确提示(核心启动失败、端口占用、配置解析错误),先看提示再动手;界面本身打不开,则优先重装或换客户端。

端口占用

混合端口或外部控制端口被占用——常见占用者正是上一次没退干净的客户端进程——内核会直接起不来。查占用:

# Windows(管理员终端)
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

结束占用进程,或在客户端设置里换一组端口。改完端口记得同步检查系统代理设置里的端口是否一致。

配置文件语法错误

YAML 对缩进极度敏感:必须用空格、不能用 Tab,层级错一格就是解析失败。手改 config.yaml 之后,用客户端自带的配置检查或 YAML 校验工具过一遍。一个合法节点条目长这样:

proxies:
  - name: "节点A"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

权限与系统组件

Windows 上 TUN 模式、服务模式需要安装系统服务(客户端内一般有一键安装入口);macOS 首次开启增强模式需要授权;安全软件误报会隔离内核文件——加白名单后重装客户端即可。

配置文件损坏与版本升级遗留

客户端大版本升级后,旧配置目录里的缓存、数据库文件可能与新版本不兼容,表现为升级后打不开或一启动就闪退。处理顺序:先备份订阅链接与自定义规则,再退出客户端,把配置目录整个重命名(不要直接删),重启客户端让它生成全新目录,最后重新导入订阅。绝大多数「升级后崩了」都能用这套流程解决。配置目录的位置各客户端不同,一般在客户端设置的「打开配置目录」入口可以直达。

日志是崩溃排查的第一现场

客户端起不来时,界面日志可能看不到,但内核日志文件通常已经写在磁盘上。到配置目录或日志目录找最新的日志文件,从最后一行往前读:panic、fatal、error 三类关键词附近就是崩溃原因。把这几行原样保存下来,无论是自己继续查还是向别人求助,都比「它崩了」三个字有用得多。

重置与重装

配置目录损坏的通用解法:备份订阅链接 → 退出客户端 → 重命名配置目录 → 重启客户端重新导入。仍无法解决就换客户端:Windows 与 macOS 首推 Clash Plus,备选 Clash Verge Rev、FlClash;Clash for Windows 与 ClashX Meta 已停止维护,新装不建议继续使用。全平台客户端清单在下载页。

移动端专项:Android 与 iOS

Android:后台被杀是第一死因

国产 ROM 的电池优化会清理 VPN 常驻进程,表现是锁屏一段时间后代理「自己关了」。处理路径:系统设置 → 应用 → 找到客户端 → 电池 / 耗电管理,设为「不优化」或「允许后台活动」;在最近任务界面锁定客户端;允许自启动。Clash Meta for Android、FlClash、Surfboard 都在下载页 Android 区,Clash Plus 为全平台首推。

Android:VPN 槽位互斥

系统同一时间只允许一个 VPN 工作。其他 VPN 或加速器占着槽位时,客户端启动会失败或直接顶掉对方。用客户端的分应用代理功能缩小接管范围,也能减少与其他工具的冲突面。

iOS:Clash Plus 与系统托管

iOS 端从 App Store 安装 Clash Plus(官网 clashplus.io)。iOS 的 VPN 由系统托管,锁屏后一般保持连接;低电量模式与关闭「后台 App 刷新」会影响订阅自动更新与保活表现,遇到「放着放着不更新」先查这两项。

与桌面端配置互通

订阅链接全平台通用:同一份机场订阅可以同时导入手机与电脑,规则与分流逻辑一致。本手册前面各章关于 DNS、规则、协议的结论对移动端同样成立,差别只在系统层的保活与权限。

移动网络特有的断流场景

地铁、电梯、基站切换时,移动网络会经历短暂的完全断连。VPN 隧道对断连的容忍度因协议而异:TCP 类协议断连后需要重新握手,恢复慢;Hysteria2、TUIC 这类基于 UDP 的协议有会话保持机制,网络恢复后几乎无感续传。经常在通勤路上使用的话,优先选 UDP 类协议的节点。Android 的「始终开启 VPN」与「屏蔽未走 VPN 的连接」两个选项一起开,能在断连期间避免流量裸奔,代价是断连瞬间完全无网。

热点共享与代理的叠加

手机开热点给电脑用时,电脑端的流量默认不会经过手机上的代理——热点转发发生在系统底层,绕开了 VPN 应用。想让电脑也走代理,要么电脑上自己装客户端导入同一订阅,要么在支持「热点共享代理」的客户端里开启对应功能(部分 Android 客户端支持,需要 root 或特定系统版本)。iOS 个人热点不支持叠加 VPN 代理,只能电脑端自行解决。

移动端症状速查