Clash 故障排查
连接、订阅与系统代理

无法上网：先区分故障层

“开启 Clash 后网页打不开”并不能直接说明节点失效。网络认证未完成、系统代理指向旧端口、规则命中拒绝策略，以及 DNS 请求无法返回，都可能表现为相同的浏览器错误。先确定故障发生在客户端启动之前还是之后，再判断是全部应用受影响，还是只有某个网站或程序异常。

关闭接管，确认基础网络能用

在客户端内关闭系统代理和 TUN 模式，保持客户端窗口打开，访问平时可以直接打开的网站。如果仍失败，检查无线网络是否连接、网关是否可达，以及酒店或校园网络是否需要网页登录。不要在基础网络尚未恢复时反复更换节点，这会把网络本身的问题与代理出口问题混在一起。

退出客户端后网络反而持续中断时，到系统网络设置查看是否残留手动代理。先记录地址与端口，再关闭失效的代理设置。若设备由单位管理，代理可能属于组织网络策略，不应直接删除。恢复基础网络后重新启动客户端，只开启系统代理进行第一轮测试，暂时不要同时引入虚拟网卡和自定义 DNS。

观察连接记录，判断流量有没有进入内核

打开连接列表或日志页，清空旧记录后重新访问一个明确的目标地址。有对应连接，说明请求至少进入了内核，应继续查看匹配规则、出口策略与错误原因；完全没有记录，则优先检查应用是否遵循系统代理、浏览器是否另设代理，以及内核是否真正启动。界面显示运行中，不等于监听端口一定可用。

连接记录中的拒绝、解析失败、连接超时分别指向不同层面。拒绝通常需要核对规则或出口策略；解析失败先查 DNS；连接超时再检查节点地址与网络路径。记录目标域名、命中的策略组和最终节点，避免只看日志里最后一行错误。后台更新失败也可能出现在同一日志页，但不一定影响当前网页请求。

规则分流：核对命中顺序与最终出口

规则模式按顺序匹配，通常由最先命中的规则决定去向。先看异常连接命中了哪条规则，再确认该规则使用的策略组是否存在、组内选择是否有效。如果全局模式可用而规则模式失败，应重点检查分流配置，不必立刻重装客户端。全局模式只能作为对照测试，不能证明所有网站都适合经过同一个出口。

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

这段示例假定已有名为 Proxy 的策略组，不能脱离完整配置单独运行。末尾的 MATCH 负责处理前面未匹配的连接；组名的拼写与大小写必须和定义一致。域名规则依赖连接保留域名信息，IP 规则则可能触发解析，因此同一站点的不同连接不一定命中同一条规则。

用最小变化验证恢复结果

选择一个已经确认可用的节点，保留默认接管方式，重试原来失败的网站，再测试另一个网站。若只有单个服务失败，检查服务自身状态、账户限制和出口地区要求，不要将它扩大判断为整个客户端故障。若所有请求都失败，按下一章检查节点；若只有部分应用没记录，转到系统代理失效章节。

节点超时：分开测试路径

节点测试超时，表示客户端在测试条件下没有按时得到预期响应，不等于节点在所有用途下都不可用。测试地址访问失败、节点域名解析错误、认证信息失效和传输握手异常，都可能得到类似结果。应把本地网络到服务器、协议握手和服务器到目标网站三个阶段分开判断，不能仅凭测试按钮的颜色下结论。

先确认测试对象与实际选择

查看当前连接使用的是单个节点、自动选择组还是回退组。某些策略组内部还有另一层策略组，界面最外层的名称并不是实际出口。到连接详情展开最终链路，确认正在使用的节点与刚才测试的是同一个。若组内自动选择仍在变化，临时固定一个候选节点，减少测试期间的变量。

对比两类结果：客户端内置测试是否失败，以及浏览器通过该节点访问普通网页是否失败。内置测试依赖指定的测试地址，远端站点限制访问或返回方式改变时，实际浏览可能仍然正常。不要为了让测试显示成功而随意填写陌生地址；优先使用客户端默认测试目标，并确认该目标在当前网络条件下是否可访问。

按报错判断解析、连接与认证

日志提示主机不存在、无法解析服务器地址时，先检查节点服务器域名和本地 DNS。提示连接被拒绝，通常说明目标地址返回了明确拒绝，可能是端口错误或服务未监听。提示连接超时，则可能是链路丢包、访问受限或服务器未响应。这些信息只能缩小范围，不能单独证明服务器永久离线。

