Clash 故障排查手册：连接、订阅、DNS 与系统代理诊断

无法上网：先分清故障层

先判断是设备本身断网，还是启用 Clash 后才断网。关闭客户端里的「系统代理」和「TUN 模式」，确认系统代理设置也已恢复，再访问平常能够直连的网站。如果此时仍失败，先处理无线连接、路由器或网络登录页；代理配置无法修复底层断网。公共网络尤其要先完成网页认证，再重新启用客户端，避免把认证拦截误认为节点故障。

先做直连、显式代理两组对照

恢复直连后，启动客户端但暂不开 TUN，确认内核状态正常。下面两条命令访问同一目标，第一条明确绕过代理，第二条明确连接本地代理端口。Windows 请使用 curl.exe，避免部分 PowerShell 环境把 curl 解释成其他命令。示例端口是 7890，执行前应替换为客户端设置中实际监听的端口。

终端 / 同目标对照

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

收到 HTTP 响应说明该次请求至少完成了相应的连接过程；响应码不是成功码，也不能直接认定代理断线。若第二条立即提示 Failed to connect to 127.0.0.1，优先检查内核和端口。若端口能连接，却在后续握手或远端连接阶段失败，再检查策略组、节点和 DNS。一个测试站点只代表这条访问路径，仍需复测原先出问题的网站。

用连接记录判断请求有没有进入内核

打开「连接」或「日志」，清空筛选条件，只复现一次故障。完全没有对应请求，通常说明应用未使用系统代理、连接仍被复用，或 TUN 接管未建立；有记录则继续看匹配规则、策略组和实际出口。不要只看首页的运行状态，界面进程存在不等于内核已经成功加载配置。出现配置解析错误时，应先修正错误行，再讨论节点是否可用。

如果记录显示走了 DIRECT，而该目标原本需要代理，问题在分流选择，不在节点测速。可临时切到「全局」，明确选择一个已知可用的出口，再建立新连接对照。全局模式只改变进入内核后的选路，不会让原本绕过客户端的应用自动进入代理。测试结束应恢复规则模式，避免其他网站也被同一个出口接管。

恢复时按最小组合逐项打开

当显式代理可以访问、浏览器却不行时，先只开系统代理，重启浏览器后复测；仍有特定应用不走代理，再单独验证 TUN。不要一开始同时启动多个代理客户端、加速工具和 VPN，它们可能争用系统代理、默认路由或 DNS。退出其他工具时也要确认其网络设置已撤销，而不只是把窗口关掉。

最后用最初的失败目标复测，并记录哪一项开关触发了变化。直连和代理都失败，转向基础网络；只有代理失败，继续查下一章；显式代理成功而普通应用失败，跳到系统代理失效。需要重新核对导入与启用流程时，回到订阅导入步骤，不要靠反复重装替代定位。

节点超时：检查连接路径

节点测速出现「超时」，只说明在限定时间内没有完成测试请求，不能单凭这个词判断服务已经失效。测速还依赖测试地址、域名解析、协议握手和目标响应。先展开日志，找到同一时刻的完整错误，区分连接的是节点服务器、DNS 上游还是测试网站。特别注意错误中的目标地址，内核连接节点失败与节点连接目标失败，后续处理并不相同。

按报错发生的阶段缩小范围

dial tcp 是建立 TCP 连接时的上下文，后面的内容才提供主要线索。connection refused 常见于目标端口没有服务或连接被主动拒绝；i/o timeout 表示某阶段等待超时，仍需结合地址和前后日志；no such host 应先检查域名解析。不要把所有错误都归结为端口占用，本地端口冲突通常会在启动日志里明确出现监听失败。

日志线索	先检查什么	不要直接下的结论
`connection refused`	报错地址、服务端口和服务状态	不一定是本机防火墙
`i/o timeout`	连接阶段、当前网络和单个出口	不等于所有节点均已失效
`no such host`	节点域名与实际 DNS 查询	不是增加超时就能解决
`certificate` 相关错误	系统时间、服务器名与证书配置	不应先关闭证书验证

在同一网络、同一测试目标下手动选择另一个出口。如果只有一个失败，优先查看该条配置是否过期、服务器端口是否变更，以及服务状态是否正常。若所有出口一起失败，检查它们是否共用同一个服务器域名、同一个订阅账户或同一个上游网络。表面上多条记录，实际可能仍依赖同一处故障点，数量并不能提供独立对照。

分别验证解析、端口和协议握手

