Clash 故障排查手册

无法上网：建立网络基线

“无法上网”可能发生在无线连接、系统路由、本地代理入口、规则选择或远端出站中的任何一层。开始前记录客户端名称、操作系统、当前模式，以及故障是全部应用还是单个网站出现。保存正在使用的配置副本，截图时遮住订阅地址、密码和连接凭据。不要同时更新客户端、重置网络和更换订阅，否则即使恢复，也难以判断真正起作用的是哪一步。

先断开代理，再测试基础网络

在客户端关闭“系统代理”和“TUN 模式”，随后正常退出客户端。打开系统网络设置，确认手动代理没有遗留指向本机的地址；移动端则确认 VPN 已断开。访问一个平时能够直连的 HTTPS 网站，再检查路由器管理页是否可达。如果此时依然无法联网，先处理无线认证、网关、宽带连接或公共网络登录页。基础网络未恢复之前，更换节点通常不会改变结果。

公共 Wi-Fi 经常要求网页认证。先断开 VPN，按系统提示完成认证，再重新连接客户端。若只有一台设备异常，用同一网络中的另一台设备对照；若所有设备都异常，应优先检查路由器与上游网络。也可以临时切换手机热点作为对照，但热点下恢复只说明问题与原网络相关，不能直接证明订阅失效。记录两个网络的差别，后续再检查 DNS、UDP 或防火墙限制。

验证本地入口与实际出站

重新启动客户端，选择已成功载入的配置。先保持 TUN 关闭，只开启系统代理。进入“设置”查看实际的 HTTP 或混合代理端口，再用显式代理请求测试。下面命令仅适用于客户端端口确实为 7890 的情况；若界面显示其他端口，应同步修改。Windows PowerShell 中使用 curl.exe，避免命令别名导致参数含义不同。测试地址也可换成正在排查的目标网站。

# 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/

立即出现“连接被拒绝”，通常表示本地端口没有监听、端口填错或内核未启动，不应先归因于远端节点。能够连接本地代理但随后超时，则继续查看客户端“连接”和“日志”。若日志显示请求命中 DIRECT，检查规则与目标域名是否符合预期；若命中代理策略组，核对该组实际选中的出站。界面上的配置名称与正在使用的配置可能不是同一个，导入成功后仍需确认已启用。

缩小范围并恢复日常设置

只在必要时短暂切换“全局”模式，用同一目标重复测试。如果全局可用而规则模式不可用，应检查规则顺序、策略组名称和末尾兜底规则；如果两种模式均失败，转到节点超时章节。全局模式并不保证所有应用都已进入代理，未读取系统代理的程序仍可能直连。不要把模式切换和 TUN 开关同时改变，否则无法区分是规则问题还是流量接管问题。

如果退出客户端后仍然断网，先清除系统中残留的本机代理，再查看其他 VPN、虚拟网卡和安全软件是否接管路由。不要直接删除所有网卡或重置全部防火墙。先停止相关程序并重启系统，确认哪一项恢复了网络，再决定是否修复该组件。无法定位时保留错误发生的时间和首条错误日志，交给后续章节继续判断。

节点超时：区分探测与连接

客户端里的超时首先表示某次探测没有在指定时间内完成，不等于该出站对所有目标都不可用。探测需要经过域名解析、连接建立、协议握手和测试地址响应。任意一步失败都会表现为超时。先选择一个出站并实际访问目标网站，再对照日志中的错误。不要连续点击整组测试；大量并发探测可能触发服务端限制，也会让本地网络竞争掩盖原本的故障。

按错误出现的位置分类

打开“日志”，临时将日志级别调整为 info，清空旧记录后发起一次请求。若需要更细信息，再短时间使用 debug。查找首条与目标请求相关的错误，而不是只看最后一条“请求失败”。连接超时偏向网络不可达或端口受阻；连接拒绝通常表示目标主动拒绝；TLS 握手错误还可能涉及服务器名称、系统时间或证书。错误文字是线索，不是单凭一行就能成立的结论。