出现认证失败、握手失败或证书错误时，核对订阅是否仍有效、设备时间是否准确，以及客户端内核是否支持该节点配置。不要通过关闭证书验证来掩盖问题；证书名称、服务器名称与传输参数需要由配置提供方确认。把日志中的错误类别和时间反馈给提供方即可，不必把节点密码或完整连接串发到公开讨论区。

通过更换网络建立对照

在相同设备、相同配置下，分别使用家庭网络和手机热点测试。若仅在某一网络失败，重点检查该网络的认证、访问策略与 DNS；若多个网络都失败，而同订阅其他节点正常，更可能是单个节点或协议参数问题。使用热点会消耗移动数据，先完成小规模网页验证，不必立刻进行大文件测速。

也可以在另一台设备上使用同一条有效订阅进行测试，但要遵守订阅服务的设备数量与并发限制。另一台设备能用，只能说明配置在那个环境中成立，还需要比较内核支持、系统时间和接管设置。避免同时开启多个客户端测试同一个账户，以免账户侧的并发限制引入新的超时或断流。

区分节点失效与特定协议受限

网页能打开而语音、游戏或实时通信失败时，检查应用是否依赖 UDP，以及节点、策略组和接管方式是否支持相应流量。HTTP 代理能够承载的应用行为，与虚拟网卡接管并不完全相同。不要把某项实时功能失败直接归因于节点整体不可用，也不要仅凭网页正常就认定所有传输方式都已通过验证。

确认节点失效后，手动更新订阅并选择其他可用节点。持续增加超时时间只能延长等待，不能修复错误地址、认证失败或不可达链路。如果更新后仍全部失败，转到订阅章节核对配置来源；客户端选择与系统适配可在下载中心查看，首次选择优先考虑 Clash Plus。

订阅失败：检查返回内容

订阅导入包含获取内容、解析格式和加载配置三个步骤。链接请求失败与 YAML 语法错误不是同一种问题，处理顺序也不同。先抄下完整错误提示，判断错误发生在下载阶段还是配置加载阶段。原来已经生效的配置通常仍可作为恢复入口，在确认新订阅可用之前，不要先删除全部旧配置和节点。

确认链接完整且账户状态正常

从服务提供方的账户页面重新复制订阅链接，避免聊天软件换行、浏览器省略显示或手动选择不完整。检查前后是否夹带空格和引号，尤其留意查询参数是否被截断。订阅地址通常包含访问凭据，不应贴到公开帖子、在线格式化工具或不熟悉的转换服务中；截图时也要遮住地址栏和二维码。

如果账户已到期、流量额度耗尽或订阅链接已重置，客户端重试不能恢复权限。先在服务方页面确认状态，再使用新链接更新。浏览器打开链接后出现登录页、验证码、访问拒绝或普通网页，说明客户端获得的未必是配置内容。不要把这类网页另存为 YAML 导入，它仍然无法通过配置解析。

区分网络错误、状态码与格式错误

请求超时或连接失败时，先确认设备基础网络和系统时间。若配置页面提供下载经过直连或代理的选项，可在记录原设置后做一次对照；需要代理才能更新的订阅，必须先有可用出口，不能依赖尚未导入的节点。没有任何可用配置时，应向提供方获取可在当前网络访问的正规导入方式。

权限相关状态码通常需要检查账户或链接，频率限制则应暂停反复刷新，按服务方提示等待。解析错误更关注返回格式：为其他客户端生成的节点列表、单条分享链接与 Clash 配置文件并不等价。确认订阅页面选择了适合 Clash 或 mihomo 的输出类型，再尝试导入，避免盲目修改扩展名。

config.yaml：从首个错误位置排查

YAML 对层级和缩进敏感。优先检查报错附近的行与前一行，使用空格而非制表符缩进，核对冒号、列表短横线和引号是否配对。报错位置可能只是解析器发现异常的地方，真正原因可能在更早的未闭合字符串中。编辑前复制原文件，修复一个错误后重新加载，不要一次重排整份配置。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
  enable: true
  listen: 127.0.0.1:1053

这段仅用于说明层级关系，不包含节点与策略组，不是完整订阅。顶层字段与 dns 同级，enable 和 listen 属于 DNS 子项。除语法外，还要检查策略组引用了不存在的节点、规则使用了未定义的组名，或配置包含当前内核不认识的协议字段；这些问题需要结合加载日志判断。

检查覆写与自动更新是否改变结果