对节点域名做系统解析，可以帮助判断是否连名字都无法解析，但系统查询结果不一定等同于内核使用的结果。端口连通测试也只证明某个 TCP 端口可建立连接，不能证明密码、协议参数和后续代理请求有效。Windows 可用 Test-NetConnection 检查实际服务器与端口；不要把本地 7890 的测试结果当作远端节点正常的依据。

如果 TCP 已连通而 TLS 或协议握手失败，核对服务器名、设备时间与订阅原始参数。手动改过 server、servername 或其他握手字段的，先恢复提供方给出的内容。不能用 IP 地址随意替换域名，因为证书验证与服务端路由可能依赖域名。也不要通过开启跳过证书验证掩盖报错，那会改变安全边界，且未必修复真实问题。

用跨网络对照，而不是无限增加超时

允许条件下，用手机热点与原网络对照，保持客户端、配置和测试目标不变。如果热点正常，原网络失败，才有理由继续检查路由器策略、网络出口或 UDP 限制。网页正常而依赖 UDP 的应用失败，应核对所选节点和协议是否支持相应流量；普通 TCP 测速通过，不能替代 UDP 业务测试，更不能证明所有应用都应正常。

适度增大测速等待时间能区分响应慢与完全不通，但不会修复错误凭据或不可达路径。测试地址本身无法访问时，换一个稳定且符合实际用途的地址，并确认客户端采用的是 HTTP 状态判断还是其他检测方式。完整报错的阅读方法可参考运行日志报错含义对照。提交问题时提供脱敏日志、失败阶段与网络对照结果，比一张「全部超时」截图更便于定位。

订阅失败：区分下载与解析

订阅失败要先分成两类：地址没有成功下载，或内容下载到了但无法加载。进入「配置」页面执行一次更新，查看提示里的 HTTP 状态、解析错误和发生时间。反复点击更新通常不会增加信息，反而可能触发服务端限流。先保存仍能使用的当前配置，不要在新订阅尚未验证前删除旧配置，也不要把完整地址贴到公开问题区。

下载失败先看地址、权限与网络路径

从服务方页面重新复制客户端对应的订阅地址，检查首尾空格、换行、中文标点和剪贴板附带的说明文字。订阅地址不是账户管理页，也不一定是浏览器地址栏里当前显示的网址。带账户识别参数的链接可能因重置而失效；重新生成地址后，应更新客户端保存的地址，而不是只修改配置名称。名称变化不会改变真实下载位置。

出现 401 或 403 时，核对访问资格、地址是否失效及服务方限制；404 优先检查路径；429 应暂停重复请求，按服务方要求等待。服务器错误不适合通过改 YAML 解决。浏览器能打开也不能完全排除下载问题，因为浏览器可能带有登录会话，而客户端发起的是独立请求，返回内容可能不同。

再检查更新请求是否依赖当前代理。有的客户端允许选择直连更新或经代理更新，名称和默认行为不完全一致。如果旧出口已经失效，而订阅更新还被送到旧出口，就会形成更新依赖故障代理的循环。先使用可用网络直连更新，或临时选定已验证的出口；不要为了下载订阅而随意关闭证书验证，也不要把地址交给陌生的在线转换服务。

解析失败重点看实际格式与错误行

成功下载并不代表内容适合当前客户端。返回值可能是 YAML 配置、协议链接集合，也可能是登录页面或错误说明。yaml: unmarshal errors、cannot unmarshal 等提示应结合行号判断结构；内容开头若是网页标签，应回头修复订阅地址或访问权限，而不是逐行修改网页。Base64 文本也不能仅靠改成 .yaml 后缀变成完整配置。

YAML / 缩进结构示意

# 仅展示层级；不含节点，不能代替完整订阅
mode: rule
mixed-port: 7890
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML 使用空格缩进，不要混入 Tab；列表项要有连字符，字段冒号后通常需要空格。错误行也可能只是解析器发现问题的位置，真正缺失的引号或层级常在上一行。涉及策略组引用时，名称必须与定义完全一致。若订阅包含当前内核不支持的协议或字段，应向服务方索取匹配格式，或选择兼容的客户端，不能靠删除未知字段保证配置仍然等价。

更新完成还要确认启用与持久化

看到「更新成功」后，确认当前启用的是刚更新的配置，再到代理页检查预期策略组是否存在。部分客户端把「下载订阅」「刷新提供者」和「重新加载内核」分为不同动作；缓存仍在时，列表可能看起来没有变化。只有实际连接记录使用了新配置中的出口，才算更新闭环。不要把界面显示的最后更新时间当作全部验证结果。

