Clash 故障排查大全

无法上网：先拆开基础网络与代理链路

先关闭客户端中的系统代理和 TUN，再访问平时能够直连的站点。仅退出窗口不一定会撤销系统设置，部分客户端关闭窗口后仍在后台运行。如果关闭接管后依然无法联网，先处理无线网络登录、路由器、网线和运营商连接；此时反复换节点不能修复基础网络。公共无线网络还可能要求先完成网页认证，认证页通常需要在关闭代理后打开。

确认故障范围，再决定检查入口

分别测试一个直连站点、一个需要代理的站点和另一个应用，记录哪些成功。全部失败时，优先看系统代理是否指向已经停止的本地端口；仅代理目标失败时，检查策略组和出口；仅一个网站失败时，检查该域名命中的规则、目标服务状态与访问限制。不要使用单个网站代表整个互联网，也不要把浏览器缓存中的旧页面当成联网成功的证据。

接着确认内核已经启动。客户端主窗口能够打开，不代表后台内核正在监听端口。查看运行状态与启动日志，寻找端口占用、配置解析失败、权限不足等信息。若日志停在加载配置之前，先处理启动失败；若已经出现连接记录，再沿记录查看请求被交给 DIRECT、某个策略组还是 REJECT。没有连接记录时，应回到接管方式排查，而不是继续调整远端协议参数。

用显式代理测试缩小范围

在客户端设置里确认本地混合端口，再用命令显式指定代理。下面以本地端口 7890 为例；实际端口不同就替换数字，不能因为示例使用这个端口就修改整套配置。Windows 可使用 curl.exe，避免终端把同名命令解释成其他工具。测试目标只用于检查连接，不保证在每种网络里都能成功。

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

第一条不显式指定代理，但仍可能受终端代理环境变量影响，测试前应检查这些变量。第二条若报本地连接被拒绝，说明监听地址、端口或内核状态不符；若本地连接建立后远端超时，才转向节点和链路。若显式代理成功而浏览器失败，说明出口大体可用，应检查浏览器扩展、系统代理和安全 DNS。HTTP 返回状态码表示已获得某种响应，不等于目标业务的全部功能都正常。

按可回退顺序恢复连接

切回规则模式，选择一个此前可用的出口，关闭其他代理客户端与重复的流量接管工具，再重新建立连接。暂时关闭 TUN、只保留系统代理，有助于区分路由与应用代理问题；但对不读取系统代理的应用，这不是等价测试。每次切换后关闭旧网页连接或重启测试应用，因为已建立的连接通常不会随着策略变化立即迁移。

若所有网站在退出客户端后才失效，打开系统网络设置，撤销遗留的手动代理地址，再恢复自动获取网络参数。不要直接执行全套网络重置，它可能删除工作网络所需的虚拟适配器与固定地址。恢复后先验证直连，再启动客户端并逐项启用功能。将最后一个导致故障的开关记下来，后续才能针对性修复，而不是每次重装。

节点超时：区分测试失败与出口不可达

先实际访问目标，再参考客户端的延迟测试。测试超时只说明某次探测没有在规定时间内完成，可能与测试地址、解析、探测方法或当前链路有关，并不能单独证明节点永久失效。若实际网页可以打开，而探测始终失败，先更换可访问的测试地址或恢复客户端默认测试设置，不要据此删除整个订阅。关于测量边界，可继续阅读延迟测试与实际网速的区别。

看清超时发生在哪一段

打开日志，重新发起一次失败请求，围绕同一时间查找目标、策略和错误。连接服务器前出现域名解析错误，属于入口地址解析问题；连接服务器端口超时，可能是本地网络、线路、远端监听或中间防火墙造成；建立连接后握手失败，则要检查协议、传输层、安全参数及服务器状态。不同客户端的错误文字可能不同，应结合上下文，不要只搜索最后一个英文单词。

确认当前策略组实际选中了哪个出口。自动选择组会随健康检查变化，回退组也可能已经切到其他成员；界面显示的组名不是服务器地址。查看具体连接的出口链，确认没有误选 DIRECT 或已经失效的成员。若节点依赖其他代理拨号，还要检查前置出口；链式连接中任意一段失败，最终都可能呈现为目标超时。

用交叉测试判断网络与服务端

在同一设备上切换家庭网络和手机热点，保持客户端配置不变，分别测试同一出口。同一出口只在某个网络失败，更像是网络路径、端口限制或解析差异；多个网络都失败，再用另一台设备测试。两台设备都失败且同一订阅的其他出口可用，问题更可能集中在该服务器。交叉测试时关闭自动切换，避免表面上测试同一个组，实际每次经过不同出口。