订阅源文件正确，生效配置却报错时，检查客户端的配置合并、脚本处理和覆写功能。先备份这些自定义内容，再临时停用后重新加载，以区分订阅原始问题与本地加工问题。不要直接修改缓存文件作为长期修复，因为下一次更新可能覆盖它；需要保留的设置应放在客户端支持的持久化覆写位置。

自动更新失败不一定意味着当前连接失效。查看最近一次成功时间和失败原因，先手动更新一次，确认新配置可加载，再设置合理间隔。设备休眠、后台限制与网络切换都可能使定时任务延后。更细的检查顺序见订阅链接解析失败自查清单；导入操作位置见订阅导入教程。

速度慢：拆开延迟与吞吐

网页开始加载慢、下载速率低和视频频繁缓冲，可能分别对应解析等待、往返延迟和持续传输能力不足。客户端测试结果主要用于观察特定请求的响应时间，不能直接等同于下载带宽。排查时先选一个稳定复现的任务，例如同一网页或同一文件，记录网络、节点和时段，再改变单个条件比较。

先建立直连与代理的速度基线

关闭其他下载、云同步和系统更新，确认同网络中的其他设备是否占满带宽。使用可以直接访问的资源观察基础网络表现，再通过代理访问相同或相近资源。如果直连本身就慢，应先处理无线信号、路由器负载或宽带链路；客户端无法扩大接入带宽，也不能消除网络拥塞造成的丢包。

无线网络测试容易受距离、频段和周边干扰影响。电脑可临时使用有线网络，手机可在路由器附近复测，但要保持其他条件一致。不要拿不同站点的瞬时峰值直接比较节点优劣，站点服务器、内容分发路径和账户限速都可能不同。持续传输中的稳定速率通常比刚开始几秒的峰值更有参考价值。

按加载阶段定位瓶颈

点击链接后等待很久才开始显示，但显示后图片加载较快，优先查 DNS、连接建立与握手；页面立刻出现而大文件长期很慢，再查出口带宽与远端限制。若仅首次访问慢，后续明显改善，可能涉及解析缓存、连接复用或资源缓存。复测时说明是否为首次访问，避免把缓存差异误判为配置优化效果。

观察客户端连接列表，确认慢请求确实走了预期节点。一个页面通常连接多个域名，主站、图片和视频资源可能命中不同规则。只切换页面主域名的规则，不一定改变媒体连接的出口。先找出实际缓慢的资源域名和最终策略，再决定调整哪个规则，不要为了修复一个视频将全部流量长期切到全局模式。

比较节点线路，而非只看地理距离

距离近不一定路由短，测试响应快也不一定持续下载快。选择两三个已确认可用的节点，在相近时间完成相同测试，比较连接稳定性、丢包表现与持续传输。若只在晚间拥塞，记录发生时段交给服务提供方；若某一站点始终慢而其他站点正常，更可能涉及目标服务、出口地区或内容分发路径。

设备性能也会影响速度。观察系统任务管理工具中的处理器占用和内存压力，关闭大量闲置连接与重复运行的代理工具。详细日志可短时帮助定位，但长期保持高频调试输出会增加存储写入与处理开销。完成排查后恢复常规日志级别，不要把关闭所有日志当成普遍有效的提速方法。

谨慎处理 MTU、IPv6 与实时流量

只有开启 TUN 后才出现大文件停顿、部分页面卡住，而系统代理正常时，可以检查虚拟网卡、路由和路径 MTU。先恢复客户端默认设置，再按客户端文档进行单项调整，并记录原值。MTU 过大可能导致某些路径传输异常，过小也会增加开销；不存在适合所有宽带、热点和隧道的固定最佳数值。

IPv6 支持不完整、UDP 不可用或实时应用使用不同传输路径，也会让网页测速与实际体验不一致。按应用需求分别验证，不要仅凭一次测速关闭系统全部 IPv6。若问题只在特定接管方式出现，参考TUN 模式与系统代理对比，确认接管范围后再修改设置。

DNS 问题：确认解析由谁处理

DNS 故障常表现为域名打不开、某些应用提示离线，或连接日志中反复出现解析失败。系统解析器、浏览器安全 DNS、客户端内置 DNS 与节点服务器域名解析，可能同时参与一次访问。先确定哪一层返回错误，再决定修改位置；只把系统 DNS 改成某个公共地址，不一定会影响客户端实际使用的解析路径。

分别观察系统与客户端的解析结果

先在终端使用系统工具查询一个公开域名，确认系统能否得到响应，再查看客户端日志中同一域名的处理结果。下面的命令用于检查系统当前解析路径，不能单独证明代理链路正常。如果系统查询成功而客户端失败，应检查内核 DNS 设置；若系统也失败，继续检查网络认证、解析器可达性和本地网络策略。

