Clash 故障排查大全

无法上网：先区分基础网络与代理链路

退出代理后，先验证原有网络

网页全部打不开时，先关闭客户端的系统代理与 TUN，再通过客户端菜单正常退出。确认系统代理没有残留，然后访问平时能够直连的网站。如果此时仍然失败，先处理无线连接、网关、校园网认证或宽带问题；代理客户端无法替代底层网络。公共无线网络常要求先完成登录，认证页面又可能被代理接管，所以应先退出代理完成认证，再回来测试。

如果退出后网络恢复，故障范围就收窄到代理入口、内核或配置。重新启动客户端，先不要同时打开所有功能。查看日志里是否出现配置加载成功、监听端口建立等信息；窗口正常显示，只能说明图形界面还在运行，不能证明内核已经启动。端口占用、配置语法错误和权限不足，都可能让界面存在但代理服务不可用。

用显式代理请求绕过系统设置

在设置中确认实际混合端口。下面以本机地址和端口 7890 为例；若客户端设置不同，应替换端口。命令指定 HTTP 代理，目的是把系统代理、浏览器扩展等变量暂时移出路径。Windows 使用 curl.exe，避免部分 PowerShell 环境把 curl 解析成其他命令；其他桌面系统通常使用 curl。

# Windows PowerShell
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

# macOS / Linux
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

出现连接本机端口失败，说明请求还没到远程节点，应检查内核是否运行、监听地址和端口是否对应。若已经建立代理隧道，随后远端连接超时，则继续查节点与规则。收到 HTTP 响应说明这一次请求走通了，但单个站点不能代表全部网络；还需补测真正打不开的目标，并在客户端连接记录中确认该目标使用了哪个策略。

检查规则、策略组与恢复顺序

进入代理页面查看当前策略组，确认没有选到 REJECT，也没有引用已经消失的节点。配置更新后，界面保留的旧选择可能不再适用。临时选择一个已知可用的策略进行对照；如果全局模式能访问而规则模式不能，重点查看命中的规则与最终出口，不要继续反复更换安装包。测试结束应恢复原来的模式，避免把临时状态当作最终修复。

只在启用 TUN 后断网时，先关闭 TUN，保留系统代理验证。如果系统代理可以工作，优先检查虚拟网卡权限、路由冲突和其他 VPN，而不是认定订阅失效。公司安全软件、虚拟机网络与另一款隧道工具都可能参与路由。不要直接删除全部网卡；先关闭冲突应用，保存工作后重启系统，再逐一恢复必要的网络工具。

恢复顺序建议：关闭 TUN → 关闭系统代理 → 正常退出客户端 → 检查系统代理残留 → 验证直连。重置整个网络栈应留到最后，并先记录静态地址、DNS 与企业网络要求。

最后复测应包含两类目标：一个原本能直连的站点，以及一个需要当前代理策略的站点。记录时间、模式、目标与结果，防止把网站自身故障误判为整个客户端故障。如果仍不确定，从常见问题确认系统代理和 TUN 的职责，再进入下一章定位具体超时阶段。

节点超时：分清解析、建连与握手阶段

先看超时发生在哪里

节点测速超时，不等于节点已经永久失效。测速过程包含解析服务器域名、连接服务器、协议握手、访问测试地址等多个环节，其中任何一步失败都会得到相似结果。先打开日志，手动发起一次测试，找到同一时间的记录。不要在一次测试里同时切节点、切网络和改 DNS，否则成功之后也无法判断是哪项修改起作用。

dial tcp 后跟 i/o timeout，通常表示某次 TCP 建连未在限定时间完成，但必须看地址是节点服务器还是最终目标。若是节点服务器，检查本地到服务器的网络路径；若是目标站点，可能已经过了节点接入阶段。connection refused 更接近目标端口主动拒绝连接，与静默丢包造成的超时不同，处理方向也不应混在一起。

核对订阅与服务器入口

先确认订阅是否正常更新、服务是否仍有效，再检查选中节点的服务器域名和端口是否与提供方当前配置一致。不要凭经验给协议补字段。TLS 的服务器名称、WebSocket 路径、传输类型等通常有对应关系，随意修改其中一项可能让 TCP 通了但握手失败。若节点来自订阅，优先重新获取原配置，手动修改前保留副本并记录原因。