若错误发生在节点服务器域名的解析阶段，先转到 DNS 问题检查引导解析。若域名已解析但服务器端口无法建立连接，可在 Windows 使用以下命令测试 TCP 可达性。服务器名和端口需取自当前配置，命令中的域名只是教学地址。该测试只检查 TCP 连接，不能证明代理协议认证成功，也不能用于判断基于 UDP 的协议是否正常。

# 将域名与端口替换为当前出站的实际设置
Test-NetConnection -ComputerName proxy.example.com -Port 443

核对协议参数与系统时间

订阅导入的出站尽量先重新更新，不要逐项猜测修改。手动配置时检查服务器地址、端口、密码或用户标识，以及传输层、路径、服务器名称等参数。名称相近的协议并不互通，旧内核也可能无法识别新字段。查看配置加载日志是否有“不支持的类型”或字段解析错误，再决定更新客户端。更新入口使用客户端下载页，不要把不同客户端的数据目录互相覆盖。

HTTPS 目标和使用 TLS 的代理连接都会受到系统时间影响。进入系统“日期与时间”，启用自动同步并确认时区。证书错误不应通过长期关闭证书验证处理；先核对订阅提供方要求的服务器名称和证书设置。公司网络中的 HTTPS 检查、过期证书或错误的域名也可能触发握手异常。若仅办公网络失败而热点正常，应向网络管理方确认限制，而不是持续降低安全设置。

检查自动策略组的判断条件

url-test 使用配置的测试地址评估候选出站，fallback 按可用性与顺序切换，二者都依赖探测能否完成。测试地址不可达、返回行为变化或不适合当前网络时，策略组可能将可实际使用的出站标成异常。下面只是字段示意，应合并到已有策略组并保留真实候选列表；空的候选列表不能构成可用的代理组。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

示例中的 DIRECT 仅用于说明结构与直连探测，实际代理选择需改成配置中已有的出站名称。interval 是测试间隔秒数，不是连接超时；tolerance 是切换容差，也不会修复不可达的服务器。若手动选择可用而自动组反复异常，先检查探测目标与组内引用，再阅读策略组类型对照。

最后进行单变量对照：同一出站更换网络，同一网络更换出站，同一出站更换目标网站。只有一个目标失败，多半需要检查该目标的规则或服务限制；所有出站在同一网络失败，则回查本地防火墙、时间和网络限制。保留一组稳定可用的对照结果，比反复增加超时时间更有助于定位。调整后再次验证真实请求，不以界面探测颜色作为唯一恢复标准。

订阅失败：检查获取与解析

订阅更新由两个阶段组成：先通过网络获取响应，再将响应解析为配置或出站列表。“下载失败”和“配置无效”对应的排查方向不同。先查看订阅卡片或日志中的完整错误，记录 HTTP 状态、解析提示和发生时间。订阅链接通常带有访问凭据，不应发布到论坛、截图或在线转换工具。需要求助时仅保留域名类型、错误码和已脱敏的结构，不发送原始链接。

确认地址与账户状态

从订阅提供方页面重新复制完整链接，检查开头是否为正确的 HTTPS 地址，结尾参数是否被聊天工具截断。复制时不要带入中文标点、换行或空格。网页登录地址、分享页面地址和订阅接口不是同一类链接；能打开一个账户页面，并不能证明该地址返回的是客户端配置。若链接已经重置，旧链接即使保存在客户端中，也可能持续返回拒绝访问。

出现 401 或 403 时，先确认账户授权、订阅有效状态及接口访问要求。出现 404 时检查路径是否变化；出现 429 时停止频繁重试，按提供方说明等待。服务器错误则可能是上游暂时异常，不宜通过不断删除配置解决。部分接口会依据请求客户端返回不同格式，应选择提供方明确标注的 Clash 或 mihomo 兼容订阅，不要只凭文件后缀判断格式。

拆开下载链路与内容格式

