Clash 故障排查大全

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

先关闭客户端里的系统代理与 TUN 模式，再打开一个平时能够直连的网站。TUN 是通过虚拟网卡接管流量的方式，关闭它可以先把诊断范围缩回普通网络。若直连也失败，先处理无线连接、宽带登录、校园网认证或路由器故障。此时反复切换节点只会增加干扰，因为代理服务器仍然依赖设备已有的网络出口。

确认内核启动，再检查监听端口

打开客户端日志，寻找本地代理端口开始监听的记录。图形界面能打开，不代表 mihomo 内核已经运行；内核负责解析配置并实际转发请求。若日志停在配置加载阶段，先阅读第一条错误，检查配置路径、字段缩进与端口冲突。不要只看最后一条退出信息，它通常只是前面错误的结果。记录实际端口，后面的测试必须与它一致。

使用独立安装的 mihomo 时，可以先执行下面的配置测试。该命令只检查指定目录里的配置是否能够加载，不代表远端节点已经可用。通过测试后再启动内核；如果使用图形客户端，应优先通过客户端重新启动内核，不要同时手动运行第二个进程，否则可能争用端口。图形客户端的工作目录也可能不是下面这个默认路径。

mihomo -d ~/.config/mihomo -t

绕过系统设置，直接测试本地代理

先用显式代理命令访问同一个网址。显式代理是直接告诉测试程序连接哪个本地端口，不依赖系统代理是否写入。下面的示例假定混合端口为七八九零，实际使用时以客户端设置为准。Windows PowerShell 可将命令中的程序名写成 curl.exe，避免不同终端对命令名称的解释不同。测试失败时，保留错误原文与对应时间。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com

沿日志还原请求经过

发起一次请求后，立即查看连接列表，确认目标域名、命中的规则和最终出口。规则模式会按规则选择代理或直连，全局模式通常把请求交给全局策略组，但仍要确认该组实际选中了什么。可以临时切到全局模式做对照；如果这样恢复，问题更可能在规则或策略选择，而不是整个网络。测试完成后恢复原来的规则模式。

若只有某个网站打不开，换一个独立网站验证，不要直接判定所有节点失效。目标服务可能要求登录，也可能拒绝当前出口地址。若退出客户端后所有网站都打不开，检查系统是否还保留着指向本地的代理地址；代理程序已退出而系统仍向它发请求，就会出现整机断网的表象。先清除残留代理，再继续诊断。

02 节点超时：区分探测失败、握手失败与出口异常

先确认超时出现在哪里。客户端的节点测试通常是通过节点请求某个探测网址，并不是对服务器做简单的网络回声测试。探测网址不可达、返回状态不符合预期、名称解析失败，都可能让测试显示超时。因此先手动选择一个节点，用浏览器访问实际需要的网站，再对照日志判断，不要只凭列表里的测试结果删除整份配置。

从单个节点与整组节点的差别入手

只测一个节点，再测同一订阅里另一个不同服务器地址的节点。如果只有前者失败，检查服务方状态、节点是否过期、连接参数是否刚有调整。若所有节点同时失败，优先排除本地网络、订阅账户、系统时间与公共解析问题。多个名字不同的节点也可能指向同一台服务器，因此换名字不一定构成有效的对照。

切换一次接入网络继续测试，例如从家庭无线网络切到手机热点，但要留意移动数据用量。如果相同配置在热点可用、原网络不可用，线索指向原网络的访问限制、路由或解析；如果两边都失败，再检查订阅和协议参数。不要同时换网络、换客户端又改配置，否则即使恢复，也无法知道是哪一项产生作用。

读取连接阶段，而不是只读错误结尾

查看日志中的服务器地址和失败阶段。本地解析失败表示尚未拿到服务器地址；连接被拒绝通常说明目标端口没有接受连接；连接超时可能涉及中间链路丢包或服务不可达；加密握手失败则应继续核对协议、服务器名称与认证参数。这些信息不能单独证明某个服务方故障，但可以决定下一步应该找本地配置还是远端服务。

检查操作系统日期、时间与时区，并开启正常的时间同步。基于 TLS 的连接需要验证证书有效期，设备时间偏差会产生看似网络故障的握手错误。若日志提示证书名称不匹配，先核对订阅是否完整、服务器名称是否由服务方要求填写。不要把跳过证书验证当作常规修复，它会掩盖配置错误并削弱连接认证。

