#Clash 疑难手册:按症状分章的故障排查大全

开启后无法上网:先分层,再动手

「开了 Clash 什么都打不开」是最常见也最笼统的症状。它可能出在四个完全不同的层级:本地网络本身断了、客户端没有真正在监听、系统没有把流量交给客户端、或者流量到了内核但规则把它引向了一个失效的出口。排查的第一原则是逐层缩小范围,不要一上来就重装客户端或换订阅。

第一步:确认本地直连正常

先把客户端的系统代理或 TUN 模式关掉,直接访问一个境内站点(例如运营商官网)。如果关掉之后也打不开,问题在路由器、网线或运营商,与 Clash 无关,先解决基础网络。如果直连正常、开代理后全断,继续往下。

第二步:确认端口在监听

Clash 系客户端默认在 7890 端口开混合代理(mixed-port,同时接受 HTTP 与 SOCKS)。用下面的命令确认端口确实被占着:

# Windows(PowerShell 或 CMD)
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

如果什么都没输出,说明内核没启动成功——多半是配置文件解析失败或端口被别的程序占用,直接跳到客户端崩溃一章。如果端口在监听,用 curl 走一遍代理测试连通性:

curl -x http://127.0.0.1:7890 -sS -o /dev/null -w "%{http_code}\n" \
  https://www.gstatic.com/generate_204

返回 204 说明「内核 + 当前节点」这条链路是通的,问题出在系统代理层,去看系统代理不生效一章;返回超时或错误,说明出口本身有问题,继续看节点超时。

第三步:排除规则误伤

把客户端切到全局(Global)模式再试一次。全局模式跳过所有分流规则,把流量统一交给你手选的节点:如果全局能通、规则模式不通,说明是规则把目标域名分给了失效的策略组,或兜底的 MATCH 规则指向了 DIRECT。三种模式的分流逻辑差异可以读这篇笔记:规则、全局、直连三种代理模式怎么选。

第四步:看连接列表验证流量走向

多数客户端都带一个「连接」或「Connections」面板,逐条列出当前活跃连接的目标域名、命中的规则与最终出口,这是判断「流量到底有没有走代理」最直接的证据。保持面板打开,再访问一次打不开的网站,然后对照三种结果判断:列表里连一条相关记录都没有出现,说明流量根本没进内核,问题在系统代理或 TUN 接管这一层;记录出现了但「规则」一列显示 DIRECT,说明分流规则把它判成了直连,该补的是规则而不是换节点;记录显示的策略组与出口节点都正确却依然超时,问题就落在节点出口这一段。先花十几秒做完这一步,后面能省掉大量方向错误的尝试。

如果客户端界面没有连接面板,也可以用外部控制端口查看实时连接。内核默认在 9090 端口提供 RESTful 接口,配置里由 external-controller 指定,访问 http://127.0.0.1:9090/connections 即可拿到与面板同源的原始数据;设置了 secret 时需要在请求头里带上对应的令牌。这个接口同样能读到当前生效的规则列表与策略组状态,适合在图形界面卡死时做旁路诊断。

节点超时:分清「一个超时」和「全部超时」

客户端里的延迟数字来自对一个测试地址的 HTTP 请求耗时,常用的是 https://www.gstatic.com/generate_204。显示超时意味着这次探测在限定时间内没有拿到响应,原因可能在节点服务器、传输协议、本地网络对特定端口的干扰,也可能只是测试地址本身抽风。排查前先回答一个问题:是个别节点超时,还是所有节点一起超时?

全部节点同时超时

所有节点一起红,基本可以排除节点本身的问题,优先怀疑三件事。其一,本地直连是否正常——回到上一章第一步。其二,系统时间是否准确:多数加密协议对时间偏差敏感,手动改过时区或虚拟机时钟漂移都可能导致握手全军覆没,把系统时间设为自动同步再测。其三,订阅是否整体过期或被服务端封禁,登录订阅提供方的用户面板核对流量与到期时间,必要时按订阅失败一章重新拉取配置。

个别节点超时

单个节点超时最常见的原因就是那台服务器负载高或线路波动,换一个同地区节点即可。如果某个节点长期时好时坏,可以用 url-test 类型的策略组让内核自动选择当前可用的节点,写法如下:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港-01
      - 日本-01
      - 新加坡-01