若当前出站已经不可用，而订阅更新又被设置为通过该出站进行，就会形成“需要更新才能连接、需要连接才能更新”的循环。进入订阅更新设置，确认使用的是直连、系统网络还是代理；有条件时通过另一条正常网络更新。某些客户端的订阅下载由界面进程完成，另一些由内核完成，所以浏览器能访问不代表客户端请求一定相同。先核对日志，再调整更新路径。

如果响应内容是登录页、验证码页面或网关提示，客户端会把 HTML 当作配置解析，常见结果是首行语法错误。不要为了消除提示而删除第一行内容。需要查看响应时，在本机保存并用文本编辑器检查开头结构，避免上传到公共网站。有效 YAML 也可能不是完整配置：仅包含出站列表的内容，需要由 proxy-providers 引用，不能总是直接作为主配置启用。

修复语法并保护已有配置

手动编辑 YAML 时使用空格缩进，不混入制表符；包含特殊字符的密码与地址应使用合适的引号。错误行号有时指向解析器终于无法继续的位置，真正的问题可能在上一行的冒号、引号或列表层级。先导出一份副本，再只修改相关片段。不要把网上的整段配置直接覆盖进订阅文件，订阅更新通常会覆盖该文件，临时修改既难追踪，也容易丢失。

订阅下载成功却没有可选出站时，检查账户是否确实返回有效内容，以及筛选表达式是否排除了全部项目。若日志提示策略组引用不存在的名称，应核对本地覆写、订阅重命名和组内引用。先停用最近添加的覆写或合并脚本，重新载入原始订阅；原始配置可用后，再逐项恢复。需要回到标准导入流程时，参照订阅导入教程操作。

速度慢：拆分响应与吞吐

网页首屏慢、下载速度低、视频卡顿和语音中断不是同一种故障。网页更受解析、握手和多资源请求影响；大文件更依赖持续吞吐；实时应用还会受到丢包和抖动影响。先记录慢的是哪个应用、哪个目标、哪个时间段，以及直连时是否同样缓慢。不要直接用策略组探测结果推断下载速度，短请求响应快的出站，并不一定有更高的持续传输能力。

使用一致条件进行对照

固定同一设备、同一网络和同一目标，分别测试直连与一个手动选择的出站。暂停云盘同步、系统更新和其他大流量任务，避免背景传输干扰。无线网络下先靠近路由器，必要时使用有线连接对照。若局域网传输也很慢，优先检查信号、无线干扰和网卡；若只有某个远端站点慢，则可能涉及目标服务、线路互联或该站对访问出口的限制。

多次测试应保留相近的条件，而不是拿不同网站、不同文件和不同时间的结果相互比较。浏览器缓存可能让第二次访问显著变快，下载站也可能动态分配服务器。可用浏览器开发者工具中的“网络”面板观察等待首字节、连接建立和内容下载分别占用多少时间。等待首字节长不一定是带宽不足，可能是服务端处理、路径绕行或连接重试造成的。

检查分流与应用连接行为

打开客户端“连接”，按目标域名或进程筛选，确认慢请求命中的规则与实际出站。一个页面可能同时请求图片、脚本和接口，只检查主域名容易漏掉其中一个异常资源。广告过滤、浏览器扩展和安全软件也可能拦截资源，表现成页面一直等待。先用新的浏览器配置或临时关闭相关扩展做对照，不要在尚未定位时改动整份规则集。

自动策略组频繁切换可能使应用重连，尤其在持续下载或会话较长的场景中更明显。排查时先固定一个可用出站，观察问题是否消失，再调整测试间隔或切换容差。不要把间隔设得极短来追求“实时最优”；探测本身也会占用连接与流量。不同策略组的行为可参考url-test、fallback 与 load-balance 说明。

谨慎检查 UDP、MTU 与并发