本地修复若直接写进订阅生成文件，下次更新可能被覆盖。需要长期保留的端口、DNS 或规则调整，应使用客户端支持的覆写、合并或扩展配置功能，并先确认合并顺序。更具体的格式识别见订阅导入与 YAML、Base64 格式说明；首次导入仍按入门指南操作。更换客户端时可优先从下载页的 Clash Plus开始核对平台适配，但客户端无法替代有效订阅和正确权限。

速度慢：排除规则与链路影响

先把「慢」描述准确：是页面开始响应慢、下载持续速度低，还是视频隔一段时间缓冲。三者可能对应 DNS、连接握手、出口拥塞或应用自身限制。固定一个目标、一个文件和一个出口，在相近时间做对照；同时暂停云盘同步、系统更新和其他大流量任务。不要用不同网站的结果互相证明，也不要把一次测速响应快等同于长时间传输一定稳定。

先确认出口，再比较连接与吞吐

在「连接」页面找到慢请求，确认它匹配的规则、策略组和实际节点。有的网站主页面与下载文件使用不同域名，主页面走代理不代表文件也走同一出口。切换策略后，已有连接可能继续使用原出口；关闭对应应用或仅关闭相关连接，再发起新请求才有比较意义。为测试而频繁切换整个策略组，会让每次结果都处在不同条件下。

规则模式慢、全局模式正常时，重点检查目标域名是否命中了不合适的直连规则，或关联域名分散到不同出口。两种模式都慢，则继续检查节点与本地网络。若只有单个站点慢，还要考虑站点对出口地址的限速、CDN 分配及地区差异。此时换客户端通常不是第一步，先用另一个出口访问同一资源，更能区分站点路径与软件设置。

GeoIP 更新：只修复相应规则依赖

GEOIP 用于按目标 IP 所属地区匹配，不直接测量线路质量。日志出现地理数据库下载或加载失败时，先确认当前配置使用的是哪种数据模式，以及客户端实际的数据目录。不同内核可能使用不同数据库文件或加载方式，不应把网上找到的文件随意重命名后覆盖。更新动作通常位于「设置」「内核」或地理数据相关页面，具体名称以客户端为准。

执行更新后查看日志，确认下载完成且重新加载成功；仅出现开始下载不算完成。如果更新依赖的地址无法访问，先修复下载路径，再使用客户端支持的更新入口重试。不要凭空替换来源地址，也不要删除仍可读取的旧数据库来强迫更新。使用规则提供者的配置还需分别刷新对应规则集，GeoIP 数据与远程规则集并不是同一份资源。

数据库更新后，重新建立慢请求，查看匹配是否按预期改变。IP 归属判断存在数据时效和 CDN 边界，仍有特殊目标时，可以在确认用途后添加范围更小的域名规则，并放在相关宽泛规则前。下面片段仅展示顺序，Proxy 必须是现有配置已经定义的策略组；不存在时应改成实际名称，不能直接复制后期待自动创建出口。

config.yaml / rules 片段

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

再查无线网络、UDP 与传输路径

如果所有出口在同一设备上都慢，用有线连接或靠近路由器后复测，并对照手机热点。无线干扰、路由器负载和上行占满都可能表现为代理不稳定。只有 TUN 开启时慢，可先关闭 TUN、用显式代理验证同一目标；如果差异稳定存在，再检查虚拟网卡、路由冲突与 MTU。不要直接套用固定 MTU 数值，应记录原值，每次只做一项调整并能恢复。

部分应用优先使用 QUIC，也可能在 UDP 受限时表现为反复等待，而普通网页 TCP 测试仍然正常。可在应用允许的情况下临时关闭相应功能做对照，但不要把禁用所有 UDP 当作通用提速方法。最终保留能重复复现的结果：网络、出口、规则、目标和发生时段。策略组选择逻辑可查策略组名词解释；若只有解析阶段等待明显，继续下一章，而不是不断扩大连接超时。

DNS 异常：检查解析路径

DNS 问题常表现为 no such host、域名打开失败、首次访问等待很久，或启用 TUN 后部分应用失联。先确认失败的是节点域名、目标网站域名还是 DNS 上游本身。节点域名无法解析会让多个网站同时失败；单个目标失败则可能只是该域名或对应上游的问题。不要一看到网页打不开就同时替换系统 DNS、内核 DNS 和浏览器安全 DNS，否则很难知道实际生效的是哪一层。