可以使用系统工具确认端口连通性，但只测自己有权访问的服务器。Windows 的 Test-NetConnection 能观察 TCP 端口是否可达；这并不能验证代理认证、加密参数或目标网站。某些协议主要使用 UDP，仅凭 TCP 检测无法判断其健康程度。同样，服务器不响应 ping 也不代表代理端口不可用，不能把 ICMP 结果当作最终结论。

用交叉测试隔离网络与节点

保持客户端、配置和节点不变，把电脑从原无线网络切到手机热点，再访问相同目标。如果热点可用而原网络失败，重点查原网络的出口策略、UDP 限制或认证状态。如果两种网络都失败，再选择同一订阅内另一个入口不同的节点。多个节点若共用同一个服务器域名，它们并不是独立样本，全部失败仍可能只指向同一入口问题。

如果测速失败但网页能够正常打开，检查测速地址本身是否可达、是否被规则直连以及是否有访问限制。健康检查测的是指定地址，不是所有互联网服务。也不要通过不断拉长超时掩盖稳定故障；延长等待只适合确认网络确实较慢的情形，对错误端口、错误认证和无法解析的服务器域名没有实质帮助。

遇到 TLS 证书错误，先同步系统日期、时间和时区，再核对配置中的服务器名称。不要把跳过证书验证作为常规解决办法，这会削弱连接身份确认。详细记录的读取顺序可参照Clash 运行日志定位方法。向提供方反馈时，给出发生时间、接入网络与脱敏错误即可，不要发送完整订阅地址或认证字段。

订阅失败：检查下载、格式与配置加载

把获取失败与解析失败分开

订阅导入失败通常有两类：客户端没有取得内容，或者取得了内容却无法按配置解析。先看错误来自下载阶段还是加载阶段。HTTP 状态码、连接超时、证书错误属于获取线索；行号、缩进、未知字段、代理组引用不存在则更接近解析线索。如果界面只显示更新失败，应打开日志查看具体原因，不要马上把所有配置删掉重新导入。

从提供方复制完整订阅地址，注意聊天软件可能在末尾混入空格、换行或标点。某些链接包含访问凭据，整个地址都应当作敏感信息处理，不能放到公开论坛、在线搜索框或截图中。若地址已经公开，应到提供方撤销或重置。不要随意把私人订阅提交给不熟悉的转换网站，转换服务能够接触其中的节点与认证信息。

根据响应结果选择下一步

出现 401 或 403 时，先确认账户状态、链接有效性与提供方的访问要求；出现 404 时，检查地址是否已迁移或复制不完整；出现 429 时，停止连续点击，按服务提示等待。状态码只能提供方向，仍需结合响应内容判断。返回成功状态也不一定是配置，登录页、验证页或错误提示同样可能以普通网页返回。

浏览器可以下载而客户端失败时，要核对两者的出口路径是否相同。浏览器可能使用独立扩展、已登录会话或系统代理，客户端订阅更新却走直连；反过来也可能成立。只有在明确更新请求需要代理时，才启用客户端相应的订阅下载代理选项。已有节点全部不可用时，让订阅更新依赖这些节点会形成循环，应尝试可信的可用网络直连获取。

核对 YAML 结构与内核能力

文件已经下载后，先检查它究竟是 Clash YAML 配置，还是节点分享链接集合。二者不能简单互换。YAML 使用空格表达层级，不要混入制表符；带特殊符号的字符串应正确引用。界面提示某行错误时，连同它上方几行一起看，因为真正缺失的冒号、引号或列表标记，可能出现在报错行之前。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

这段只是顶层基础字段示例，不含节点与策略组，不能据此建立远程代理。合并时检查文件内是否已经存在相同顶层键，避免出现两段 rules 或两段 dns。规则引用的策略名称必须与代理组名称一致，名称中的空格与大小写也应保留。对 YAML 段落不熟悉时，可对照配置文件结构详解逐段检查。

如果错误指向不支持的协议或字段，确认当前运行的是哪种内核，而不是只看客户端窗口名称。图形客户端与内核有各自的功能边界，旧内核未必支持提供方新增的配置。需要更换时可到客户端页面，优先选择 Clash Plus，并按系统选择对应安装包。不要把新内核文件随意塞进旧客户端目录，除非该客户端明确支持这种更新方式。