# PowerShell：检查服务方给出的真实地址和端口
# 以下保留域名用于演示命令结构
Test-NetConnection example.com -Port 443

上面的端口测试只证明到指定地址的 TCP 连接是否建立，不能验证代理协议，也不能代替完整请求。对于主要使用 UDP 的协议，TCP 测试更不能作为可用性结论。服务器可能限制探测，应用也可能通过不同路径访问；因此应把端口测试作为辅助证据，并以代理请求、内核日志和服务方说明共同判断。

检查策略组是否真正更换出口

在选择节点后，再打开连接详情确认实际出口。有些策略组嵌套了另一个策略组，表面选择的是自动选择，真正使用的仍是其内部节点。已经建立的长连接也可能继续沿旧出口工作。可以只关闭相关连接，再重新请求；不要一开始就清空所有连接，以免影响下载、会议或其他正在进行的任务。

最后再更新订阅并联系服务方，提供故障发生时间、网络类型、协议名称及已经做过的对照测试，不要发送完整订阅链接。若更新后只有部分节点恢复，保留可用节点继续使用，等待远端处理其余线路。若日志明确提示未知协议或不支持字段，则检查内核兼容性，到下载页选择仍在维护的客户端，而不是盲目降低安全设置。

03 订阅失败：分别检查下载、解析与配置合并

先识别失败发生在订阅的哪一步。订阅链接是用于获取节点或完整配置的地址，导入失败可能是没有下载到内容，也可能是下载成功却无法解析。打开订阅管理页，查看更新结果和内核日志中的具体提示。不要把所有失败都归因于链接失效，更不要将私有链接粘贴到公开转换网站测试，它可能包含访问账户资源的凭据。

检查地址与返回内容

重新从服务方账户页面复制链接，避免复制到说明页面、二维码图片地址或带有空格的片段。确认链接没有被聊天软件截断，也没有把句尾标点一起带入。部分链接包含很长的查询参数，不能只保留问号前的部分。若账户刚续费或重置过订阅地址，旧地址可能已经不能使用，应以账户页面当前提供的地址为准。

观察更新错误的类别。认证失败或禁止访问通常需要检查账户权限、链接凭据及服务方限制；找不到资源可能是地址路径已经改变；请求超时则先检查基础网络和订阅站点是否可达。若返回的是登录页、维护页或访问验证页面，即使下载请求显示成功，内容也不是可用配置。不要通过反复重试掩盖明确的权限错误。

遇到必须经过代理才能更新的订阅地址，先确认客户端是否允许选择更新使用的代理路径。已有可用配置时，可以先启用它再更新；完全没有可用节点时，应使用服务方提供的其他合法获取方式。不要随意把更新地址改成陌生域名，也不要为了获取订阅而把整个配置目录公开共享。

确认订阅格式与内核兼容性

区分节点集合与完整配置。完整配置可以包含端口、规则和策略组，节点集合则可能需要放入代理集合提供器，也就是 proxy-providers 所定义的来源。客户端的订阅导入入口不一定接受所有分享链接格式。先查看服务方是否提供 Clash 或 mihomo 对应格式，再使用匹配的入口；不要仅通过修改文件扩展名尝试转换内容。

如果报错包含 YAML 行号，先备份文件，再检查该位置附近的缩进、冒号和列表符号。YAML 使用空格表示层级，不应混用制表符；但错误行号也可能指向前一行引号没有闭合所造成的后果。对下载得到的配置不建议直接大段手改，应先重新获取原文件，确认是否在复制、保存或自动合并时损坏。

# 仅展示代理集合提供器的字段层级，需并入完整配置。
# 保留域名用于说明结构，不是可导入的真实订阅地址。
proxy-providers:
  subscription:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/subscription.yaml
    interval: 3600

保留有效配置，定位覆盖与更新问题

若原订阅能够下载，只有启用本地覆写后才启动失败，就把问题缩小到合并过程。覆写是客户端在订阅基础上加入本地设置的机制，可能改变 DNS、规则和端口。先停用最近增加的一条覆写，再重新生成运行配置；不要直接改客户端自动生成的临时文件，因为下一次更新可能覆盖修改，造成问题看似反复出现。