视频或实时通信异常而普通网页正常时，检查应用是否使用 UDP，以及当前协议、出站配置和服务器是否支持相关流量。浏览器的 HTTP/3 也依赖 UDP，某些受限网络中可能反复尝试后才回退。可以短暂关闭应用的相关功能做对照，但不能据此认为所有 UDP 都应禁用。语音、游戏和部分隧道协议需要它，长期禁用可能制造另一类问题。

若只在 TUN 模式出现大文件停滞、小请求正常，应进一步观察是否与路径 MTU 有关。先确认没有同时运行另一套 VPN；再在客户端允许的范围内逐步降低 TUN 的 MTU，每次只改一个值并重新建立连接。不存在适合所有网络的固定最优值。若调整没有稳定改善，恢复原值，避免把临时绕过措施留成永久配置。MTU 测试还会受系统与链路类型影响，不宜照搬单条命令的结论。

最后查看设备资源状态。客户端长期占用异常时，检查是否开启大量调试日志、加载重复规则或同时运行多个内核；磁盘空间不足也可能拖慢日志写入。关闭调试级别并减少重复任务后重测。若更换网络或出站后稳定改善，保留该对照信息；若所有路径都只对单个目标缓慢，应联系目标服务或订阅提供方确认，不要仅凭一次测速认定本地软件损坏。

DNS 问题：理清解析路径

DNS 故障常表现为域名打不开、首次连接很慢、局域网设备名称失效，或日志出现解析超时。先区分三个问题：系统如何解析普通域名，内核如何解析目标域名，以及代理服务器自己的域名如何解析。三条路径可能由不同组件完成。直接访问某个 IP 能连通，也不能证明 HTTPS 服务正常，因为证书与虚拟主机仍依赖域名，不应把 IP 访问当成最终修复方法。

确认请求交给哪个解析器

在系统中查看当前网络接口的 DNS 设置，并使用下列命令获取基础解析结果。命令反映的是系统查询路径，不一定等同于浏览器安全 DNS 或内核内部解析。若浏览器启用了加密 DNS，它可能绕过系统解析器；若使用 TUN 的 DNS 劫持，普通查询又可能被内核接管。测试前写明当前是否开启这些功能，否则两个不同工具的结果无法直接比较。

# Windows
nslookup example.com
ipconfig /flushdns

# macOS / Linux：已安装 dig 时使用
dig example.com A
dig example.com AAAA

清理缓存只能移除旧结果，不能修复上游不可达或配置错误。应先调整解析路径，再清理系统与应用缓存并重新连接。查询返回 NXDOMAIN 表示没有找到对应名称，但仍需判断是域名本身不存在，还是上游响应异常；查询超时则更偏向路径或服务问题。不要将所有失败统一理解为“缓存污染”，也不要只凭不同解析器返回不同 IP 就认定其中一个错误。

理解 fake-ip 与引导解析

fake-ip 会给应用返回用于内部映射的地址，再由内核根据映射关联真实域名。看到 198.18.0.0/16 范围内的地址，在相应配置下可能是正常现象，并不代表目标网站真的部署在那里。如果应用持有旧映射而内核已经重启，连接可能失败。先关闭受影响应用并重新打开，再按客户端提供的方式清理 DNS 映射；不要把整个地址范围加入直连规则来绕开映射。

代理服务器域名需要能够在代理尚未建立时完成解析，否则会产生启动依赖循环。mihomo 的 proxy-server-nameserver 可用于指定此类域名的解析器；default-nameserver 则用于解析 DNS 上游自身的域名。下面片段仅演示依赖关系，使用前确认解析器在当前网络可达。不要另开一个 DNS 监听端口与已有客户端配置争用，也不要直接替换整份订阅。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

处理局域网域名与双栈差异

公司内网、家庭存储和路由器名称通常依赖内部 DNS。将所有查询统一发送到公网解析器，可能导致这些名称失效。先查看局域网设备原本使用的解析器，再通过 nameserver-policy 为明确的内部域名后缀指定解析路径。涉及 fake-ip 兼容问题时，可针对必要域名设置过滤，但过滤不会自动赋予公网解析器查询内网记录的能力，仍需配置能回答该名称的上游。