自动更新覆盖手动修改也是常见来源。订阅文件通常由远程内容重新生成，持久自定义应使用客户端支持的覆写或合并机制，而不是不断改下载缓存。修复后执行一次手动更新，再重启内核复测，确认配置既能下载也能加载。保留最近一份可用配置，但别让失效订阅在后台高频重试，造成限流后又误判为新的网络故障。

连接速度慢：拆分延迟、带宽与应用行为

先明确是哪一种慢

打开网页前等待很久、下载吞吐低、视频中途缓冲和游戏操作延迟，是不同的问题。先描述可复现现象：是否只有首次访问慢，是否所有站点都慢，是否只在晚间发生，是否切换无线网络就恢复。节点测速通常衡量某个测试请求的完成情况，不能直接预测持续下载速度，更不能用一个延迟值解释所有应用体验。

保持节点与目标不变，先检查基础网络。笔记本离路由器较远、无线信道拥挤、后台云盘同步或系统更新，都可能占用带宽。用同一设备直连访问一个可用目标，再通过代理访问相同目标，记录多次结果。不要拿不同站点、不同文件和不同时间的下载速度直接比较；目标服务器的地域、限速与缓存策略本身就会造成差异。

沿着连接记录检查实际出口

确认应用请求真正经过预期策略。网页主文档、图片、视频分片和登录接口可能来自不同域名，命中不同规则，因此首页打开快不代表视频流也走同一路径。在连接记录中按应用或域名筛选，观察最终策略组与出口。若个别资源被错误分流，应修正规则，不能因为一个资源慢就长期把所有连接改成全局代理。

自动选择组也可能带来误解。策略组的检查地址、检查间隔与可用性判断决定了选择结果，未必覆盖当前业务。手动固定一个可用节点做短时对照，可以避免测试期间自动切换引入变量。节点切换之后，应用已经建立的长连接可能继续使用旧出口；应关闭相应页面或重连应用，再看新连接，而不是只观察按钮选中状态。

理解协议、UDP 与路径差异

部分浏览器和视频应用会尝试 QUIC，相关流量使用 UDP。若接入网络或节点不支持所需 UDP 转发，可能出现等待回退、部分资源加载慢或连接反复重试。先从日志判断协议，再确认节点与客户端是否支持对应能力。不要为了验证一个网页而全局封禁所有 UDP；可以在可控应用中暂时关闭相关协议做对照，测试结束恢复原设置。

只有 TUN 场景明显变慢时，要注意路由回环、路径 MTU 和网卡冲突。典型线索包括小页面可开、大文件传输停住、某种网络可用而另一种网络异常。先关闭其他 VPN，比较系统代理与 TUN 两条路径。调整 MTU 前应查客户端与内核文档，并保存原值；随意套用网上的固定数字，可能让另一条网络路径变差，无法形成稳定修复。

服务器距离、跨网互联和高峰拥塞也会影响表现。当同一节点在多台设备、多条接入网络上都对同一目标表现不佳，而其他节点正常，才更有理由向提供方反馈线路问题。反馈应包含测试时间、目标、连接方式与可重复现象，而不是只说速度很差。不要提供编造的吞吐数字，也不要把短暂峰值当成稳定带宽。

最后撤销用于测试的临时改动，包括全局模式、应用协议开关和手动固定策略。保留能解释问题的最少修改，连续观察真实业务是否恢复。批量替换 DNS、修改网卡参数、切换内核和重装客户端同时进行，看似迅速，却会失去可复现性，也让下一次网络切换后的问题更难定位。

DNS 问题：找出解析请求实际经过的链路

域名打不开时，不要先替换所有解析器

DNS 故障常表现为域名无法解析、部分站点首次访问卡住，或节点服务器本身找不到地址。先确认失败的是目标域名还是节点域名，两者可能使用不同解析路径。系统 DNS、浏览器安全 DNS、客户端内置 DNS 与应用自带解析器也可能同时存在。修改系统设置后仍无变化，不一定是设置失效，可能是应用根本没有使用那条路径。

在 Windows 可用 nslookup example.com，在有相应工具的 macOS 或 Linux 可用 dig example.com 观察系统查询结果。它们只能说明这次工具查询的路径，不能直接证明浏览器或 TUN 的解析行为。先记下查询使用的服务器、返回结果和错误，再对照客户端日志。别把不同解析路径得到不同地址一律视为异常，内容分发网络本来就可能按地域返回不同结果。

理解 Fake-IP 与真实地址的区别