nslookup example.com

查询超时与域名不存在含义不同。前者可能是解析器没有响应，后者可能是域名确实不存在或解析结果异常。还要检查是否只有节点服务器域名失败：内核需要先解析服务器地址才能建立代理，这一步如果又依赖尚未建立的代理，就会形成循环。应依据客户端文档配置节点域名解析路径，而不是随意复制整段 DNS 模板。

理解 fake-ip、缓存与浏览器安全 DNS

启用 fake-ip 后，客户端可能向应用返回专用地址段中的映射地址，再由内核关联真实域名。这是接管机制的一部分，不能仅凭查询结果不是公网地址就判断解析异常。关键在于后续连接是否仍回到同一个内核，以及映射是否存在。流量绕过客户端而直接连接映射地址时，应用可能表现为连接失败。

浏览器启用独立安全 DNS 后，可能绕过系统解析路径，导致浏览器与其他应用表现不同。排查时记录当前设置，再临时使用系统解析做对照。不要同时更换浏览器解析器、客户端上游和系统 DNS，否则恢复后无法知道是哪一步有效。对于局域网设备名称和内部域名，应保留网络本身需要的解析路径。

切换配置后旧连接与缓存可能继续使用之前的结果。先关闭出错页面并重新建立连接，再考虑清理对应层的缓存。Windows 可使用下方命令清理系统解析缓存；它不会清理客户端内部缓存或浏览器自己的缓存，也不能修复不可达的上游服务器。其他平台应按系统文档操作，避免运行来源不明的一键网络重置脚本。

ipconfig /flushdns

GeoIP 更新：与 DNS 数据分开检查

GeoIP 数据用于按 IP 地理归属参与规则判断，并不负责将域名转换成 IP。数据下载失败时，先看日志是否明确提到资源文件、下载地址或读取错误，再检查客户端的数据更新入口、存储权限与网络。不要因为某个域名打不开就直接重建地理数据库，尤其不要混淆域名规则数据、IP 地理数据和 DNS 缓存。

如果日志报告数据库缺失，先使用客户端支持的更新功能，完成后重新加载配置并确认错误消失。数据来源与格式应和当前内核及配置匹配，不能只把其他格式文件改名后替换。若更新需要代理而当前出口不可用，先恢复一个有效出口，或按客户端文档使用可达的下载方式，避免不停触发相同失败任务。

处理 IPv6 与局域网解析边界

域名可能同时返回 IPv4 和 IPv6 地址，但当前网络不一定具备完整的 IPv6 出站路径。若日志显示仅 IPv6 连接失败，应比较系统、内核与节点的支持情况，再做临时对照测试。不要长期屏蔽所有 IPv6 来代替定位。打印机、网络存储和单位内部域名失效时，先检查它们是否错误进入代理解析或代理出口。

恢复时以“目标应用能访问、连接走预期策略、内部资源仍可用”为标准，而不是只看一次查询结果。需要了解配置字段所属层级，可阅读config.yaml 结构详解；常见概念可在帮助中心继续查阅。

系统代理失效：核对监听与接管

系统代理是操作系统向应用提供的代理设置，不是强制接管所有网络流量的开关。浏览器可能遵循它，命令行程序、游戏或部分商店应用却可能使用自己的网络栈。因此，“浏览器能用而终端不能用”并不必然是设置失效。先确定目标程序支持哪种代理方式，再检查客户端监听地址与系统设置是否一致。

确认实际监听端口与系统地址一致

在客户端设置或生效配置中查看混合端口，不要默认所有设备都是 7890。系统代理应指向当前设备的回环地址与实际监听端口。若曾运行另一个客户端，它可能保留旧端口或在后台反复改写系统设置。先退出其他代理程序，再关闭并重新开启当前客户端的系统代理，观察系统设置是否同步变化。

使用支持代理参数的命令行工具，可以绕过系统代理开关直接测试本地端口。下面命令假设客户端在本机监听 7890，实际使用时应替换为设置中确认的端口。如果显式代理可用而浏览器失败，重点检查浏览器独立设置、扩展和系统代理；若显式代理也失败，则回到监听、节点与规则层排查。

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

区分图形应用、终端与系统服务

终端中的某些工具读取环境变量，另一些只读取各自配置文件；Windows 的不同代理接口也可能服务于不同类型的程序。修改某一套设置，不代表全部系统服务都会改变。先查看目标工具的代理文档，使用单次命令参数测试，确认有效后再决定是否持久化，避免把代理变量写到全局环境后忘记恢复。