再检查订阅是否更新成功、账户是否仍有可用权益，以及服务提供方是否变更了入口。不要手动猜测服务器端口、加密方式或传输路径；这些参数需要与服务端对应，凭经验修改通常只会把超时变成握手错误。设备日期和时区也应正确，时间明显偏移可能使证书验证失败。遇到证书问题应核对服务器域名与证书配置，而不是长期跳过验证。

避免把局部协议问题当成全面断网

网页文字可以加载，语音或游戏却超时，可能涉及 UDP 支持、应用接管或目标限制。先检查节点协议与服务端是否支持所需流量，再看客户端连接记录。浏览器使用的 QUIC、普通 HTTPS 和应用自定义协议并不走完全相同的路径，因此一次网页测试不能覆盖全部业务。临时使用应用提供的兼容传输选项可以辅助对照，但不应把关闭某项协议当作所有设备的固定优化。

调整超时值只能帮助识别缓慢响应，不能让被阻断的端口恢复。先保留默认值，确认故障稳定复现后再适度延长单次探测，并比较实际请求结果。提交问题时附上失败时间、网络类型、脱敏错误和交叉测试结论；不要发送完整服务器凭据。若只有个别出口异常，先切到可用成员保证使用，再让服务提供方检查对应入口。

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

先确认失败发生在哪一步：地址无法获取、内容成功下载但不能解析，还是配置导入后内核不能启动。这三种情况对应不同处理方法。保留最后一份可用配置，避免更新失败后把工作环境一起覆盖。客户端显示订阅条目，只能证明本地保存过记录；需要查看更新时间和更新结果，才能确认当前内容来自最近一次成功获取。

检查链接完整性与获取路径

从服务提供方重新复制适用于 Clash 或 mihomo 的订阅地址，注意聊天软件换行、前后空格以及网页复制时附带的标点。订阅地址常包含账户访问凭据，应像密码一样保管。不要把完整地址粘贴到公共转换服务，也不要为了排查把它写进截图标题。若地址曾公开，应在服务端重新生成，单纯删除帖子不能撤销已经泄露的访问权限。

观察更新时的错误：未收到响应通常需要检查网络与解析；明确返回未授权或禁止访问时，优先核对链接权限与账户状态；返回页面内容却解析失败时，可能下载到登录页、错误提示或访问验证页面。浏览器能够打开服务网站，不代表客户端能够使用订阅接口，因为两者的请求路径、登录状态与网络出口可能不同。不要反复重试触发服务端频率限制。

有些客户端允许为订阅更新选择直连或代理。已有可用配置时，可以比较两种获取路径；首次导入还没有可用出口时，应先使用当前网络能够访问的合法获取方式。若更新依赖当前失效的节点，便会形成无法自行修复的循环。此时切回最后可用配置、临时选择其他可用出口，或联系提供方确认订阅入口，比随意修改 DNS 更直接。

确认格式与内核能力对应

YAML 完整配置、编码后的节点集合和单条 URI 链接不是同一种文件。能够导入某个客户端的内容，不一定能直接作为另一个客户端的完整配置。查看导入入口要求，区分添加单个节点、导入配置与更新订阅。若拿到的是其他格式，优先获取服务方提供的对应格式；确需转换时，可参考订阅格式与转换说明，了解策略组、规则和额外字段可能丢失的范围。

解析错误往往包含行号和字段名。回到原始文件查看该行以及上一行，检查缩进、冒号、引号和列表符号。YAML 缩进使用空格，不能把制表符混进去。配置可以通过语法解析，也仍可能存在策略引用错误：规则引用了不存在的组、组中包含不存在的节点，都会导致加载失败或行为异常。带空格和特殊符号的名称应保持完整，重命名后同步修改所有引用。

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

这是一段只用于验证基本加载的直连配置，不包含远端代理。若客户端允许导入本地配置，可在备份后单独新建测试条目，不要覆盖原订阅。最小配置可以启动而原配置不能启动，说明应检查原文件字段、引用或外部资源；两者都失败，则继续查看端口、目录权限和内核运行环境。

处理更新覆盖与外部资源失败