interval 是自动重测间隔(秒),tolerance 表示新旧节点延迟差超过这个毫秒数才切换,避免在两个延迟接近的节点之间来回横跳。策略组的组织思路在教程页与相关文章里有更完整的说明。

延迟正常但实际用不了

读懂延迟数字的含义

界面上的毫秒数是一次完整 HTTP 请求的往返耗时,包含握手、加密协商与代理服务器转发,因此天然比 ping 出来的网络延迟大一截,同一节点相差几十毫秒完全正常,不必为此反复重测。真正值得关注的是稳定性:连续测五次,数字在小范围内浮动的节点,即便绝对值略高,实际体验也比「一次 80 毫秒、一次 900 毫秒」的节点好得多。另外,批量测速时客户端会同时向所有节点发起探测,短时间内的并发请求本身会互相挤占带宽,把结果整体拉高;想拿到准确数字,单独测目标节点即可。测试地址被目标地区限制访问时也会误报超时,可以把策略组的 url 换成一个在该地区可正常访问的 204 地址再看。

延迟测试只验证「能建立连接」,不验证带宽,也不验证 UDP。游戏、语音通话依赖 UDP 转发,如果协议或服务端没开 UDP 支持,会出现「测速绿色、游戏掉线」的错位现象;这类问题优先联系订阅提供方确认节点是否支持 UDP,客户端侧无法凭空修复。另外,延迟数字只反映「你到节点」这一段,节点到目标网站的那一段拥堵时,同样会出现延迟很低但网页打不开的情况,换一个出口地区通常立竿见影。

订阅更新失败:先看报错,再决定走直连还是走代理

订阅本质上是一个 HTTP(S) 地址,返回一份 YAML 配置或可转换的节点列表。更新失败时客户端一般会给出报错,不同报错对应完全不同的处理方式,不要盲目反复点更新。

手动验证订阅地址

客户端报错信息有限时,直接用 curl 模拟一次拉取,把问题从客户端剥离出来:

# 直连拉取
curl -sS -o sub.yaml -w "%{http_code}\n" "订阅地址"

# 走本地代理拉取
curl -x http://127.0.0.1:7890 -sS -o sub.yaml -w "%{http_code}\n" "订阅地址"

返回 200 且 sub.yaml 里能看到 proxies: 开头的节点列表,说明订阅本身健康,问题在客户端设置(常见是 User-Agent 被服务端拒绝,换一个客户端标识重试);两条命令一条通一条不通,则说明订阅域名在你的网络环境下被干扰,固定使用能通的那条路径即可——多数客户端在订阅编辑界面都有「使用代理更新」开关。

更新成功但节点没变化

部分客户端对订阅有本地缓存,更新后记得看一眼配置的最后更新时间戳。另外注意:手动改过配置文件里的分流规则后再点订阅更新,改动会被服务端下发的内容覆盖——需要长期自定义规则时,应使用客户端的「配置增强/合并脚本」类功能,而不是直接编辑订阅落地的文件。

速度慢:定位瓶颈在哪一段

「慢」是一条链路上任何一环的木桶效应:本地宽带上限、你到节点的线路质量、节点服务器带宽、节点到目标站点的线路,以及加密协议本身的开销。排查慢的问题,核心是先弄清慢在哪一段,而不是无脑换节点。

建立基准

先关掉代理测一次本地裸速,记下数字;再开代理、切到全局模式、选一个延迟最低的节点测一次。两个数字的差距就是「代理链路开销 + 节点瓶颈」的总和。如果裸速本身只有几兆,任何节点都救不了;如果裸速很高、代理后掉到十分之一以下,再继续往下分。

常见原因与对策

让不该走代理的流量直连

速度慢的隐形元凶经常是分流没做好:系统更新、游戏下载、网盘同步这类大流量本没必要绕道出口。在规则模式下确认这些域名命中的是 DIRECT,必要时手动补规则。地理类规则(GEOIP、GEOSITE)能否正确命中,取决于本地数据库是否新鲜,更新方法见这篇笔记:GeoIP 与 GeoSite 数据库更新方法。