Fake-IP 模式会给域名分配保留地址，并在内核中保存映射，随后根据映射恢复目标域名并执行路由。因此看到保留地址，不表示网站服务器真的位于那个网段。问题在于发起连接的应用是否仍经过维护该映射的内核。客户端退出后，如果系统或应用缓存了旧的合成地址，就可能暂时无法连接，需要恢复正常解析路径并清理相关缓存。

局域网设备发现、打印服务或某些要求真实地址的应用，不一定适合统一使用合成地址。应先确认具体域名与失败行为，再按内核支持的规则加入 fake-ip-filter，而不是把所有域名全部排除。过滤写法和策略能力需以当前内核为准；相关原理与适用边界见Fake-IP 与 redir-host 对照。

核对配置、上游与启动依赖

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

这段展示本机 DNS 监听与上游写法，上游是否可达仍取决于所在网络。监听 1053 不会自动让系统把所有 DNS 查询交给它；系统设置、TUN 的 DNS 接管或其他转发机制必须另外对应。不要在没有访问控制的情况下把 DNS 监听暴露到公共网络，也不要把本机回环地址直接填写成另一台设备的 DNS 地址。

使用加密 DNS 时还要考虑启动依赖：上游的域名可能需要先解析，上游连接又可能依赖尚未可用的代理。若形成循环，应根据内核支持的引导解析与节点域名解析字段分开处理，并先验证上游可达性。不要盲目添加一长串解析器来碰运气；更多上游会增加变量，错误路由仍然会失败。企业内部域名则通常应保留组织要求的解析路径。

IPv6 也应单独观察。域名同时返回 IPv4 与 IPv6 地址时，设备可能优先尝试一条实际不可用的路径。先比较两种地址族的连接结果，再检查路由、节点支持与客户端设置，不要把关闭 IPv6 当成所有 DNS 问题的标准答案。若确实为临时验证关闭，应记录原状态，并确认不会影响本地网络或其他服务。

清理缓存应放在修正解析路径之后。先停止应用重试，再按系统支持的方法刷新缓存、重新打开应用并产生新查询。仅反复清缓存，无法修复不可达的上游或错误的 DNS 接管。

最终验证应同时检查普通域名、原来失败的域名以及必要的内部域名。看到解析成功还不够，还要确认连接命中正确策略并完成请求。若错误只发生于浏览器，暂时对照其安全 DNS 与扩展设置；若只发生于 TUN，则回到 DNS 接管和路由链路，避免继续修改与当前故障无关的订阅节点。

系统代理不生效：检查入口、应用与路由边界

系统开关不等于所有流量都会经过代理

系统代理只是向遵循系统设置的应用提供代理入口。部分命令行程序、游戏、后台服务和带独立网络设置的应用不会读取它。因此浏览器可以访问、终端却失败，并不一定是客户端异常。先用第一章的显式代理命令测试本机入口；入口正常后，再确认目标应用支持系统代理、需要单独设置代理，还是确实需要通过 TUN 接管。

Windows 可在系统网络设置中检查手动代理地址和端口，macOS 应查看当前使用的网络服务对应的代理设置，Linux 桌面设置则取决于桌面环境与应用。无线与有线网络可能不是同一个设置对象，切换网络后不要只看旧页面。使用自动代理脚本的环境，还要区分脚本地址与手动 HTTP 代理，避免两套机制同时生效造成结果不一致。

核对本机监听与环境变量

本机通常使用 127.0.0.1 访问客户端端口；这与局域网地址有不同作用。只有其他设备需要接入时，才考虑 allow-lan 和监听范围。本机系统代理不生效时，打开允许局域网并不能修复错误端口。反而可能扩大访问范围，所以应先确保本机链路正确，再单独配置可信网络中的共享需求。

# 仅影响当前 macOS / Linux shell 及其子进程
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# 测试结束后恢复当前 shell
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

上述变量是给支持它们的程序读取的，不会强制全部流量改道。有些程序只读取小写变量，有些有自己的设置文件；应查看目标程序文档，而不是同时堆叠多套变量。这里 HTTPS_PROXY 的值仍可使用 http://，表示连接本机 HTTP 代理，再由代理建立隧道，并不是把目标网站降级为普通 HTTP。

排除多套代理互相覆盖

浏览器扩展、旧客户端、公司代理脚本和启动项都可能重新写入系统代理。如果开关刚打开又被改回，先退出其他代理工具，再检查后台进程和开机启动列表。浏览器扩展可暂时停用做对照，但不要删除企业强制安装的网络组件。受管理设备应遵循组织策略，不能通过停用安全服务来绕过本来就存在的限制。