订阅正文成功加载后，规则集或代理集合仍可能获取失败。分别检查外部资源的地址、文件路径和错误，不要把所有下载失败都归因于订阅链接。客户端若支持覆写或合并配置，应把本地调整放在专用入口，避免下次更新覆盖；不确定合并顺序时，查看最终生效配置。连续失败后先恢复备份，再逐项加入自定义内容。客户端与内核能力不匹配时，从客户端下载页选择适用客户端，普通用户可先考虑 Clash Plus，再按平台核对其他选项。

速度慢：拆分解析、握手与持续传输

先描述慢在哪里：点击链接后等待很久、页面开始加载后很快、文件下载持续缓慢，还是只有高峰时段卡顿。首字节等待、吞吐量和交互延迟是不同指标。客户端探测数值较低，只说明某次短请求响应较快，不代表线路拥有足够带宽。不要同时启动多个测速工具和下载任务，否则测试本身就会抢占出口与本地无线网络资源。

建立可重复的对照测试

固定设备、网络、出口和目标，关闭大文件同步、系统更新与其他占用带宽的任务，再进行少量重复测试。先测直连目标，判断本地网络是否已经拥塞；再测需要代理的业务，观察差异。比较出口时使用同一个目标和相近时间，避免把服务器缓存、资源大小和不同地区的内容分发差异误认为节点差异。手机热点测试还应考虑套餐限速与信号波动。

下载速率常以每秒字节表示，宽带标称常以每秒比特表示，两者不能直接比较。无线网络协商速率也不是应用能够持续获得的净速率。路由器性能、无线干扰、设备省电模式、出口共享人数和目标服务器限速都可能成为瓶颈。先比较有线与无线，或靠近路由器测试；若直连同样缓慢，应先改善本地条件，修改代理规则不会增加无线链路的容量。

检查慢请求究竟走了哪个出口

在连接页面找到正在加载的域名，查看命中规则与策略。一个网页通常调用多个域名，主页直连而静态资源走代理，或登录接口走到另一地区，都可能造成局部等待。不要因为主域名规则正确，就假定所有子请求都正确。按连接记录补充必要规则，并把更具体的规则放在宽泛规则之前；修改后重新建立连接，避免旧连接继续沿用原出口。

规则按顺序匹配，过早放置的宽泛条件可能把本应直连的内容送往远端，增加往返时间。反过来，将需要代理的域名交给直连，也可能出现长时间等待后才报错。检查最终配置，而不是只看编辑器中的片段，因为订阅合并和覆写可能改变顺序。需要理解匹配机制时，阅读自定义规则与匹配顺序，再调整规则，不要靠大量重复条目碰运气。

若只有首次访问慢，后续访问恢复，优先排查 DNS、连接握手与远端唤醒；若开始很快、持续传输逐渐下降，则更像拥塞、限速或设备负载。查看任务管理器中的处理器、内存和网络占用，判断是否有单个进程持续占满资源。图形客户端日志量过大也可能增加界面开销，完成定位后恢复普通日志级别，不要长期把详细调试日志当成运行常态。

谨慎调整 MTU、协议与并发

TUN 开启后小页面正常、大文件或部分站点停住，才值得检查路径 MTU 与分片问题。先用关闭 TUN、保留显式代理的方式做对照，确认故障与虚拟网卡接管有关。MTU 应根据链路测试和客户端文档调整，不能把网上某个数值当成通用答案。每次修改后重新测试相同业务，并保留原值；盲目降低会增加包数量，未必提高速度。

同样，不要把增加并发、打开所有高级开关或更换任意公共 DNS 当成提速组合。并发可能增加连接压力，某些协议也依赖服务端能力。优先选择与目标业务距离和路径合适的可用出口，减少不必要的链式转发。自动选择策略适合维护可用性，但健康检查往往不能评估大文件吞吐；对持续下载，可以在对照测试后手动固定出口，避免选择频繁变化干扰判断。

DNS 问题：确认由谁解析、结果在哪里使用

先区分域名解析失败与目标连接失败。日志出现找不到主机、解析超时或没有可用地址时，才优先检查 DNS；已经得到地址但连接超时，仍可能是路由或出口问题。直接把网址中的域名换成 IP 并不是可靠验证，因为 HTTPS 证书、服务器名称与虚拟主机路由都可能依赖原域名。应结合解析工具和客户端日志判断，不能仅凭一个浏览器错误页下结论。

画出当前实际解析路径

系统、浏览器、客户端与远端代理都可能参与解析。浏览器启用安全 DNS 后，可能绕过系统解析器；应用内置解析也可能与终端工具结果不同。TUN 的 DNS 劫持是否生效，还取决于路由和请求类型。先记录当前模式、客户端 DNS 开关、系统 DNS 和浏览器设置，再检查出错应用实际走哪条路径。只修改系统 DNS，不一定会改变应用的查询结果。