显式代理参数成功，但常规命令失败时，检查工具是否设置了独立代理、直连例外或旧环境变量。变量中的地址应与当前客户端一致，例外列表也可能让目标域名绕过代理。排查只修改目标工具的设置，不必立即重置整个系统网络。关闭客户端后，还应检查是否留有指向已停止端口的持久化配置。

需要 TUN 时，先验证权限与路由

TUN 通过虚拟网络接口接管流量，可覆盖部分不遵循系统代理的应用，但通常需要相应系统权限、服务组件和路由支持。开启失败时先看客户端日志中的权限、设备创建或路由错误，不要反复点击开关。安装服务或授权网络扩展应使用客户端提供的正常流程，完成后检查内核是否真正建立接口。

其他 VPN、虚拟机网络、容器网络和安全软件可能与路由规则冲突。先记录正在运行的网络工具，在允许的前提下逐个暂停做对照，不要直接关闭系统防火墙或删除未知网卡。远程连接设备时尤其谨慎，调整默认路由可能立即断开远程会话；应具备本地操作或其他恢复通道后再继续。

局域网共享与退出后的恢复

其他设备连接电脑代理时，不能填写 127.0.0.1，因为这个地址始终代表设备自身。需要填写电脑在当前局域网中的地址，并确认客户端允许局域网连接、监听范围正确且防火墙仅放行必要网络。不要把代理端口暴露到公网；不再共享时关闭相关设置，地址变化后也要同步更新设备端配置。

正常退出前先关闭系统代理与 TUN，再确认直连恢复。若强制结束进程后出现断网，手动关闭残留系统代理，并重新启动客户端让其完成清理。完整的共享步骤见混合端口与局域网连接说明；基础开关位置见系统代理设置教程。

客户端崩溃：保留配置再恢复

窗口闪退、界面空白、内核反复重启和无法保存设置，需要分开处理。图形界面负责展示与管理，内核负责实际代理，两者可能独立异常。先看进程是否仍存在、托盘是否可打开，以及代理端口是否继续监听。界面关闭但网络仍通，可能只是窗口隐藏；内核退出但界面仍在，也可能被误认为节点全部失效。

先判断安装、权限与运行环境

确认安装包平台与处理器架构匹配，系统版本满足客户端要求。macOS 要区分 Apple Silicon 与 Intel，Linux 要确认发行版及软件包类型，Windows 则检查系统安全提示与安装目录权限。不要从不明弹窗下载所谓修复组件，也不要为了启动程序长期关闭系统安全机制；优先使用客户端文档描述的安装和授权方式。

安装到受保护目录、便携运行目录不可写，或磁盘空间不足，都可能导致设置无法保存和启动失败。检查客户端实际使用的数据目录，而不只是程序安装目录。单位设备可能限制后台服务和网络扩展，此时需要按设备管理规则处理。以管理员权限运行可以作为有依据的测试，但不能代替修复错误的目录权限。

区分界面故障与内核加载失败

界面可打开但内核无法启动时，先读取启动日志。端口被占用、配置字段错误、策略组引用无效和数据文件缺失，通常会给出明确提示。不要立刻删除全部用户数据；先用客户端内置校验或加载功能检查配置，再停用最近添加的覆写、脚本和规则资源。恢复到之前可用配置后，逐项重新加入修改。

出现端口冲突时，查明占用者是否为旧客户端或残留内核，再正常退出对应程序。确需改端口，应同时更新系统代理、终端配置和共享设备设置。只改配置中的监听端口而保留旧系统地址，会把启动问题变成新的断网问题。对于界面空白或渲染异常，可按客户端文档检查图形运行环境，避免套用其他软件的启动参数。

备份后重建最小运行环境

进行重置或重装前，导出订阅配置、记录策略组选择，并备份覆写内容和必要设置。备份应保存在个人可控的位置，因为其中可能包含订阅凭据与节点认证信息。只卸载程序未必删除用户数据，因此“重装后仍崩溃”并不能证明安装包有问题，旧配置或缓存可能在重新启动时再次加载。

客户端提供重置功能时，先阅读其影响范围；没有明确说明时，可在完全退出相关进程后备份并暂时移开数据目录，而不是直接永久删除。重新启动后先保持默认设置，确认空白环境能稳定打开，再只导入一份已知有效配置。若刚导入就复现，重点检查该配置和资源；若空白环境也崩溃，再查系统兼容与安装环境。

