C1 / 完全无法上网
无法上网:三刀切出问题层
开了 Clash 之后所有网站都打不开,先别急着换节点。病因大概率只有三类:本地线路本身断了、节点全挂了、规则把流量送错了地方。三刀切下去,十分钟内一定能把锅定位到某一层。
第一刀:退出代理,测本地线路
关闭系统代理或直接退出客户端,用浏览器访问一个平时秒开的国内站点。打不开,说明问题出在本地网络,和 Clash 一点关系没有——先修 Wi-Fi、路由器或宽带。能打开,说明线路正常,进第二刀。
这一步经常被跳过,然后对着客户端修一下午,最后发现是路由器欠费重启。先切直连,永远是排查代理问题的第一动作。
第二刀:切全局,排除规则
把客户端切到全局模式(GLOBAL),手动选一个平时表现稳定的节点,访问需要代理的目标站点。通了,说明节点没问题,问题在规则分流——切回规则模式,进第三刀。不通,说明问题在节点侧或本地入站,直接跳到 C2 节点超时继续。
全局模式只是排查手段
定位完记得切回规则模式。一直挂全局,国内流量也绕地球一圈,速度和流量都亏。全局与规则模式的取舍,
疑难解答里有单独一条。
第三刀:开日志,看规则命中
在配置里把日志级别调高,然后在客户端的连接/日志面板里观察:目标域名被哪条规则命中、送进了哪个策略组、策略组当前选的是谁。常见翻车现场有两个:兜底的 MATCH 规则指向了 DIRECT,该代理的流量全体直连;或者某条 DOMAIN-SUFFIX 写得太宽,把不该直连的域名劫去了直连。
# config.yaml:排查期把日志调详细,修完再调回去
log-level: debug
mode: rule
怀疑内核根本没起来?用命令直接戳本地入站端口(端口号以你配置里的 mixed-port 为准):
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204
期望返回 204。连 curl 都不通,说明内核没在监听——不是配置端口写错,就是进程压根没启动,跳到 C7 崩溃闪退。
三刀之外:两个容易被忽略的入站陷阱
三刀切完还是不通,再看两处入站细节。第一处是监听地址:多数配置默认只在 127.0.0.1 上监听,本机自己用没问题,但你若在另一台设备上填了这台机器的局域网 IP 当代理,请求会被直接拒绝,现象是「客户端明明连着,另一台电脑却完全打不开网页」。要给局域网共享,得把 allow-lan 打开,并确认 bind-address 没有把可访问范围锁死。
第二处是端口协议对不上。mixed-port 同时接受 HTTP 与 SOCKS5 两种入站,是最省心的写法;如果配置里只写了 socks-port,而浏览器扩展按 HTTP 代理去连它,握手阶段就直接失败,报错长相和「内核没启动」几乎一模一样。排查时先确认你填进去的那个端口到底提供哪种协议,再怀疑别的。
# config.yaml:一个端口全都收,省掉大半协议错配问题
mixed-port: 7890
allow-lan: false
还有一种隐形故障值得单独点出来:同一台机器上先后装过两个代理客户端,另一个还在后台监听同一个端口。此时你连上的其实是另一个软件,规则怎么改都不生效,日志里也看不到任何请求进来。C7 章的端口占用查法同样适用于这个场景,查出占用进程后把多余的那个彻底关掉再重试。
C2 / 节点超时
节点超时:全红和零星红是两种病
延迟测试一片红,先分型:所有节点全部超时,和个别节点超时,病因完全不同。全红多半是你这一侧的问题;零星红才是节点自己的问题。
全部超时:先查自己这一侧
- 订阅过期或流量用尽。登录服务商面板确认套餐状态。这是全红榜单上的第一大户,查它花十秒,值得排第一。
- 测速链接本身被拦。延迟测试用的 URL(常见是
generate_204 一类)如果在当前网络里被拦,所有节点都会显示超时,但实际都能用。换一个测速 URL 再测一轮,数字全回来了就是这个原因。
- 本地防火墙拦了内核。Windows 首次启动时的防火墙放行弹窗点了「拒绝」,之后内核发不出包,全部超时。到防火墙的应用放行列表里把内核进程放行。
- 系统时间偏差过大。部分加密协议对本机时间敏感,误差超出容忍范围握手直接失败。打开系统时间自动同步,校准后重测。
个别超时:节点自己的事
单个节点常年红,多半是服务器下线或线路劣化,换节点即可。某个地区的节点集体红,通常是该条国际线路故障或维护,等一等或换其他区域的节点。个别超时不值得修,值得换。
| 现象 | 大概率原因 | 处理 |
|---|
| 全部节点超时,面板显示套餐正常 | 测速 URL 被拦或防火墙拦内核 | 换测速 URL;放行内核进程 |
| 全部超时,浏览器还提示证书错误 | 系统时间偏差 | 开启时间自动同步 |
| 某地区节点整排红 | 线路故障 | 换区域,或等线路恢复 |
| 数字正常,实际连不上 | 规则送错出口 | 回 C1 第三刀看日志 |
延迟数字怎么读
延迟测试测的是一次 HTTP 请求的往返耗时,不是带宽。80ms 的节点可能跑不满 10Mbps,200ms 的节点反而可能满速——延迟决定「响应快不快」,带宽决定「下载快不快」,两码事。想让不同协议的节点延迟可比,可以打开统一延迟:
# config.yaml
unified-delay: true
tcp-concurrent: true
自动测速策略组里的 url、interval、tolerance 三个参数各管什么,博客有一篇实测:url-test、fallback、load-balance 三种策略组差异。
健康检查的节奏也会制造「假超时」
自动测速组会按 interval 周期性地对组内每个节点各发一次测速请求。节点多、间隔短,客户端就在持续制造大批短连接;在弱网、或者路由器会话表偏小的环境里,这些并发探测本身就会互相挤占资源,反而让延迟数字虚高,甚至整组一起显示超时。订阅里有上百个节点时,把 interval 从默认的几十秒放宽到 300 秒以上,数字往往立刻就干净了。
tolerance 是切换的防抖阈值,单位是毫秒:只有当另一个节点比当前节点快出这个数值,才真的切换过去。设成 0,两个延迟接近的节点会不停互抢,长连接被反复重建,体验上就是「网页时不时断一下、视频每隔几分钟缓冲一次」;设成 50 到 100,稳定性会明显改善,代价只是有时没选到理论上最快的那个。
还有一个容易误判的细节:延迟列表里的数字是上一次探测留下的结果,不是实时值。刚切换过网络环境(比如从 Wi-Fi 换到手机热点)时,列表里挂的可能还是旧网络下测出来的数字,红绿都不作数。手动点一次「测试全部延迟」,等一轮探测跑完再判断,比盯着旧值猜要靠谱得多。
C3 / 订阅失败
订阅失败:报错文案就是病历
订阅拉不下来,客户端抛出的报错关键词基本就说明了病因。先照表对号,再动手验证。
| 报错关键词 | 含义 | 处理 |
|---|
404 / not found | 订阅地址失效,或已被服务商重置 | 到服务商面板重新复制订阅链接 |
timeout / 超时 | 订阅域名在当前网络被拦,或接口响应慢 | 先用可用节点挂上代理再更新订阅 |
403 / forbidden | 服务商限制了请求方的 UA | 按服务商要求的客户端类型拉取 |
| invalid / yaml decode error | 拉到的内容不是合法配置 | 按下面的方法手动验证内容 |
手动验证订阅到底返回了什么
客户端的报错有时候太含糊,直接用命令把订阅拉到本地看一眼,一切都清楚了:
curl -sSL -A "clash.meta" "https://你的订阅地址" -o sub.yaml
head -n 20 sub.yaml
前几行应该是 YAML 结构(proxies:、port:、proxy-groups: 这类字段)。如果看到的是 <html> 开头,说明拉到了服务商的错误页或拦截页;如果是一整段没有空格的长字符串,说明返回的是 base64 编码的通用订阅,需要经过订阅转换才能给 Clash 用。
订阅转换的取舍
转换服务会经手你的订阅地址,而订阅地址等同账号凭据。能用服务商原生提供的 Clash 订阅,就不要转;必须转的,优先自建转换服务,退而求其次也只用自己信得过的实例。转换后节点全丢、策略组错乱,多半是转换模板和订阅格式不匹配,换模板重试。
订阅地址 = 账号凭据
别贴到群里,别填进来路不明的转换站,别截图带链接。泄露了就去面板重置订阅,旧链接立即作废。
更新成功但节点没变:缓存与更新时机
另一类容易被当成「订阅失败」的情况是:更新显示成功,节点列表却还是旧的。先看客户端里显示的订阅更新时间有没有前进,再看配置文件的修改时间。两个都变了而节点没变,那就是服务商那边还没把新节点写进配置,和客户端无关,等一等再更新。只有更新时间没变的,才是客户端真的没拉取成功,常见原因是自动更新的定时任务在系统休眠期间被跳过,手动点一次即可。
反过来还有一种更隐蔽的:订阅更新成功了,但你本地对配置做过手改(加了自己的规则、改了 DNS 段),更新时被服务商的原始内容整体覆盖,于是「本来好的忽然又坏了」。想同时保留订阅节点和自己的定制,正确做法不是直接编辑订阅生成的文件,而是用客户端提供的覆写机制(Merge / Script / 覆写配置这类功能)把自定义部分单独放一份,让它在每次更新后自动叠加上去。
更新频率也别设得太激进。几分钟一次地拉订阅,除了给服务商接口增加压力,还容易触发限流,返回 429 或者干脆被临时封禁,反而制造出「时好时坏」的假故障。一天一次,或者每次开机拉一次,对绝大多数人完全够用。
C4 / 速度慢
速度慢:先立基准,再谈优化
「慢」是最容易冤枉工具的症状。不建立基准,一切优化都是玄学。先做两次测速:一次直连,一次走代理。两个数字的差值,才是代理链路引入的损耗。
基准怎么读
代理速度只有直连的三成以下,值得往下查;只差一两成,那基本就是节点的物理极限——国际线路的带宽本来就比本地宽带贵得多,别指望代理测速追平直连。
三个常见瓶颈,按序排除
- 节点侧:带宽小、线路在晚高峰拥塞。换个时段测一次,白天快晚上慢,基本可以定性为线路拥塞,换节点或换套餐,本地怎么调都没用。
- 协议侧:不同传输协议的开销和抗干扰能力差异很大;UDP 被节点或线路限制时,视频通话和部分依赖 QUIC 的应用会明显退化。同一服务器上换协议对比,或确认节点是否支持 UDP 转发。
- 本地侧:路由器上已经挂了一层代理、电脑上又开一层,双重加密双倍损耗;老旧设备跑重加密协议 CPU 先到瓶颈。一层就够,别叠罗汉。
内核侧有两个不花钱的开关值得打开:并发握手能压低建连耗时,统一延迟让测速更接近真实体验:
# config.yaml
tcp-concurrent: true
unified-delay: true
高峰期慢的工程解法
手动换节点是战术,策略组是战略。把常用地区的几个节点编成一个自动测速组,tolerance 设一个防抖阈值,避免两个节点延迟接近时来回横跳:
proxy-groups:
- name: AUTO
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies: [节点A, 节点B, 节点C]
大流量下载类场景可以考虑负载均衡组把流量摊到多个节点上。三种策略组类型怎么选,看博客实测:url-test、fallback、load-balance 差异。
测速方法本身也会骗你
很多「代理速度只有几兆」的结论,其实是测法造成的。在线测速站会自动挑选距离最近的测速服务器,而你的流量此刻从境外节点出去,测速站选的服务器可能远在节点所在地的另一端,来回绕两趟,数字自然难看。判断代理链路是否正常,更靠谱的做法是固定用同一个测速目标、同一个时段、同一个节点连测三次取中位数,只比较相对变化,不迷信绝对值。
浏览器里的单线程下载也不适合当作带宽结论。单条 TCP 连接的吞吐受延迟和丢包影响极大,高延迟链路上单线程跑不满是物理规律;换成支持多线程的下载工具,同一个节点常常能翻好几倍。要评估节点的真实上限,用多线程下载一个大文件比刷测速网页更接近实际。
分流做对了,慢的感觉会少一半
体验上的「慢」很多时候不是带宽不够,而是本该直连的流量被送去了代理。国内的视频站、网盘、游戏更新一旦绕到境外节点,速度必然崩;反过来,该走代理的域名落到直连上,则表现为长时间转圈然后失败。检查规则顺序时记住一条:规则是自上而下第一命中即生效,把范围大的兜底规则写在前面,后面精确的规则就永远轮不到。
另一个常被忽略的开销是 UDP。视频通话、在线游戏、部分依赖 QUIC 的网站都吃 UDP;节点不支持 UDP 转发时,这些流量要么退化成 TCP、要么直接失败,主观感受就是「网页还行,通话卡成幻灯片」。这类症状不要往带宽上找原因,先确认节点的 UDP 支持情况,再决定是换节点还是把 QUIC 相关流量单独拒绝掉走回 TCP。
最后提醒一句取舍:本地能调的参数,总收益远小于换一条好线路。把 tcp-concurrent、unified-delay 打开、把分流规则理顺,该做;但反复折腾内核参数期待翻倍提速,不现实。基准测出来差距悬殊的,直接换节点或换服务商更省时间。
C5 / DNS 问题
DNS 问题:一半的「玄学故障」都在这
DNS 故障的典型长相:有的网站秒开、有的永远转圈;代理明明连通,检测站却显示解析出口是本地运营商;换个节点某些站就好了、某些站又坏了。这些看起来随机的现象,病根多半都在解析这一层。
两种解析模式,先弄懂再调
Clash 系内核有两种增强解析模式。redir-host 走传统路线:先把域名解析成真实 IP 再匹配规则,解析路径长,容易在本地这一跳泄漏。fake-ip 则由内核直接返回一个保留网段的「假地址」(默认 198.18.0.0/16),真实解析放到代理出口去做——建连更快,本地也不产生真实的明文查询,是目前更推荐的默认选择。
一份可以直接抄的 dns 配置
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "+.local"
nameserver:
- https://doh.pub/dns-query
fallback:
- https://1.1.1.1/dns-query
逐行说清:fake-ip-filter 是豁免名单,列出的域名不发假地址,留给局域网设备发现、打印机这类必须拿真实地址的场景;nameserver 走加密 DNS 处理常规解析;fallback 给境外域名兜底。两组分工,别把所有域名都塞进同一个上游。
泄漏自查两条路
代理连通不代表 DNS 没泄漏。快的路:打开在线泄漏检测站,看解析出口归属地是不是本地运营商。硬核的路:本地抓包,观察 53 端口有没有明文查询直接出网。两套手段的完整步骤和防泄漏写法,博客有一篇实操:Clash DNS 泄漏检测与 fake-ip 防泄漏配置。
fake-ip 的副作用与解法
fake-ip 不是没有代价:个别应用会把假地址缓存下来,关掉 Clash 切回直连后,这些应用拿着 198.18 开头的地址继续撞墙,表现为「关了代理反而上不了网」。解法是刷新系统 DNS 缓存:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
经验法则
游戏平台、局域网投屏、NAS 这类对真实 IP 敏感的域名,统统加进 fake-ip-filter。豁免名单宁可宽一点,别让打印机也去问代理要地址。
「有的站能开有的不能」的两条典型病根
这个症状几乎总能归到解析结果不对。第一条病根是上游分工错了:把境外域名交给国内的加密 DNS 去问,拿回来的往往是就近的、或者被污染的地址,连上之后不是打不开就是内容错乱。nameserver 负责常规与国内域名,fallback 负责境外域名,两组各司其职,别图省事只写一组。
第二条病根是解析和出口不一致。域名在本地解析出一个国内 CDN 地址,流量却从境外节点发出去,服务端看到的来源和解析结果南辕北辙,于是给你返回一个访问不了的节点。fake-ip 模式天然缓解了这个问题——真实解析交给出口去做,解析与出口自然一致,这也是它比 redir-host 更推荐的核心原因之一。
改完 DNS 一定要重新验证
DNS 配置改完不会马上见效:系统缓存、浏览器自己的内置缓存、以及内核里的解析缓存都可能还留着旧结果。验证顺序建议固定成三步:重启内核或重载配置,刷新系统 DNS 缓存,再关掉全部浏览器窗口重开。三步做完再测,才能确认改动到底有没有生效,否则很容易把「缓存没清」误判成「配置没用」。
还要留意浏览器的加密 DNS 开关。Chrome 与 Firefox 都有内置的「安全 DNS / DNS over HTTPS」功能,一旦开着,浏览器会绕过系统与 Clash 自己去问域名,你在 config.yaml 里写的一切都被跳过,泄漏检测也会显示出意料之外的出口。做 DNS 排查时,先把浏览器这个开关关掉,把变量减到一个。
C6 / 系统代理不生效
系统代理不生效:告示不是执法
先说透原理:「系统代理」只是操作系统贴出的一张告示——「建议大家走 127.0.0.1 的这个端口」。应用可以看,也可以装没看见。浏览器一般看,终端从来不看,部分客户端软件有自己的主意。所以这一章必须分对象排查。
浏览器不走代理
- 确认浏览器的代理设置是「使用系统代理」。Firefox 默认用自己的代理设置,不读系统的,需要手动指到
127.0.0.1 加对应端口。
- 代理类扩展会覆盖系统设置。装过 SwitchyOmega 一类扩展的,先禁用再测——扩展里残留的旧规则是这一症状的头号嫌犯。
- 换个浏览器交叉验证:A 浏览器通、B 浏览器不通,锅一定在 B 自己的设置里,别再折腾客户端。
终端不走代理
终端程序只认环境变量,不认系统告示。开着 Clash 用 curl、git、包管理器照样直连,是正常现象不是故障。给当前会话手动挂上:
# 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:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
注意 git、docker 这类工具还有自己独立的代理配置项,环境变量不一定全覆盖,连不上时去各自的配置文件里再确认一层。
TUN 模式:一次接管所有流量
不想逐个应用伺候,就上 TUN 模式:内核创建一块虚拟网卡,在网络层直接接管全部流量,谁都别想装没看见告示。代价是需要管理员权限或系统授权,首次开启会有安装虚拟网卡的确认步骤。开了 TUN 之后建议关掉系统代理开关,避免流量被处理两遍。浏览器与终端的完整分路排查记录,见博客:系统代理不生效的浏览器与终端分路排查。
TUN 也有它自己的失效方式。虚拟网卡装好了但路由没接管成功时,现象是「开了 TUN 跟没开一样」,多数发生在系统更新后驱动失效,或者设备上还装着别的 VPN 类软件抢占了路由表——把其他 VPN 客户端退干净,再重新开一次 TUN,大多能恢复。另一种是开了 TUN 之后局域网设备互访失效,原因是局域网网段的流量也被隧道接管了,把内网网段加进直连规则即可。
代理开关看着开着,其实早被顶掉了
Windows 上系统代理是写进注册表的一个全局设置,谁都能改。常见的顶掉场景有三种:另一个代理客户端启动时把它改成了自己的端口;某次异常退出没有把设置清干净,残留了一个已经没人监听的端口;企业设备上的策略脚本在登录时又把它刷回公司代理。判断方法很直接——去系统的代理设置页面,亲眼确认地址和端口跟客户端里显示的一致,而不是只看客户端里那个开关是不是绿的。
macOS 上则要注意「按网络服务分别设置」这件事:代理设置是挂在具体网卡上的,给 Wi-Fi 打开的代理,插上网线用以太网时并不生效。多网卡设备上遇到「换了个上网方式代理就失灵」,先去网络偏好里确认当前那张在用的网卡有没有配上代理。
还有一个必须知道的例外:绕过列表。系统代理设置里通常有一份「不使用代理的地址」清单,本机地址与内网网段默认在里面。有人为了排查随手往里加过通配符,之后就会出现「某些域名死活不走代理」的怪现象。这份清单是排查系统代理问题时必看的一栏,别只盯着端口。
C7 / 崩溃闪退
崩溃闪退:四步走,九成能救
客户端打不开或者启动秒退,九成落在三件事上:配置解析失败、端口被占用、上次异常退出留下的内核残留进程。按下面四步走,不要跳步。
第一步:看日志
闪退不是没有遗言,遗言都写在日志里。从客户端设置里找「打开日志目录」或「打开应用目录」,看日志最后几行。YAML 解析失败会直接指出行号和字段名,端口冲突会写明 address already in use,照着报错走,比瞎猜快十倍。
第二步:验配置
用客户端「新建空白配置」或恢复默认配置的功能启动一次。能起来,说明锅在你的配置文件——回到日志指出的行号修 YAML。高频错误就三种:缩进混用了 Tab 和空格、复制粘贴带进了中文引号、字段值该加引号没加。修不动就把订阅重新导一遍,让服务商的原始配置覆盖本地改动。
第三步:查端口
内核监听的端口被别的程序占了,启动直接失败。查一下谁占着(端口号换成你配置里的值):
# Windows
netstat -ano | findstr 7890
# macOS / Linux
lsof -i :7890
查到占用进程,要么结束它,要么给 Clash 换端口:改配置里的 mixed-port 为一个空闲值,保存重启。
第四步:清残留
上一次崩溃退出时,内核进程可能没跟着死,占着端口和 TUN 虚拟网卡,新实例一启动就撞车。手动清一次:
# Windows(进程名以任务管理器里实际显示为准)
taskkill /f /im mihomo*
# macOS / Linux
pkill -f mihomo
四步走完还不行,就走最后一条路:完全卸载后从下载中心重装最新版,让安装器把损坏的运行环境整个换掉。Windows 与 macOS 各自的高频崩溃场景对照,博客单独写了一篇:启动崩溃闪退的日志定位与修复步骤。
按平台补三条特有原因
- Windows:安全软件把内核当成可疑程序隔离,是最高频的原因之一——客户端界面能开,点连接就退,日志里内核部分空空如也。到安全软件的隔离区看有没有被拦下的文件,加信任后重装。此外,把客户端装在中文路径或含空格的深层目录里,个别版本会因为路径解析失败启动不了,换到简单的英文路径试一次成本很低。
- macOS:从非商店渠道下载的应用会被系统加上隔离标记,首次打开需要在「隐私与安全性」里手动允许;跳过这一步的表现就是双击没反应。TUN 或系统扩展相关的授权也必须在系统设置里点通过,否则内核起来一半就退。
- Linux:多为权限与依赖问题。TUN 模式需要相应的网络能力授权,直接以普通用户启动会在创建网卡时失败;发行版缺少必要的运行库时,终端里会给出明确的缺库提示,照着装上即可。
崩溃之后怎么留住证据
反复崩溃却抓不到原因的,把日志级别调到 debug 再复现一次,然后从日志末尾往上读。真正有用的信息通常在最后二三十行:解析到哪一行失败、哪个端口绑定被拒、哪个文件读不到。想给开发者反馈或者自己留档,记得同时保留三样东西——客户端版本号、内核版本号、以及触发崩溃前做的最后一个操作。缺了这三样,别人也帮不上忙。
如果崩溃只在导入某一份特定配置后出现,那基本可以断定是配置问题而不是客户端问题。此时最快的办法是二分法:把配置里的 rules 段砍掉一半启动一次,再砍一半,几轮就能定位到具体那条规则或那个字段,比逐行肉眼审查快得多。
C8 / 移动端专项
移动端专项:Android 和 iOS 各有各的脾气
手机端的故障和桌面端不是一套逻辑:Android 的坑集中在授权与后台管控,iOS 的坑集中在系统 VPN 框架的状态同步。分开说。
Android:三件事管住九成问题
- VpnService 授权。安卓端 Clash 靠系统的 VpnService 建本地隧道,首次连接必弹「连接请求」授权窗,必须点允许。误点了拒绝,去系统设置的 VPN 页面删除该应用的 VPN 配置,回客户端重连,授权窗会重新弹出。
- 省电白名单。国产 ROM 的后台清理相当勇猛,内核进程被杀等于断网,表现为「锁屏几分钟后网就没了」。把客户端加入省电白名单并允许自启动,是安卓端的必做项。各主流厂商系统的设置路径,博客整理了一份:VpnService 授权与省电白名单。
- 分应用代理。只让指定应用进隧道,其余应用直连。既省电,也能绕开个别应用与 VPN 隧道的兼容问题——某个应用一开代理就抽风,先把它踢出隧道试试。
安卓安装包从下载中心 Android 区取,首选 Clash Plus。
iOS:状态以系统设置为准
iOS 走系统的 Network Extension 框架,客户端从 App Store 安装,首推 Clash Plus。两个高频坑:
- 开关状态不同步。应用内显示已连接,状态栏却没有 VPN 图标——以系统为准,去「设置 → VPN」里手动拨开对应配置的开关。
- 旧配置残留打架。装过多个代理类应用的设备,系统 VPN 列表里会积攒多份配置,互相抢接管权。把不再使用的配置删干净,只留当前在用的一份。
移动端排查的三个通用动作
第一,先分清是「隧道断了」还是「解析坏了」。手机上没有 curl 那么方便,但可以用一个笨办法:直接在浏览器里访问一个纯 IP 的地址,如果 IP 能通、域名不通,问题就在 DNS 那一层,回 C5 处理;两者都不通,才是隧道本身的问题。
第二,善用流量统计。移动端客户端一般都有实时上下行速率显示。连接状态正常但速率长期为零,说明流量根本没进隧道——十有八九是分应用代理把目标应用漏掉了,或者系统把客户端的后台联网权限掐了。速率有跳动但网页打不开,才需要往节点和规则上找。
第三,换网络交叉验证。同一份配置,在 Wi-Fi 下正常、切到蜂窝就不行,大概率是运营商网络对某些端口或协议做了限制,换协议或换节点端口通常能解;反过来蜂窝正常、Wi-Fi 不行,那要怀疑路由器上的 DNS 劫持或另一层代理,先去路由器设置里看一眼。
移动端通用提醒
手机切换 Wi-Fi 与蜂窝网络时,隧道会重建,出现几秒断流属正常现象;持续断流才需要按本章排查。