使用系统工具查询一个稳定域名，同时查看客户端日志。下面的命令用于观察系统解析结果；它不一定代表浏览器或代理出口得到的地址。分别查询失败域名与正常域名，若只有一个域名失败，可能是权威记录、缓存或分流解析配置问题；全部失败时，再检查解析服务器是否可达。不要把终端结果与客户端日志中的不同地址直接认定为异常，内容分发本来就可能返回不同地址。

nslookup example.com

# Linux 或 macOS 安装了 dig 时可使用
dig example.com A
dig example.com AAAA

检查代理服务器自身域名如何解析。若用来解析代理入口的请求又必须经过尚未建立的代理，就会形成启动循环。mihomo 的 proxy-server-nameserver 用于代理节点域名解析，default-nameserver 可用于解析加密 DNS 服务的域名；具体行为还取决于其他配置项。先确保启动阶段所需的解析路径可用，再处理目标域名分流，不能把所有查询都强制送往一个不可达的出口。

理解 fake-ip 与缓存的边界

fake-ip 模式会给应用返回用于映射的虚拟地址，再由内核结合映射处理连接。看到这类地址不代表解析被污染。问题在于应用拿到虚拟地址后，连接是否仍由同一个内核接管；若应用保留旧缓存，而客户端已关闭或映射丢失，就可能无法建立连接。切换模式后应关闭旧连接、重新启动受影响应用，必要时清理对应缓存，而不是立刻增加一大批排除规则。

某些设备发现、局域网服务和特殊应用依赖真实地址，可在确认兼容性问题后使用 fake-ip 排除项。排除只改变相关域名的解析处理，不自动保证其后续流量直连；仍需检查规则与路由。局域网主机名还可能依赖路由器、搜索域或组播发现，公共解析服务通常不了解这些记录。远程办公环境尤其要保留企业内部解析路径，不能用单一公共解析器覆盖全部用途。

用最小 DNS 配置做对照

下面的片段用于说明字段关系，应合并进独立测试配置，不要覆盖已有订阅的整个 DNS 段。此例使用普通 DNS 做基础对照，不包含加密传输；解析器在当前网络不可达时，应换成网络管理员或服务提供方确认可用的地址。测试成功只证明这一条解析路径可用，不代表已经满足隐私与分流需求。

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

若 IPv4 正常而双栈环境间歇失败，分别检查 IPv6 的解析结果、默认路由和代理支持。不要仅关闭某个应用的 IPv6 就认定根因消失，系统其他应用可能仍走另一条路径。恢复配置时分开验证节点域名、普通目标与局域网目标，随后再逐项恢复加密解析和分流规则。完整 TUN 接管关系见TUN 模式与虚拟网卡设置。

系统代理不生效：检查应用是否读取代理设置

先确认预期：系统代理是提供给应用读取的一组代理参数，不是强制接管所有网络流量。部分终端工具、游戏、服务进程和自行建立连接的应用不会读取它。开启后浏览器可用、某个程序仍直连，未必是客户端故障。先用显式指定代理的工具验证本地入口，再看目标应用是否支持代理设置；需要覆盖更多应用时，再评估 TUN，而不是不断重复开关系统代理。

核对监听地址、端口与代理类型

查看客户端当前端口，确认系统手动代理指向同一地址。常见本地地址是 127.0.0.1，但端口并不固定。HTTP 代理端口、SOCKS 端口和混合端口的能力不同，不能随意互换。若应用要求 SOCKS，应填写支持 SOCKS 的端口；若使用 HTTP CONNECT，应选择对应入口。两种协议可能共用混合端口，但需要客户端确实启用了该监听。

检查是否有第二个客户端、浏览器扩展或企业管理策略反复写回系统设置。表现可能是刚开启时有效，过一会儿代理地址又改变。先退出其他接管工具，观察设置是否稳定，再逐个恢复。不要为了抢占设置而让多个客户端同时自动启动。若系统设置由单位管理，应按管理员要求处理，擅自覆盖策略可能让工作网络与认证服务失效。

分别处理终端与隔离环境