更新成功却看不到新节点时，检查当前激活的配置是不是刚更新的那一份，以及策略组是否过滤掉了新节点。自动更新与切换当前配置是两件不同的事。还要确认本地文件路径是否可写、剩余磁盘空间是否充足。保留最后一份可用配置，等新配置测试通过再替换；有关订阅入口的基本操作可回到导入订阅教程核对。

04 速度慢：先定位吞吐、响应与单站限制

先描述慢在哪里。打开网页前等待很久、下载开始后速度低、视频播放偶尔停顿，是三类不同现象。前者可能涉及 DNS 或连接握手，中间一种更接近持续吞吐不足，最后一种还可能与目标服务的内容分发有关。记录同一时段、同一网址、同一网络下的表现，再做对照；不要把节点测试的响应时间直接当作下载速度。

建立可重复的对照条件

先暂停云盘同步、系统更新和其他大流量任务，在同一设备上分别测试直连资源与代理资源。直连也慢时，应先检查无线信号、路由器负载和宽带本身。无线网络显示已连接，不代表链路稳定；可以靠近路由器，或在具备条件时改用有线连接。测试过程中尽量不要移动设备，否则信号变化会干扰结果。

每次只下载一个来源可靠、大小适中的文件，避免同时运行多个测速工具。短时间高并发测试会争抢带宽，也可能触发远端限制，测出来的结果未必代表日常使用。需要比较节点时，保持目标资源一致，并记录实际出口；不同测试网站所在地区和服务能力不同，不能把它们的结果直接横向比较。

从连接详情确认真实瓶颈

查看慢请求命中了什么规则。有些网站主页面与图片、视频使用不同域名，如果只有主域名走代理，子资源可能绕到不可用的直连路径。反过来，本可就近直连的资源绕经远端，也会增加等待。先在连接列表找到具体失败或慢的资源域名，再增加范围合适的规则，不要直接用过宽的关键词匹配整个网络。

若只有一个服务慢，尝试同一节点访问另一个独立服务，再换节点访问原服务。如果换节点改善，可能与出口路径或目标服务对该出口的调度有关；如果所有节点访问原服务都慢，则继续看服务本身、账户限制和客户端播放设置。视频网站显示的缓冲状态不是代理内核吞吐的直接测量，应结合连接列表与实际播放观察。

谨慎调整协议与网卡参数

检查客户端与其他 VPN、流量过滤工具是否重复处理同一连接。重复接管会增加处理开销，有时还会形成绕路。先退出其中一个工具再测试，而不是立即卸载。若仅开启 TUN 后变慢，检查路由、DNS 接管和安全软件拦截；如果系统代理模式正常，可以暂时用它维持工作，再单独处理 TUN 的兼容问题。

不要把修改 MTU 当作所有慢速问题的第一步。MTU 表示单次网络传输所允许的数据包大小，路径不匹配可能引发部分连接卡住，但数值并非越小越好。只有在某种网络下频繁出现大请求停滞、切换网络又恢复时，才值得在备份后做受控调整。每次记录原值、调整值和同一请求的结果，未改善就恢复。

最后检查处理器占用、设备温度和省电状态。老设备加密转发、大量连接和持续调试日志可能消耗资源；先恢复普通日志级别，减少不必要的后台连接，再观察。不要在故障尚未定位时叠加一批所谓加速字段，字段间的相互作用会让问题更难复现。速度问题的修复标准是常用场景稳定改善，而不是某次测速出现更高峰值。

05 DNS 问题：拆开系统解析、内核解析与代理出口

先理解解析发生在哪里。DNS 是把域名转换成网络地址的服务，系统、浏览器和 mihomo 都可能各自发起查询。系统命令能查到地址，不代表代理内核采用相同结果；浏览器启用了安全 DNS，也可能绕过预期的解析路径。因此看到域名相关错误时，要先确认是哪一个程序报告失败，再查看它实际使用的解析方式。

用不同入口判断失败层级

先用系统解析工具查询一个日常可用域名，再用显式 HTTP 代理命令访问该域名。前者检查系统解析，后者把目标域名交给本地代理处理，两种结果并不必然相同。测试时不要只把网址换成某个地址，因为 HTTPS 还涉及证书名称与站点识别，直接访问地址失败不一定说明网络断开，也不适合作为普通用户的最终验证。