分清系统、浏览器和内核的解析结果

系统的 nslookup 只能反映它实际查询的解析器，不保证与浏览器或内核相同。浏览器可能使用自己的加密 DNS，内核也可能按 nameserver-policy 把特定域名送到另一组上游。先记录系统配置的 DNS，再查看客户端的 DNS 设置和最终生效配置。修改后还要确认覆写功能是否覆盖了订阅字段，避免只改了文件却没有改变运行参数。

测试时选择一个能稳定复现的域名，分别观察系统查询、浏览器访问和内核日志。如果系统查询正常、代理请求失败，应检查内核上游及其连接路径；如果浏览器正常而其他应用失败，检查浏览器是否独立解析。系统缓存、浏览器缓存和内核缓存也可能保存不同结果，清理一处不会自动清理全部。每次清理后重新发起连接，不要继续观察旧连接。

上游可达性比填写数量更重要

使用加密 DNS 时，访问上游本身也需要网络连接；上游写成域名时，还可能需要引导解析。应区分 default-nameserver 的引导用途与 nameserver 的常规解析用途。若启用了按规则选择上游连接路径的功能，还要检查是否形成循环依赖：解析节点需要代理，建立代理又需要先解析节点。此时应按照内核文档配置独立的节点域名解析路径，而不是堆叠更多上游地址。

下面片段用于临时排查普通 DNS 连通性，不是所有网络的通用推荐，也不包含 TUN 接管。它仅适合支持这些字段的 mihomo 配置；合并前保留现有设置，并确认本地监听端口没有占用。普通 UDP DNS 在某些网络可能受到限制或干预，因此这次测试成功与否都只能作为一条证据，不能代表加密 DNS 的访问结果。

config.yaml / 临时 DNS 对照片段

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

Fake-IP、局域网名称与劫持要分别验证

启用 Fake-IP 后，解析返回合成地址属于正常机制，前提是后续连接也进入同一内核并能找到映射。若应用拿到合成地址后绕过 TUN 直连，就可能失败。不要把合成地址当成真实服务器地址保存到其他设备，也不要用直接访问该 IP 的结果判断网站状态。需要为特定设备发现或局域网服务设置过滤时，只加入确认有冲突的域名范围，避免把所有域名排除导致测试失去意义。

打印机、NAS 和公司内部域名通常依赖本地解析器、搜索后缀或组播机制。公共 DNS 不知道这些名称，换成公共上游后失效并不意外。检查是否有域名专用解析策略，以及 TUN 路由是否仍允许访问局域网。普通 DNS 劫持也不保证覆盖应用内置的加密 DNS；如果某个应用始终绕过预期解析路径，应在该应用设置中对照，而不是继续扩大劫持范围。

修复后按原来的域名、网络和应用复测，再恢复临时降低的日志级别及测试配置。先让解析链路稳定，再处理分流或性能，能避免把缓存偶然命中当成修复。字段层级与覆盖关系可继续阅读config.yaml 端口、dns 与 rules 拆解。如果 DNS 正常却没有连接记录，应转到流量接管章节，不必继续更换解析器。

系统代理失效：确认流量接管

「系统代理已开启」不等于设备上每个应用都经过 Clash。系统代理通常向支持它的应用提供 HTTP 或相关代理设置；自行建立连接、使用独立代理配置或不读取系统设置的程序，可能仍然直连。先用第一章的显式代理测试确认本地服务可用，再检查故障应用采用哪种接管方式。若显式代理也失败，应先修复内核和端口，而不是反复切系统开关。

核对系统里写入的地址和端口

在客户端查看混合端口或 HTTP 端口，再进入系统网络代理设置，确认主机与端口一致。本机通常使用 127.0.0.1，不是节点服务器地址。external-controller 是控制接口，不是浏览器代理端口；把 9090 填成代理端口会导致访问失败。HTTP 与 SOCKS 的协议也要匹配，除非配置使用同时接受两者的混合端口。

Windows 应区分用户代理设置与个别服务使用的 WinHTTP 代理；一个页面里的开关不保证覆盖另一套机制。macOS 要检查当前活动的网络服务，例如无线网络与其他网卡的设置可能不同。Linux 桌面环境的代理设置也不保证被所有程序读取。看到地址残留时，先确认是谁写入的，再在对应界面修复；不要直接复制网上的全局重置命令影响工作网络。