终端通常需要工具参数或环境变量。下面只对当前类 Unix 终端会话设置 HTTP 与 HTTPS 代理，并排除本地地址；Windows PowerShell 应使用对应的环境变量语法。环境变量名称的大小写支持因工具而异，使用前查看工具说明。已经运行的进程不会自动继承后来修改的变量，应从新环境重新启动测试程序。

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 的值使用 HTTP 地址并不必然错误，它可以表示经 HTTP 代理建立到 HTTPS 目标的隧道。不要仅凭变量名称就把地址前缀改成不受支持的协议。容器、虚拟机和部分子系统内的 127.0.0.1 指向自身，不能直接套用宿主机回环地址。若需要跨环境连接，应先确认宿主机地址、监听范围和防火墙，并限制访问来源，避免把本地代理暴露到不可信网络。

只有确认需要时再启用 TUN

若目标应用不支持代理，可使用客户端提供的 TUN 功能，但应先检查所需权限、虚拟网卡、路由与 DNS 接管。系统代理和 TUN 可以在某些客户端里协同存在，却不是同时打开就更可靠。诊断时一次保留一种接管路径，避免请求被重复转发或被另一套 VPN 路由截走。虚拟网卡存在也不代表路由正确，应以目标应用的实际连接记录为准。

若浏览器正常而命令行失败，先显式指定代理验证；若所有应用都不进入连接记录，先检查监听与接管；若记录存在却走了错误出口，再检查规则。修复后测试代理目标、直连目标和局域网设备，确认没有牺牲打印机、文件共享或工作网络。退出客户端后还要检查系统代理是否正常撤销，把恢复过程也验证一遍，才能避免下次开机出现遗留地址导致的断网。

客户端崩溃：分开检查界面、内核与后台服务

先观察哪个进程退出。界面打不开、窗口卡住、内核停止和后台服务启动失败并不是同一种故障。若窗口关闭后代理仍可用，可能只是界面进程异常；若窗口正常但端口不再监听，应看内核与服务日志。记录操作系统提示、异常时间和最后一次动作，例如更新配置、切换 TUN、唤醒设备或更换网络，避免只留下无法复现的“突然闪退”。

保留证据，再做最小启动

先从客户端入口导出必要日志，或在程序数据目录查找对应时间段的记录。分享前删除订阅地址、节点凭据、访问历史和本地用户名等信息。不要直接上传整个配置目录，它可能包含账户数据和控制接口参数。日志太长时截取启动到报错附近的片段，同时保留错误前的上下文；只贴最后一行往往无法判断是配置问题还是运行环境问题。

备份后切到一份最小本地配置，暂时关闭自动更新、外部规则下载、TUN 与开机启动，再启动客户端。最小配置可以运行，说明应逐项恢复原设置，找出触发异常的功能；最小配置仍不能运行，则检查安装文件、系统组件、目录权限和进程冲突。不要同时删除配置、重装和更新系统，否则即使恢复，也无法知道真正生效的修复步骤。

检查权限、架构与端口冲突

从客户端下载页按系统和处理器架构选择安装包，普通用户可先考虑 Clash Plus；需要其他界面或部署方式，再选择 Clash Verge Rev、FlClash 等适用选项。旧系统支持情况应以客户端当前要求为准，不要假定所有新安装包都能在旧环境运行。Clash for Windows 与 ClashX Meta 已停止维护，迁移时保留可用配置，重新核对接管与服务设置，不要复制整个旧程序目录覆盖新客户端。

启动日志若提示地址被占用，先确认占用者，而不是随机结束系统进程。Windows 可使用下面的命令查看示例端口对应的进程编号，再在任务管理器核对程序；Linux 可用 ss 查看监听状态。若确实是另一个代理实例，退出重复实例或在设置中更换端口，并同步修改系统代理与应用入口。日志中的端口可能是控制接口而非代理端口，要按字段分别处理。

# Windows：查看示例端口
netstat -ano | findstr :7890

# Linux：查看 TCP 监听
ss -lntp

服务安装、虚拟网卡创建和普通界面运行需要的权限可能不同。只在文档要求的步骤授予必要权限，不要长期使用高权限启动全部程序来掩盖目录权限错误。安装目录受保护、数据目录只读或磁盘空间不足，都可能导致配置写入失败。若安全软件隔离了组件，先核对来源和事件记录，再按设备管理要求处理，不应直接关闭整套防护来尝试。

处理休眠恢复与持续资源增长

若只在休眠唤醒或网络切换后异常，先重新连接网络，再重启内核，观察是否恢复。网络接口编号、默认路由和 DNS 服务器都可能在恢复后改变，旧的 TUN 状态未必继续适用。确认客户端具备相应恢复设置后，再决定是否启用自动重连；自动循环重启会抹去现场，且可能打断正常连接，不能代替定位。