nslookup example.com
curl --proxy http://127.0.0.1:7890 -I https://example.com

# socks5h 表示让 SOCKS 代理处理目标域名解析
curl --proxy socks5h://127.0.0.1:7890 -I https://example.com

对照测试前清楚记录代理端口与工作模式。SOCKS 的本地解析和代理端解析并非一回事，命令中是否带字母后缀会影响解析位置。若系统查询失败而代理请求成功，可以优先检查系统 DNS；若系统查询正常但内核日志报错，应检查内核 DNS 配置、上游解析服务可达性，以及解析请求是否又依赖尚未建立的代理连接。

检查配置层级与解析依赖

打开实际运行配置，确认 dns.enable 是否启用，并查看 nameserver 指向什么服务。它是常规域名解析所使用的上游列表；proxy-server-nameserver 则可用于解析代理服务器自身的域名。若解析节点域名又必须先连接该节点，就可能形成循环依赖。先让服务器域名具备独立可用的解析路径，再处理其他域名。

# 诊断用 DNS 片段，需合并到已有完整配置。
# 上游应按当前网络的可达性与使用需求选择。
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

理解 Fake IP 再判断地址是否异常。该模式会为域名分配保留地址，由内核在后续连接中还原目标，所以看到保留地址不等于解析被破坏。真正要检查的是后续连接能否被正确接管。如果某个应用拿到虚拟地址却绕过代理直接访问，就可能失败。此时应检查接管范围，或针对确有兼容问题的域名使用适当过滤，而不是清空全部 DNS 设置。

分别处理缓存、IPv6 与浏览器设置

修改 DNS 后，已有连接与缓存可能继续沿用旧结果。先关闭目标应用的相关连接，按客户端提供的方式刷新 DNS 缓存，再重新访问。必要时重启目标应用，不要一开始就重置整机网络。浏览器若启用了独立的安全 DNS，可以临时停用做对照；记录原设置，确认问题后再决定保留哪一种解析路径。

如果只在支持 IPv6 的网络异常，分别观察地址族与路由是否一致。获取到 IPv6 地址，并不保证应用到该地址的路径可用；代理支持 IPv6，也不表示本地接入网络一定支持。可以临时做单一地址族对照，但不应把永久关闭系统 IPv6 当作通用答案。恢复正常后，应明确问题来自接入网络、规则还是代理出口。

涉及 TUN 时，再检查 DNS 请求是否被接管，以及局域网设备、企业内部域名是否需要保留本地解析。不要把所有内部域名送到公共解析服务，它们通常只能由所在网络的 DNS 回答。更完整的字段关系和场景配置可阅读mihomo DNS 配置详解；每次调整后都要同时验证公共网站与内部资源。

06 系统代理不生效：按应用入口逐条验证

先区分系统代理与流量接管。系统代理是向操作系统登记代理地址，由愿意读取该设置的应用使用；它不是对所有连接的强制转发。终端工具、游戏、后台服务和部分商店应用可能不读取同一份设置。因此开关显示开启，只能说明客户端尝试写入设置，不能证明每个程序已经使用代理。先用显式代理测试，确认内核本身可用。

检查系统设置是否真正写入

打开操作系统网络设置，核对代理服务器地址、端口，以及是否同时启用了自动配置脚本。若客户端监听在本机回环地址，系统设置也应指向对应本地地址，端口必须与当前运行配置一致。不要照抄其他教程中的端口数字。若设置刚写入又自动变回，检查是否有其他代理工具、设备管理策略或安全软件正在持续修改它。

Windows 的不同网络组件可能读取不同代理来源，浏览器可用而后台程序不可用并不罕见。macOS 则需要注意当前网络服务，先前为无线网络设置的代理不一定等同于后来接入的有线网络。Linux 桌面环境的网络代理设置也不保证覆盖全部命令行程序。先定位具体应用，再选择它支持的配置方法，避免同时改动多个系统层。

让浏览器与终端分别完成对照

浏览器侧先停用会控制代理的扩展，再完全退出并重新打开浏览器测试。某些扩展会覆盖系统设置，无痕窗口也未必能排除所有企业策略或扩展权限。检查浏览器自己的代理选项是否跟随系统，并使用一个新请求观察连接列表。如果浏览器成功打开网页但内核没有新连接，还要排除缓存页面，不能仅凭界面判断流量路径。