IPv4 正常而 IPv6 路径不完整，也可能造成应用先尝试 IPv6、等待后才回退。分别检查 A 与 AAAA 记录，并观察日志实际连接的地址族。可临时关闭客户端的 IPv6 解析选项做对照，但不要直接认定系统必须永久禁用 IPv6；有些网络依赖它提供完整连接。确认原因后应修复路由或出站支持，再恢复需要的双栈设置。

修复完成后同时测试公开网站、节点域名和一个常用内网服务。只恢复公开网页却丢失打印机或内部系统，不算完整解决。规则与 DNS 的关系可结合规则分流实战查阅；遇到术语差异时使用概念速查，先确定字段负责哪一段路径，再决定是否修改。

系统代理不生效：分开检查应用入口

“系统代理”主要是向操作系统登记代理地址，只有主动读取该设置的应用才会使用它。TUN 则通过虚拟网络接口接管符合路由条件的流量，两者作用层不同。浏览器正常而终端直连，并不必然是客户端异常；游戏或独立下载器也可能使用自己的连接设置。先查看显式代理请求是否成功，再决定是修复应用入口还是启用 TUN，不要把所有情况都归为节点故障。

浏览器、终端与服务分别验证

在浏览器中检查代理扩展是否覆盖了系统设置，关闭重复的代理管理功能后重新启动浏览器。Firefox 等程序可能使用独立代理配置，需要确认其设置为使用系统代理或填写正确的本机端口。再打开客户端“连接”，访问目标网站，观察是否出现该请求。界面没有记录并非绝对证据，但结合显式代理成功的结果，通常可以将排查重点放到应用侧。

终端工具是否读取环境变量，取决于具体程序。下面设置仅作用于当前终端及之后启动的子进程；已经运行的程序不会自动获得新环境。把端口改成客户端实际值后，用同一目标测试。NO_PROXY 用于指定绕过代理的目标，不宜写入过宽的域名范围。完成测试后删除临时变量，避免客户端退出后，终端仍然尝试连接一个不存在的本机端口。

# PowerShell：当前会话
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com/

# 清除当前会话的临时设置
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux：仅对这一条命令生效
https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

HTTPS 目标使用的代理入口仍可能写成 http://，这是指与本机代理建立连接的方式，不是把目标网站降级成明文。SOCKS 端口与 HTTP 端口不能随意混用；使用 socks5h 的工具通常会将目标域名交给代理解析，适合进一步区分本地 DNS 问题。后台服务、容器与远程会话还拥有独立环境，宿主机浏览器可用不代表它们会继承同一设置。

TUN 启动后检查权限与路由

需要接管不读取系统代理的应用时，再按客户端说明安装或启用服务组件，然后打开 TUN。若开关立即回落，查看日志中的权限、设备创建和路由错误。Windows 的服务模式、macOS 的系统授权、Linux 的网络管理权限是不同机制，不应把某个平台的操作直接照搬到另一平台。Clash Plus 可作为优先选择；其他客户端的具体界面与系统要求见下载页。

TUN 显示开启但流量仍不经过时，检查是否存在另一套 VPN、虚拟机网络、手动静态路由或应用排除规则。下面是 mihomo 常见字段示意，应通过客户端支持的覆写入口合并，避免与界面自动生成的 TUN 配置重复。auto-route 负责自动设置路由，auto-detect-interface 帮助选择出站接口；它们不能替代所需系统权限，也无法保证所有复杂网络均自动正确识别。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

保留内网通路并清理残留设置

开启 TUN 后内网失效，应先查看内网网段是否被错误接管，以及内部域名是否仍交给正确的 DNS。路由排除与规则直连不是完全相同的操作：前者决定流量是否进入隧道，后者决定进入内核后如何出站。先确认业务要求，再配置精确网段，避免用过宽的排除范围绕过全部流量。办公 VPN 有专用路由时，应优先遵守组织的网络策略。