需要 TUN 时，应先确认客户端支持、服务已安装且获得系统要求的权限。TUN 的作用与系统代理不同，它通过虚拟网络接口和路由处理流量，但仍受规则、DNS 与排除路由影响。不要把 TUN 理解为自动修复一切的总开关。开启后出现本地设备不可达，应检查局域网路由与排除规则，而不是直接把整个内网强制送往远程代理。

虚拟机、容器和子系统还有独立边界。容器内部的 127.0.0.1 指向容器自身，并不是宿主机；虚拟机的系统代理也未必继承宿主设置。应使用该环境支持的宿主访问地址，并按需配置监听范围和防火墙。不同网络模式的访问方法不同，不能把一条宿主命令原样复制到所有容器里。

确需让手机或电视使用电脑代理时，先确认两者在同一可信网络，电脑允许局域网访问，防火墙仅放行需要的来源。接入设备应填写电脑的局域网地址而非回环地址。操作细节可参照混合端口与局域网共享设置。测试完成后关闭不再需要的共享入口，避免忘记开放范围。

最终判断依据是目标应用的新连接是否出现在客户端记录中，以及它最终命中了什么策略。日志完全没有该请求，应继续查应用入口；日志已有请求但出口不对，应查规则；出口正确仍失败，再查节点。按这三个边界推进，比反复点击系统代理开关更容易得到可解释的结果。

客户端崩溃：分离界面、内核与系统组件

先识别退出的是哪一个部分

窗口消失、窗口卡住、托盘还在但代理失效，是三种不同情况。图形界面退出时内核可能仍在后台运行；内核退出时界面也可能继续显示。先在任务管理器或活动监视器中查看相关进程，再检查客户端日志的最后几行。记录故障发生在启动、导入配置、开启 TUN、更新订阅还是休眠恢复之后，这些触发点比笼统的崩溃描述更有价值。

先保存当前工作，正常退出客户端并检查后台是否仍有残留。不要在旧进程未退出时反复启动多个实例，这可能造成端口占用或配置锁冲突。若不得不结束进程，随后检查系统代理是否残留，确保不会因为服务已经停止却仍指向本机端口而断网。恢复直连之后，再开始收集信息和修复，避免边断网边重复下载造成混乱。

核对架构、安装位置与依赖

安装包应与系统和处理器架构匹配。Apple Silicon 与 Intel、Windows 的不同架构、Linux 的软件包类型不能只凭文件名相似就互换。到客户端下载页按平台选择，普通图形界面用户可优先考虑 Clash Plus；Linux 用户按页面清单选择合适客户端。不要为了寻找某个旧教程里的界面而优先安装已停止维护的程序。

首次启动就失败时，检查系统报告缺少的运行组件、权限或安装目录问题。Windows 的图形界面可能依赖系统 WebView 组件，Linux 可能提示缺少动态库，macOS 则可能给出应用权限与安全检查提示。应按客户端文档和系统提示处理，不要从陌生站点下载单个动态库，也不要全局关闭系统安全机制来让一个应用启动。

用最小改动隔离配置与状态

如果只在载入某份配置后崩溃，先备份配置与客户端数据目录，再切回已知可用的配置测试。禁用近期增加的覆写、脚本或外部规则，观察是否恢复。大体积规则集、过多连接记录和较高日志级别可能增加资源使用，但不能只看到内存上涨就断言泄漏；应结合触发动作、持续时间和系统资源趋势判断。

内核因配置错误退出时，通常会留下可定位的语法或引用错误；界面组件崩溃则可能需要系统事件或崩溃报告。不要把二者都通过删除所有配置处理。若客户端支持临时使用独立数据目录，可以在保留原数据的前提下做干净状态对照；如果不支持，应遵循其迁移说明，避免误删订阅、覆写规则和本地自定义设置。

重新安装不一定清除用户数据，也不一定修复旧配置。操作前先确认配置目录与程序目录的区别；卸载服务或清理数据前，保留可恢复副本，并记下需要重新授权的系统组件。

故障只在休眠唤醒后出现时，先观察网络接口是否改变、系统代理是否仍指向原端口、TUN 路由是否恢复。可先停止再启动内核，而不是立即重装。若网络切换会稳定触发，记录从有线到无线或从热点回到路由器的具体步骤，这类可复现路径更容易定位服务恢复和路由重建问题。