DNS 问题:污染、泄漏与 Fake-IP 的取舍

相当一部分「规则不生效」「个别网站打不开」「首次打开很慢」的问题根子在 DNS。Clash 内核自带 DNS 模块,理解它的两种增强模式和 nameserver 的分层设计,能解决绝大多数疑难杂症。

症状识别

典型的 DNS 污染表现是:域名能解析出 IP,但那个 IP 根本连不上,或解析结果明显不属于目标网站;而 DNS 配置不当的表现是域名规则(DOMAIN-SUFFIX 等)命中正常、GEOIP 规则错乱,或者切换节点后仍访问到旧地址。用 nslookup 或 dig 对比本地解析与公共 DoH 的解析结果,可以快速确认是否被污染。

推荐的 DNS 配置骨架

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.windows.com"
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query

enhanced-mode: fake-ip 让内核用保留网段的虚假地址即时应答查询,省掉真实解析的等待,并保证域名规则精确命中——这也是多数客户端的默认模式。它的完整工作流程、与 redir-host 的差异,以及哪些场景必须排除,详见这篇拆解:Fake-IP 模式原理详解。

Fake-IP 的典型坑与排除名单

需要拿到真实 IP 的程序在 Fake-IP 下会出问题:局域网设备发现、NTP 时间同步、部分游戏登录器、需要回连的 P2P 应用。症状是这些程序拿到 198.18.x.x 的地址后行为异常。解决办法不是关掉 Fake-IP,而是把相关域名加进 fake-ip-filter,让它们走真实解析。改完配置后如果旧的虚假地址仍被系统缓存,Windows 下执行 ipconfig /flushdns,macOS 下执行 sudo dscacheutil -flushcache 清一次缓存。

系统代理不生效:哪些流量根本不理会系统代理

系统代理的本质,是在操作系统层面登记一条「HTTP/SOCKS 代理在 127.0.0.1:7890」的建议——注意是建议,不是强制。浏览器和多数现代应用会遵守,但命令行工具、部分老软件、以及 Windows 的 UWP 应用会无视它。理解这一点,一半的「不生效」就有了答案:不是代理坏了,是那个程序压根没打算走代理。两种流量接管方式的机制对比,推荐先读:TUN 模式与系统代理有什么区别。

Windows:UWP 回环限制

微软商店应用(UWP)默认被禁止访问本机回环地址,也就是说即使系统代理指向 127.0.0.1,商店版应用的流量也发不进 Clash。多数 Windows 客户端内置「UWP 回环助手/Loopback 工具」,勾选目标应用放行即可;也可以用系统自带命令手动放行,例如放行微软商店:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

# 查看当前已放行列表
CheckNetIsolation.exe LoopbackExempt -s

命令行与开发工具

终端里的 git、pip、npm、curl 不读系统代理设置,需要显式声明环境变量,或改用 TUN 模式整体接管:

# macOS / Linux(当前会话生效)
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

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"; $env:HTTP_PROXY="http://127.0.0.1:7890"

代理设置被抢或没写进去

开关「系统代理」后,去操作系统的代理设置页亲眼确认一次:Windows 在「设置 → 网络和 Internet → 代理」,macOS 在「系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理」。如果地址不是 127.0.0.1:7890,常见原因有:其他代理软件(或残留的驱动)在反复改写设置、macOS 上当前活跃的网络服务不是被写入的那一个(比如写了 Wi-Fi 但实际走有线)。杀掉冲突软件、确认网络服务顺序后重开开关即可。彻底绕开这一层麻烦的办法是启用 TUN 模式,用虚拟网卡在网络层接管全部流量,代价是需要管理员权限并留意与其他虚拟网卡类软件的兼容性。

客户端崩溃与启动失败:从日志找答案

客户端「点了没反应」「启动就闪退」「运行中突然断流」大多有明确的日志线索,盲目重装的命中率远低于先读一眼日志。各客户端都在设置或托盘菜单里提供「打开日志/应用目录」入口,排查前先把日志等级调到 info 或 debug 复现一次。

启动即退出:先查配置,再查端口