排查结束后先关闭 TUN，再关闭系统代理并正常退出，确认直连仍可恢复。异常退出留下代理设置时，在系统网络面板删除残留地址，不需要立即卸载客户端。浏览器与终端的完整检查顺序另见系统代理不生效专项文章；需要部署到路由器的场景，应转看OpenWrt 旁路由部署要点，不要套用桌面系统代理结论。

客户端崩溃：分离界面与内核

窗口关闭、托盘消失、内核停止和配置载入失败，是四种不同状态。先确认客户端是否仍在后台运行，系统代理是否还指向它，以及日志是否继续产生。界面打不开但代理仍可用，可能只涉及界面进程；窗口正常而全部请求失败，则可能是内核没有启动。反复双击程序会增加重复进程和端口竞争，先在任务管理器或系统活动监视器中确认现有实例，再决定重启。

先保存证据与可恢复数据

记录故障发生前最后一次操作：更新订阅、添加覆写、启用 TUN、导入规则或升级客户端。通过“设置”中的日志或配置目录入口保存相关文件；目录位置随客户端与安装方式变化，不应照搬其他软件的固定路径。若界面无法打开，使用系统应用日志或崩溃报告辅助定位。对外分享前删除订阅链接、密码、控制接口凭据和可能暴露访问记录的内容。

备份订阅来源、用户覆写、规则文件和策略选择记录。不要只复制正在生成的运行时配置，因为其中可能混合缓存与临时字段，也不一定是下次启动时真正读取的源文件。移动数据目录前应先退出程序，避免正在写入的数据库或文件被截断。可恢复备份应放在本机受控目录，不能因求助而把整个配置目录公开上传。

检查启动失败的具体原因

日志出现地址已被占用时，查看代理端口或控制接口端口由哪个进程监听。下面命令用于观察 7890 的占用情况，端口需按实际设置调整。发现监听者后先辨认程序名称，不要直接终止系统进程。常见情况是旧客户端仍在后台、同时启动了另一个内核，或重启过程中出现短暂重叠。保留一个明确使用的实例通常比随意改动多个端口更容易维护。

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

# macOS：查看本机 TCP 监听
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看监听端口
ss -lntp

如果内核启动后立即退出，检查配置解析错误、规则文件读取权限、磁盘空间和外部资源加载失败。先停用最近新增的覆写或规则提供者，重新载入上一份可用配置。若只有某个配置触发故障，优先修复配置，而不是重装界面。出现文件无法写入时，确认安装目录与数据目录是否有权限，不要把所有文件权限改成全员可写来绕开问题。

窗口空白或显示组件报错时，按客户端文档检查系统运行组件与操作系统支持范围。安全软件隔离记录也应查看，确认被拦截的是哪个文件、原因是什么。不要把关闭全部防护作为长期解决方案；可在可信来源重新下载安装，并依据系统提示处理授权。安装包架构应与设备匹配，旧系统不一定满足新界面组件要求，兼容性信息以下载页及项目说明为准。

使用隔离测试而非直接清空

怀疑缓存或本地状态损坏时，退出客户端后先将数据目录改名保存，让程序按文档支持的方式创建新目录。新环境能启动，再逐项导入订阅和用户覆写，找出触发项。不要立即删除旧目录，也不要一次性把全部缓存复制回去。若使用便携模式与安装模式，确认二者是否共享数据位置，避免测试时仍然读到同一份有问题的状态。

确需更换客户端时，优先从下载页选择当前平台支持的 Clash Plus，或按需求选择 Clash Verge Rev、FlClash 等客户端。Clash for Windows 与 ClashX Meta 已停止维护，不宜作为新系统问题的通用修复方案。恢复后先测试普通代理，再启用 TUN 与自动更新，最后恢复开机自启。这样可以区分程序启动、网络接管与后台权限三条链路，减少故障再次出现时的排查成本。