参数或入口	实际作用	排查重点
`mixed-port`	本地 HTTP 与 SOCKS 代理入口	应用是否连接了实际监听端口
`external-controller`	内核控制接口	不能当作应用代理入口
系统代理	由应用决定是否读取系统设置	应用支持情况与独立代理设置
TUN 模式	经虚拟网络接口接管符合条件的流量	权限、路由与排除范围

端口占用与应用覆盖分别排除

启动日志出现 address already in use 或 bind 失败时，先查占用进程。Windows 可用下方命令查看监听信息，再结合任务管理器确认进程身份。不要看见一个 PID 就强行结束，它可能属于另一个正在使用的服务。若选择更换端口，应同步修改客户端、系统代理和手动配置的应用，最后重新启动连接。

Windows / 查看本地监听

netstat -ano | findstr :7890

终端可能读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY，浏览器扩展也可能覆盖系统代理。先在应用内部恢复跟随系统或临时指定明确的本地代理，再做对照。修改环境变量后，旧终端或已经启动的应用可能保留原值，需要重新打开。代理绕过列表中的域名也会影响结果，检查时不要忘记通配符和地址段。

TUN 只在确有接管需求时加入测试

显式代理正常、目标应用又不支持系统代理时，再单独测试 TUN。确认客户端所需的服务或权限已成功启用，虚拟接口与路由已经建立；开关亮起但内核日志报错，仍属于未完成接管。其他 VPN、虚拟机网络或容器网段可能与 TUN 规则冲突，应记录原路由和排除范围，逐一停止冲突工具对照，不要清空整张路由表。

允许局域网连接与本机系统代理是两件事，本机访问通常不需要开启 allow-lan。只有明确需要其他设备访问本机代理时，才检查监听地址、防火墙范围和可信网络边界；其他设备填写的应是这台电脑的局域网地址，而不是它们自己的 127.0.0.1。端口基础用法见端口设置指南，开机后不生效则结合开机自启 FAQ检查内核是否真正启动。

客户端崩溃：保留现场再恢复

先区分界面退出、界面卡住和内核停止。窗口消失时，代理内核可能仍在运行；窗口还在时，内核也可能已经退出。查看进程列表、监听端口和最后一段日志，再判断故障范围。若整台设备出现网络异常，先恢复系统代理与 TUN，保证基础网络可用，再处理客户端数据。不要把「卸载后重装」当第一步，否则容易连复现条件和错误记录一起丢掉。

保存故障前后的最小现场

记录启动方式、故障发生在启动、更新订阅还是打开某个页面，以及当时是否刚切换配置。复制日志文件并保留时间上下文，不要只截最后一句；配置错误前面的提示可能更关键。日志含有路径、服务器域名或请求目标时，分享前需要脱敏。系统事件记录或崩溃报告也可能含用户目录，不宜把整份原始材料直接公开上传。

如果每次启动都在加载同一配置时退出，先备份客户端数据目录，再使用软件提供的配置停用或恢复入口。能够进入界面时，切换到已知可加载的配置，对照是否仍崩溃；无法进入时，按客户端文档处理配置选择状态，不要猜测并删除未知文件。自定义规则提供者、庞大配置和损坏缓存都可能参与故障，应一次排除一类，保留可回退副本。

安装包、内核与系统权限分开检查

从客户端下载页核对设备系统与处理器架构，优先使用 Clash Plus 对应平台的安装方式。若选择 Clash Verge Rev 或 FlClash，也要确认包格式与系统匹配。不要把不同客户端的程序目录互相覆盖，或只替换其中一个内核文件期待兼容；界面与内核的控制接口、配置生成方式可能不同，混装会使问题更难复现。

Windows 上检查安全软件的实际拦截记录，以及所需后台服务是否能够启动。只针对确认可信且被误判的项目处理，不要为了排查永久关闭整机防护。macOS 应先确认来源和系统提示，再按系统界面授权所需功能；不是所有客户端都使用同一种网络扩展机制。相关弹窗可参考macOS 权限与钥匙串处理，不要无差别执行绕过系统保护的命令。

Linux 上先在终端启动对应程序，观察缺失依赖、显示环境或权限错误。桌面应用与服务进程读取的环境变量、工作目录和用户权限可能不同，因此「终端能启动、菜单启动失败」应从启动环境比较。使用系统服务时查看服务管理器输出，确认配置路径和文件读取权限。普通界面运行尽量保持普通用户身份，权限仅按明确功能需求授予。

逐层恢复，不直接清空全部数据