最常见的启动失败是配置文件解析出错——YAML 对缩进和冒号后的空格极其敏感,手动编辑后少个空格整份配置就报废。日志里会给出具体行号,按行号修复;改动较大时,可以先换回一份未修改的订阅配置验证客户端本身是否正常,从而区分「配置问题」与「程序问题」。第二常见的是端口冲突:7890 或 9090(外部控制端口)被其他程序占用,日志会出现 bind: address already in use 一类字样,用上文的 netstat/lsof 找到占用者,或在配置里改用其他端口。

运行中断流或崩溃

TUN 模式下突然断流,优先怀疑虚拟网卡驱动与其他网络软件(虚拟机、另一个代理工具、部分安全软件)冲突,日志中通常伴随网卡创建或路由写入失败的记录;系统睡眠唤醒后网络不恢复,是各平台都存在的老问题,重开一次 TUN 或系统代理开关通常即可恢复。内存持续增长导致被系统杀掉的情况,多见于订阅节点数量极大或规则集过多的配置,精简订阅、减少不必要的规则订阅集能显著缓解。

重置与更换客户端

确认是程序自身问题时,卸载后手动清理残留的应用数据目录再重装,比覆盖安装更彻底(记得先备份订阅地址)。同一份订阅在不同客户端之间是通用的,某个客户端在你的系统上水土不服时,直接换一个试试成本很低:各平台推荐顺序与差异见客户端对比,安装包统一从获取客户端页面拿,首选各平台的 Clash Plus。

移动端专项:Android 与 iOS 各有各的坑

移动端的故障模式与桌面端不同:系统对后台进程和 VPN 通道的管理更激进,问题往往不在配置,而在系统策略。本章按平台分开说。

Android:VPN 权限与后台存活

Android 客户端通过系统 VPN 接口接管流量,首次启动必须同意「创建 VPN 连接」的系统弹窗;如果当时点了拒绝,之后会出现「点启动没反应」——去系统设置的 VPN 管理里找到应用重新授权即可。第二大类问题是后台被杀:国产定制系统的电池优化会掐掉长期驻留的 VPN 服务,表现为「用着用着断了」「锁屏一段时间后失效」。解决办法是把客户端加入电池优化白名单、允许自启动与后台运行,并在最近任务里锁定。另外注意系统的「始终开启的 VPN」与「无 VPN 时阻止连接」选项:前者能提升存活率,后者在客户端异常退出时会直接断网,排查断网问题时记得看一眼这两个开关的状态。分应用代理(Access Control)配置错误也常被误判为故障——如果只有个别 App 不走代理,先检查它是否被排除在名单外。

iOS:按 App Store 渠道获取,注意配置体积

iOS 上通过网络扩展(Network Extension)实现接管,系统对这类扩展的后台内存限制很紧。订阅里节点数量过多、附带大量规则集时,扩展进程可能因超限被系统终止,表现为「连接开关自动跳回关闭」。对策是精简配置:让订阅方提供节点较少的精简版订阅,或在客户端里裁剪用不到的规则。iOS 客户端从 App Store 获取,首选 Clash Plus(官网 clashplus.io),商店入口与说明见下载页 iOS 区。切换 Wi-Fi 与蜂窝网络后短暂断流属于扩展重建通道的正常现象,数秒不恢复时手动重开开关即可。

另一条思路:让电脑替移动设备代理

电视、游戏机,或不方便装客户端的设备,可以走「一台电脑跑 Clash、全屋共享」的方案:开启 allow-lan 后,其他设备把代理指向电脑的局域网 IP 和混合端口即可。完整步骤(含 bind-address 取值与防火墙放行)见这篇笔记:Clash 局域网共享代理设置。

还没解决?下一步这样走

按症状章节走完仍未解决时,按这个顺序继续:第一,把日志等级调到 debug,复现一次问题,日志里的报错原文往往比现象本身有信息量得多;第二,做最小化验证——换一份干净配置、换一个客户端、换一个网络环境,三个变量各换一次,问题会被夹逼到具体环节;第三,去 常见问题 页按分类翻一遍短问答,很多细碎问题(开机自启、配置文件位置、模式切换不生效)在那里有直接答案。基础操作不熟的话,回到 使用指南 把主线流程重走一遍,不少「疑难」其实是某一步被跳过了。