提交问题时，提供客户端名称、系统架构、内核信息、复现步骤与脱敏日志。删除订阅凭据、节点认证、个人路径中的敏感信息；崩溃报告也可能包含用户名和文件位置。调试日志只在短时复现期间开启，完成后恢复 log-level: info，避免持续写入大量记录，干扰日常使用与后续定位。

修复后至少验证一次正常退出、再次启动和网络重连，确认系统代理、配置加载与内核服务都能恢复。若新安装后仍然在相同步骤失败，应停止重复重装，回到可复现条件继续排查。保留一个能够直连恢复网络的操作路径，比不断更换客户端但没有记录更重要。

移动端专项：VPN 授权、后台限制与网络切换

先确认设备上的接管方式

手机端通常通过系统 VPN 接口接管流量，与桌面端填写本机 HTTP 代理的方式不同。首次开启时应在系统弹窗中允许相应 VPN 配置，并确认当前连接归属目标客户端。状态栏出现 VPN 标志只说明系统隧道已建立，不能证明订阅节点、规则和 DNS 全部可用。仍应在客户端查看新请求、命中策略和错误日志，再判断故障属于哪一层。

按系统从Android 下载区或iOS 下载区选择客户端，优先考虑 Clash Plus。iOS 可通过其 App Store 页面获取，官网为 clashplus.io。不同客户端支持的配置字段与系统能力并不完全相同，不能把桌面 YAML 中的所有 TUN 参数原样当成移动端必备选项。

Android：后台中断与应用范围

如果亮屏可用、锁屏一段时间后失效，先检查系统电池策略、后台活动和厂商的进程管理设置。只针对正在使用的客户端按需放宽限制，不要关闭整机全部省电功能。验证时保持同一节点，锁屏后再唤醒并查看日志时间线，区分应用被系统停止、隧道仍在但连接过期，以及无线网络进入休眠这几种情况。

部分 Android 客户端支持按应用选择代理范围。如果浏览器正常而某个应用不通，先查看它是否被排除、是否使用独立进程，或者是否属于工作资料中的另一个应用实例。始终开启 VPN 与阻止未经过 VPN 的连接等系统选项，也可能让断开的隧道表现为全机断网。先理解这些选项的效果，再按需要调整，避免把保护机制误认成节点故障。

iOS：授权、按需连接与配置兼容

iOS 开启失败时，先检查系统 VPN 配置是否存在、是否属于当前客户端，以及是否有其他应用正在建立隧道。已有配置可能来自旧安装或设备管理策略，不要直接删除不认识的企业配置。个人设备上若要重新授权，先在客户端停止连接，按系统提供的流程处理，再回到应用重新触发授权并观察提示。

若系统显示已连接但个别服务失败，检查配置导入是否完整、规则组是否需要手动选择，以及客户端是否支持订阅中的协议。移动端的兼容能力应以实际应用说明为准，配置能被导入并不保证所有字段都有相同语义。首次导入的操作顺序可参照iPhone 配置导入步骤，避免在授权未完成时先调整一大批规则。

无线网络与蜂窝网络分别验证

保持相同节点和配置，分别在无线网络、蜂窝网络上测试同一目标。只在某个无线网络失败时，先完成门户认证，检查网络是否隔离设备或限制特定传输；只在蜂窝网络失败时，留意运营商路径、IPv6 与数据使用限制。网络切换后，旧连接可能已经失效，应重新发起请求，必要时停止再启动隧道，而不是沿用切换前的页面结果。

如果手机使用的是电脑共享代理，排查方式又不同。手机设置里的代理服务器应是电脑的局域网地址，端口与电脑混合端口一致，且电脑不能进入休眠。无线网络的客户端隔离会阻止设备互访，蜂窝网络通常也无法直接访问家中电脑的私有地址。这种模式下手机不一定运行本地 VPN，不要用 VPN 状态标志判断共享是否成功。

最后检查应用自身缓存与已有会话。切换出口后，登录服务、视频播放或即时通信的长连接可能需要重新建立；关闭并重新打开目标应用，再查看新的连接记录。不要以一个应用恢复就认定全部解决，还应补测原来失败的服务。若需要求助，提供手机系统、客户端名称、网络类型与脱敏错误，按本页相应章节继续缩小范围。