终端侧先用命令参数测试，再决定是否设置环境变量。环境变量是传递给进程的配置，通常只影响新启动的子进程，不会自动修改已经运行的所有终端窗口。下面只针对当前 shell 会话设置常见变量；不同工具支持的变量名称可能不同，涉及构建工具、包管理器或远程开发时，还应检查该工具自己的代理文档。

# 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

# 完成测试后撤销
unset http_proxy https_proxy no_proxy

https_proxy 的变量名表示它用于 HTTPS 目标请求，变量值仍可使用本地 HTTP 代理地址。不要只因为目标网址是 HTTPS，就把本地地址协议改成 HTTPS。还要检查已有的 ALL_PROXY、大写变量和工具内部配置，避免遗留设置指向已经关闭的端口。退出客户端后，持久化的终端代理变量也需要同步处理。

仅在需要时使用 TUN，并验证排除项

对于确实不支持代理设置的应用，再考虑 TUN。启用前确认客户端具备需要的权限，查看服务模式或虚拟网卡是否成功启动，并检查内核日志里的路由错误。服务模式是让后台服务承担需要权限的操作，不应仅靠反复以管理员身份打开界面替代诊断。若启用后内部网络失联，先关闭 TUN 恢复连接，再检查排除路由和内部 DNS。

最后检查绕过列表。有些应用提供忽略本地地址、指定域名直连或独立网络隔离，命中这些条件时不走代理是预期行为。容器、虚拟机和远程开发环境中的回环地址指向各自环境，不一定是宿主机，不能直接照搬本机端口。跨设备开放代理需明确访问控制，普通本机使用保持局域网访问关闭即可。更多对照步骤见浏览器与终端分开排查。

07 客户端崩溃：保留日志、排除冲突并回滚配置

先判断退出的是图形界面还是内核。界面直接消失、界面仍在但连接中断、开机后后台服务反复重启，分别可能指向不同层级。记录复现动作：是打开软件时、更新订阅后，还是启用某个功能后。不要立刻删除整个应用数据目录，这会同时移除日志、配置和恢复线索，也可能让订阅凭据与本地规则无法找回。

保存第一现场，检查配置是否可加载

能打开界面时，优先使用客户端提供的日志和配置目录入口。无法打开时，再根据该客户端文档找到数据目录，将配置、覆写规则和最近日志复制到私有备份位置。备份文件也可能含敏感信息，不能直接上传公共论坛。截图应保留错误类型、文件名和发生顺序，同时遮住订阅地址与认证字段，避免为了求助而扩大信息暴露。

若故障紧随一次配置修改出现，先回滚最近改动，再执行配置测试。语法正确不等于所有资源都可读取，日志可能继续提示规则文件不存在、代理组引用错误或路径没有权限。检查相对路径是相对于哪个工作目录，而不是只确认文件在设备上存在。图形客户端的生成配置与原始订阅不同，应该检查真正交给内核的那份文件。

检查端口占用与运行权限

日志若提示地址已被使用，先确认是否有另一个客户端或旧内核进程在运行。相同端口不能由多个普通监听进程同时占用。下面的命令用于查看端口对应的进程线索，不会自动结束进程。查到进程编号后，再通过任务管理器或系统工具确认程序名称；不要复制网络上的批量结束命令，以免误关其他服务。

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

若占用者就是旧客户端，先正常退出，再重新启动当前客户端。若端口属于其他必要服务，可以在客户端中改用空闲端口，并同步修改系统代理和终端变量。不要只改配置一处就开始测试，否则应用仍访问旧端口，会把端口冲突变成连接拒绝。完成调整后，确认日志、系统设置与显式测试命令使用同一个端口。

遇到权限不足时，检查配置目录是否只读、是否从其他账户复制而来，以及安全软件是否拦截了内核或虚拟网卡操作。不要直接关闭全部防护功能；先阅读系统通知，确认被阻止的文件路径与来源，再按需允许对应组件。安装包架构也要匹配设备，尤其是不同处理器的 macOS 与 Linux 系统，不能仅看文件扩展名判断。

采用最小恢复，而不是整体清空