若运行越久越卡，观察内存、处理器和磁盘写入是否持续增加，记录发生增长的时间与业务。过量日志、极大的规则集合和频繁健康检查都值得对照，但不能仅凭资源占用偏高就认定存在某种缺陷。逐项减少自定义配置、恢复普通日志级别，并比较相同时间长度。更新或迁移后先验证稳定运行，再恢复开机启动；Linux 后台服务的目录与日志检查可参考mihomo 与 systemd 部署说明。

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

先确认系统是否已经建立当前客户端的 VPN 连接，再测试目标应用。移动端通常通过系统 VPN 接口接管流量，状态栏图标只是连接状态提示，不能证明订阅、DNS 与远端出口都正常。设备上若还有工作 VPN、防火墙或其他网络过滤应用，可能竞争同一接管位置。先明确当前由哪个应用负责接管，再处理规则和节点，避免两个工具轮流覆盖设置。

Android：先看授权与后台限制

启动 Clash Plus、Clash Meta for Android 或 FlClash 时，按系统提示确认 VPN 授权；拒绝授权后，界面可能仍能查看配置，但应用流量不会按预期进入隧道。若点击连接没有授权提示，检查系统 VPN 设置中是否存在旧配置、始终开启连接或阻止未经过 VPN 的连接选项。修改这些选项前记录原状态，工作设备还应遵循管理策略，不能擅自移除单位要求的连接。

前台正常、锁屏一段时间后失效，优先检查电池优化、后台活动和自动启动限制。不同系统厂商入口不同，应以设备设置为准。对客户端允许必要的后台运行后，进行一次锁屏与唤醒对照，观察连接是否保留。不要一次性给所有应用放开限制；只调整确实负责网络接管的客户端，并检查系统是否提示耗电或后台服务被终止。

若只有部分应用不经过代理，查看是否启用了按应用包含或排除列表。列表模式与全局接管的含义不同，应用更新、工作资料隔离或分身功能也可能让原先的选择不再覆盖实际进程。先用普通浏览器做基准，再测试目标应用。应用内部安全 DNS、独立网络栈和账户地区限制，都可能造成与浏览器不同的结果，不应仅凭一个应用失败就判定整个 VPN 无效。

iOS：检查连接配置与目标业务

iOS 可从iOS 客户端入口查看首推的 Clash Plus，并核对官网 clashplus.io。首次连接时完成系统要求的 VPN 配置授权，再回到客户端确认启用的订阅与策略。若系统中保存了多份 VPN 配置，检查当前激活的是哪一份；删除旧配置前先确认其用途，避免误删工作连接或其他仍需使用的网络配置。

浏览器可以访问而某个应用失败时，先在连接记录里查目标是否出现，再区分未接管、规则错误与服务端拒绝。部分业务会依据账户地区、设备位置或既有会话决定功能，切换出口并不会自动改变这些条件。重启目标应用可用于排除旧连接影响，但不应把清空全部应用数据作为首选步骤。涉及付款、账户验证或工作认证时，先恢复稳定网络，再按服务方指引处理。

切换无线网络与蜂窝网络后重新验证

从无线网络切到蜂窝网络时，本地地址、解析器、IPv6 条件与出口路径可能同时变化。若切换后立即断流，先等待系统网络就绪，再重新建立客户端连接。分别记录两种网络下的结果：只在无线网络失败，检查认证页和路由器；只在蜂窝网络失败，检查信号、套餐状态与运营商路径。不要在驾驶或其他不适合操作设备的场景下进行连续测试。

手机已经通过客户端联网，不代表开启热点后连接的电脑也自动经过代理。热点转发流量是否被接管取决于系统能力、路由和客户端实现，不能从手机上的 VPN 图标推断。对其他设备共享代理还涉及监听范围、身份验证和防火墙，应按明确的局域网方案配置；普通用户优先在每台设备安装适用客户端，分别验证，不要把手机回环地址填写到电脑代理设置中。

排查完成后依次测试前台访问、锁屏恢复、无线与蜂窝切换，以及一个需要直连的本地服务。保留最少量的必要后台权限，恢复临时调试设置。若问题仍可复现，整理设备系统、客户端名称、网络类型、失败时间和脱敏日志，再向对应维护方或服务提供方反馈。基础术语可在术语手册查阅；需要重新建立配置时，返回入门指南按主线逐步验证，不必继续叠加未知参数。