选择维护中的客户端并整理反馈

新安装优先考虑 Clash Plus，也可按平台在 Clash Verge Rev、FlClash 等客户端中选择。Clash for Windows 与 ClashX Meta 已停止维护，旧环境中的问题未必能通过重新安装解决。切换客户端前先确认订阅格式兼容，避免直接复制整个用户目录；配置文件、应用设置和缓存数据通常不能作为同一种内容迁移。

反馈应包含系统平台、处理器架构、客户端名称、实际安装信息、触发步骤和最后几行相关日志。不要编写无法复现的结论，例如仅凭一次闪退认定系统不支持。日志中出现的账户、订阅和节点信息应先脱敏；若排查时启用过详细日志，问题解决后恢复常规级别，并按需清理本地诊断文件。

移动端问题：检查 VPN 与后台

手机上的代理连接依赖系统 VPN 接口或网络扩展，与桌面系统代理的工作方式不同。状态栏出现 VPN 标志，只能说明系统建立了相应接口，不能证明订阅、节点和分流都正确。先在客户端前台完成一次连接测试，再观察锁屏、切换应用与更换网络后的表现，把初次连接失败与后台中断分开记录。

Android：确认授权与其他 VPN 冲突

首次连接时完成系统 VPN 授权，并确认当前启用的是目标客户端。过滤工具、工作配置和其他 VPN 应用可能争用同一接管位置，表现为连接刚建立就断开。先按系统设置查看当前 VPN，不要同时反复启动多个应用。若设备由单位管理，工作区域与个人区域的网络策略也可能不同，应分别确认适用范围。

只在锁屏后断流时，检查系统是否限制客户端后台活动、电池使用或移动数据。将客户端加入系统允许的后台范围，再复测锁屏场景；各厂商设置名称不同，以实际系统页面为准。不要把所有应用都设为不受限制，也不要仅因通知消失就判断代理停止，仍应结合客户端状态与实际访问结果确认。

Android 的按应用代理设置可能选择只接管指定应用，或排除某些应用。若一个浏览器能访问而另一个不能，先核对应用是否在接管范围内，再查规则。更新应用或切换工作配置后，也要重新检查选择结果。基础导入与授权流程见Android 上手步骤，不要用桌面教程里的系统代理开关名称硬套手机界面。

iOS：确认网络扩展与配置已启用

iOS 可优先选择 Clash Plus，通过iOS 下载入口查看商店链接，客户端官网为 clashplus.io。完成系统授权后，还要确认订阅已经加载、策略组有有效选择。只创建 VPN 配置而未导入可用节点，无法完成实际代理连接。

从其他网络工具切换过来时，检查系统当前使用的 VPN 配置是否正确，并在旧工具中关闭可能自动重连的选项。应用内显示连接成功后，用同一网页复测；若只有一个应用异常，检查它的独立网络行为和分流结果。不要反复删除全部系统配置，先确认问题是否由旧工具重新接管引起。

切换无线网络、蜂窝网络与热点

从无线网络切到蜂窝网络后，原有连接可能仍依赖旧地址和旧路径。先等待网络稳定，再在客户端内断开并重新连接，以重新建立会话。若只有蜂窝网络失败，检查客户端与目标应用是否被允许使用移动数据，并比较节点域名解析和网络协议支持。不要在切网瞬间的短暂失败后就判定订阅失效。

公共无线网络需要网页认证时，先暂停代理并完成网络登录，再恢复连接。手机分享热点也不代表连接到热点的设备会自动经过手机代理，系统对共享流量的处理与手机本机流量可能不同。需要共享时，应使用客户端和系统明确支持的方式，并参考局域网代理共享说明核对地址与安全边界。

保留可回退设置，完成最终验证

Android 的始终开启 VPN、阻止未经过 VPN 的连接，以及客户端的自动连接选项，可能在服务停止时让设备表现为完全断网。先记下这些选项当前状态，再按系统说明暂时关闭进行对照；完成排查后根据使用需求恢复。应用删除或配置失效后，也要检查系统是否仍要求通过一个已经不存在的连接出站。

移动端最终验证至少包含前台访问、锁屏后恢复、无线与蜂窝切换三个场景。每次使用同一目标，查看实际出口是否符合预期，不要只看状态栏图标。若仍无法定位，整理设备系统、网络类型、客户端名称、错误时间与脱敏日志，再到帮助中心核对常见问题；重新配置时回到入门指南，沿单一主线逐步恢复。