缓存异常可以通过客户端提供的清理入口处理，但应先区分缓存、订阅、配置与凭据。若确实需要重建用户数据，先退出界面和相关后台进程，把原目录移动为备份，而不是立即永久删除。用新的数据状态启动后，只导入一份必要配置，不恢复全部历史设置；确认稳定后再逐项恢复覆写、规则集与启动选项，才能找到触发故障的那一项。

恢复后至少重现原先的触发动作，而不是只看能否打开窗口：更新一次订阅、重新加载配置，再建立一条实际连接。问题仍在时，提交客户端名称、系统架构、复现顺序和脱敏错误，并说明新数据状态下是否发生。不要编造版本结论，也不要把一次偶发退出归因于某个协议。界面区域不熟悉时，可先看客户端界面逐区讲解找到配置页与日志入口。

移动端：权限、后台与网络切换

移动端先分清连接立即失败、锁屏后停止，以及无线网络切到移动数据后失败。这三类问题分别优先检查 VPN 授权、后台限制和网络重建。先固定在一个网络下测试，关闭其他使用 VPN 通道的应用，再启动当前客户端。多数移动系统在常规情况下只允许一个主要 VPN 通道工作，广告过滤、企业接入和其他网络工具可能与代理争用，不能只看它们的窗口是否打开。

Android：检查授权、应用范围与后台

Android 首次连接通常会显示系统 VPN 授权。拒绝后需要重新发起连接并确认，界面显示已选节点不代表 VPN 通道已建立。系统若启用了始终开启 VPN 或阻止不使用 VPN 的连接，也要确认绑定的是当前客户端；旧客户端被停用但系统限制仍在时，可能导致整个设备断网。工作资料和个人资料属于不同管理范围，企业策略也可能限制接管，不能用普通应用设置强行覆盖。

只有部分应用不走代理时，查看分应用代理、绕过列表和当前使用的包含或排除模式。误把目标应用放进排除列表，与节点不可用的表现不同；应先在连接记录里确认是否出现请求。还要检查应用自己的代理或加密 DNS 设置。某些应用依赖 UDP，网页成功并不能证明该应用的语音、游戏或实时通信链路也可用，应按对应业务实际测试。

锁屏后断开时，查看系统对客户端的电池优化、后台活动和自启动限制，允许维持必要的后台连接，再观察通知栏状态及日志。不同设备厂商的入口名称不同，应按设置搜索相关项目，不要照着另一台手机逐项猜。若放开后台限制后仍断线，记录断线发生时是否切换网络，以及是进程被结束还是 VPN 仍在但连接不可用，两者需要不同处理。

iOS：确认通道状态与订阅有效性

iOS 可从下载页进入 Clash Plus 的 App Store 页面，官网入口为 clashplus.io。首次使用先完成系统 VPN 配置授权，再回到应用检查当前配置与策略选择。系统显示 VPN 标识只说明通道状态，不保证订阅有效或远端可达；仍需用实际请求与应用日志验证，不要把系统标识当成节点健康证明。

连接后所有网站都失败时，先停止通道，验证原网络，再按订阅、解析、出口的顺序检查。仅在某个无线网络失败时，确认是否需要网页认证，或网络对相应连接方式有额外限制。设备若受企业管理，VPN 配置可能由管理策略控制，应按组织要求处理。不要删除不明用途的管理配置来测试，也不要把工作网络问题简单归为客户端权限不足。

切网、热点与流量统计要用同一条件对照

无线网络切换到移动数据后，旧连接、DNS 缓存和 NAT 映射可能不再适用。先等待系统网络稳定，再停止并重新启动通道，重新打开目标应用建立新连接。如果每次切网都稳定复现，分别记录两种网络独立连接是否正常，以及切换方向；这能区分移动数据本身不可达与客户端没有及时重建连接，不必先删除整份配置。

手机自身通过代理，不代表热点下游设备也会自动使用同一通道。系统对热点转发与本机 VPN 的处理不同，应在下游设备单独验证，不要靠手机上的成功页面推断。移动数据计费同样由运营商规则决定，代理不会改变套餐约束；遇到流量异常先看系统分应用统计，再检查后台更新与大文件任务，不能把客户端汇总连接记录直接当作账单。

完成修复后，按「当前网络访问、锁屏后恢复、切换网络后新建连接」三步复测，并恢复排查期间临时改变的设置。若仍失败，保留网络类型、通道状态、发生时刻与脱敏日志，回到对应的超时或DNS 章节继续定位。只有复现路径清楚，才适合判断是否需要更换客户端；重新安装无法替代对订阅权限、后台策略和实际连接路径的检查。