移动端专项：VPN、后台与网络切换

移动端代理通常依赖系统 VPN 能力，连接状态还会受到电量策略、后台限制、Wi-Fi 与蜂窝切换影响。先区分“系统 VPN 已断开”和“VPN 仍连接但业务失败”。前者优先查权限与进程存活，后者优先查出站、DNS 与网络变化。Android 和 iOS 的权限模型不同，不应照搬桌面的系统代理开关说明，也不要仅凭状态栏图标判断所有请求都已成功转发。

Android：先核对 VPN 授权与分应用设置

首次连接时确认系统的 VPN 授权提示，随后进入系统 VPN 设置，检查当前接管连接的是哪个应用。广告过滤、防火墙和其他 VPN 工具可能竞争同一能力，排查时先退出其他工具。若系统开启“始终开启的 VPN”或“阻止不使用 VPN 的连接”，客户端停止后可能导致全部联网被阻断；先理解这些设置的作用，再决定临时关闭，不要将其误判为无线网络损坏。

只有某些应用不经过代理时，检查客户端的分应用代理列表。不同界面可能采用“仅代理所选应用”或“绕过所选应用”两种相反逻辑，选中同一个应用产生的结果并不相同。修改后通常需要重建 VPN 连接，并完全退出目标应用再打开。工作资料、双开应用和系统组件可能拥有独立身份，应按实际应用实例检查，而不是只核对桌面上的名称。

熄屏后连接失效时，进入系统“电池”和“应用管理”，允许客户端按需要在后台运行，并检查后台数据限制。部分设备还提供自启动管理，应根据实际使用需求授权。调整后锁屏一段时间，再唤醒测试同一目标，确认日志是否显示进程重启。单纯把应用从最近任务中锁定，不一定等于解除电量限制；也不应为修复一个应用而关闭整机所有节电功能。

iOS：检查配置、授权与重连

iOS 可优先使用 Clash Plus，安装入口见iOS 下载区，官网为 clashplus.io。打开客户端确认订阅已启用，再按系统提示添加 VPN 配置并授权。若连接立即断开，查看客户端错误记录及系统 VPN 列表，确认没有旧配置或其他应用反复发起连接。不要直接删除所有网络配置；先停用冲突项，再逐个验证。

某些应用可能保留切换前的长连接。更换出站或网络后，先断开再连接 VPN，然后完全关闭并重新打开受影响的应用。系统显示 VPN 已连接，只代表隧道已经建立，不代表订阅内每个出站都可达。若一个网站失败而其他网站正常，回到规则与 DNS 检查；若所有请求失败，则用同一网络中的另一台设备对照，确认是否为当前网络限制。

网络切换与热点共享单独测试

Wi-Fi 正常、蜂窝失败时，先查看系统是否允许客户端使用蜂窝数据，账户是否有可用流量，以及应用是否被低数据模式限制。再选择相同出站测试，排除不同网络下 UDP 或 IPv6 行为差异。Wi-Fi 与蜂窝切换会改变本地地址和路由，旧连接失效并不罕见；如果重连即可恢复，应继续观察是否为客户端后台状态问题，而不是马上重置全部网络设置。

手机自身联网成功，不代表热点下的其他设备也会经过手机 VPN。共享流量是否被接管取决于系统与客户端实现，需要单独验证。开启“允许局域网连接”只是允许其他设备访问代理监听，并不自动改写它们的代理设置；如果确需使用，应只在可信网络开放，并避免把监听端口暴露到公共网络。接入设备还需填写手机局域网地址与正确端口。

完成移动端排查后，分别验证前台访问、锁屏恢复和网络切换三种状态。保留必要的后台权限，关闭临时开放的局域网监听，并恢复日常使用的模式。仍有问题时，整理设备系统、客户端名称、故障网络类型、错误时间及已完成的对照步骤；这些信息足以帮助定位，不必附上原始订阅。重新配置可回到上手教程，概念不清时查阅术语说明。