先关闭 TUN、停用新增覆写，并切回最后一次可用的配置，观察基本界面与内核能否稳定运行。若需要验证用户数据是否损坏，应按客户端支持的方式创建独立测试环境，或在完整备份后暂时移开相关配置，而不是把所有文件永久删除。测试恢复后，再逐项加入订阅、规则与高级设置，每加入一项都重新检查启动日志。

如果只有特定客户端持续退出，而同一订阅在另一款仍维护的客户端中可用，可以保留日志反馈给对应项目。更换时从客户端下载页选择匹配平台的版本，不要让多个代理客户端同时开启接管。需要更细的回滚顺序，可阅读客户端打开即闪退处理。最终确认连续启动、订阅更新与正常退出都完成后，再清理旧备份。

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

先在应用保持前台时完成一次连接测试，再锁屏或切到后台观察。移动系统会管理后台运行、网络权限和 VPN 通道，同一配置在桌面可用，不代表手机端具有相同权限与生命周期。如果前台正常、锁屏后中断，先检查后台限制；如果一开始就无法建立连接，则先核对授权、订阅与节点，不要把所有移动端问题归为省电策略。

Android：确认授权与后台运行条件

首次连接时，应在系统弹窗中允许建立 VPN 连接，并确认当前设备没有其他应用占用所需的 VPN 通道。这里的 VPN 是系统提供的流量转发接口，不表示一定采用某种特定代理协议。广告过滤、企业接入或其他网络工具也可能使用该接口，启用其中一个后可能替换另一个。先暂停其他接管工具，再单独测试 Clash 客户端。

打开系统应用设置，检查电池优化、后台活动和数据使用权限。不同设备菜单名称不同，应以系统实际选项为准，优先允许所用客户端持续后台运行。测试时不要只依赖最近任务列表里的应用卡片，它还在列表中不代表服务一直存活。锁屏一段时间后重新查看内核日志，判断是服务被停止，还是服务仍在但网络连接需要重建。

检查是否启用了分应用代理。有些应用可能被加入绕过列表，或者客户端采用仅代理所选应用的模式；新安装应用未被勾选时，就会表现为只有它不走代理。调整后重新启动目标应用，并在连接列表确认请求。Android 的私人 DNS 也可能影响解析，若出现域名异常，可临时切回系统默认做对照，再按需要恢复原设置。

iOS：区分隧道状态、网络权限与资源更新

iOS 用户可以先通过iOS 下载入口安装 Clash Plus，并通过系统提示允许添加 VPN 配置。看到系统 VPN 标识只代表隧道处于连接状态，不代表节点、规则和目标服务一定可用。回到客户端检查当前订阅、所选出口与最近日志，再发起一个新请求。若只有某个应用异常，也要核对它是否获准使用蜂窝网络。

遇到局域网资源不可达时，检查系统是否授予应用所需的本地网络访问权限，以及配置是否将内部地址错误送到代理。权限与分流是两件事，单纯添加直连规则不能替代系统授权。若更新大配置、规则资源后才出现连接中断，可先减少不必要的规则集合和并行任务，再观察系统日志；不要为了恢复连接而一次删除所有订阅。

切换网络后重新验证，并整理求助材料

从无线网络切到蜂窝网络后，旧连接可能不再适用，新的网络还可能具有不同的 IPv6、DNS 与访问限制。先等待系统网络稳定，再重新建立代理连接，并关闭目标应用的旧请求重新测试。若只在某个无线网络失败，检查是否需要网页登录认证；先暂停代理完成认证，再恢复连接，避免认证页面被错误地送往远端出口。

启用始终开启 VPN 或阻止非 VPN 连接之类的系统策略时，要理解它们会改变断开后的行为。隧道暂时失败可能导致整个设备停止联网，这是策略的预期结果，不一定是无线网络损坏。排查时先记录原设置，再临时关闭相关限制恢复对照；测试结束后按自己的保护需求恢复，不要在不知情的情况下长期改变系统策略。

最后整理一份能够复现的说明：设备系统、客户端名称、接入网络、前台与后台差异、是否仅某个应用失败，以及脱敏后的第一条错误。不要发送完整订阅、账户截图或全部配置。基础概念可查常见问题与术语表；需要重新走通安装和首次连接时，回到使用文档，先恢复最小可用状态，再逐步启用高级功能。