无法上网：先区分直连、代理与规则
“打开 Clash 后无法上网”不是单一故障。浏览器可能仍指向已经退出的本地代理，内核也可能正常监听但没有可用出口。先记下哪些应用失败、是否所有网站失败，以及客户端关闭后是否恢复。仅一个网站出错与整个系统断网应走不同分支；不要一开始就重装软件、清空全部配置或修改系统 DNS，这些操作会同时改变多个条件，丢掉原来的判断依据。
先恢复直连，再确认本机代理入口
在客户端内关闭系统代理与 TUN 模式，然后正常退出客户端。到操作系统网络设置确认手动代理没有残留，再访问平时可直连的网站。如果仍然失败，检查无线网络是否完成网页登录、网关是否可达、其他设备是否也断网。此时问题尚未定位到 Clash，应先恢复基础连接。若涉及单位网络或受管理设备，保留原来的自动配置脚本和代理设置，不要直接删除组织下发的策略。
直连恢复后，只启动一个客户端，暂不启用 TUN。查看运行日志是否完成配置加载，并确认设置页中的混合端口。下面以实际监听端口为 7890 的情况测试本地 HTTP 代理；端口不同就替换数字。这个请求只用来判断代理链路是否能取得响应，不代表所有应用都已接入代理。即使返回的是重定向，也说明请求已经得到 HTTP 层回应。
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.comWindows PowerShell 中可使用 curl.exe 执行同样的参数，避免命中其他同名命令。若提示无法连接到本机端口，先检查内核是否启动、端口是否更改，以及安全软件是否阻止本地监听。若能连接本机却在后续握手超时，说明故障已越过应用接入阶段，转到节点超时检查出口；不要继续在浏览器里反复切换代理扩展。
用模式切换确认规则是否参与故障
系统代理打开后，先保持规则模式测试同一网址，再临时切换全局模式，并确认全局策略组选中了一个实际节点。全局可用而规则失败，通常需要检查规则命中、策略组指向或规则数据库加载情况。全局与规则都失败，则优先检查节点、DNS 和本地连接。全局模式仍依赖应用确实进入客户端，不会自动接管忽略系统代理的程序，不能仅凭模式名称判断流量路径。
打开连接列表，找到刚才访问的域名，查看匹配规则、出口策略和错误日志。若出口是 DIRECT，而该目标的直连路径本就不可用，应该修正规则，而不是给所有域名永久启用全局。规则通常按顺序匹配，前面较宽泛的规则可能覆盖后面的精确规则。修改前确认策略名存在于当前配置中，规则引用的名称必须与节点或策略组名称一致。
按故障范围收束修改
只有某个浏览器失败时，换一个没有代理扩展的浏览器进行对照，检查扩展、独立 DNS 与缓存。只有某个网站失败时，查看是否属于网站自身维护、证书错误或账号限制。遇到证书警告应先核对系统时间，不应关闭证书验证来“恢复访问”。相关处理见HTTPS 证书报错原因与处理办法。不要把网站返回的拒绝访问页面误判成本地完全断网。
节点超时：拆开解析、建连与握手
节点测试超时只说明某个测试请求没有在规定时间内完成，不能直接等同于节点失效。测试地址、DNS、服务端端口、协议握手和目标网站都可能造成同样的界面结果。先选一个节点进行实际访问，再对照故障发生时的日志。不要同时对整份订阅反复测速：大量并发测试可能触发限流，也会让日志混入与当前浏览无关的错误，难以定位单条请求。
读取错误发生在哪一段
在日志设置中临时使用 info 级别，清楚记录一次失败的时间和目标。若出现解析节点域名失败，先查 DNS；若是连接服务端地址超时，检查当前网络到服务端的可达性；若已连接却出现 TLS 或认证错误，则核对协议参数、时间与订阅状态。必要时短暂切到 debug，但不要长期保留详细日志，也不要把包含完整地址与认证内容的日志直接公开。
| 日志线索 | 优先检查 | 不能直接推断 |
|---|---|---|
dial timeout | 服务端地址、端口、当前网络路径 | 不一定是客户端安装损坏 |
connection refused | 服务是否监听、端口是否正确、是否被主动拒绝 | 不等于 DNS 必然异常 |
no such host | 域名拼写、解析器与引导解析 | 不证明服务端已经关闭 |
TLS handshake 相关错误 | 系统时间、服务器名、协议参数与服务端配置 | 不应直接关闭证书验证 |
错误文字要结合前后文阅读。同一个 timeout 可能来自节点连接，也可能来自访问目标的等待。查找日志中的远端地址，区分它是节点服务器还是目标网站。具体字段随内核和客户端变化，不能只搜索一个英文单词就下结论。可对照Clash 运行日志怎么看，按“时间、目标、策略、错误”四项整理一次请求。
用单变量对照缩小范围
保持客户端和配置不变，将设备从当前无线网络换到手机热点，再测试同一个节点与同一网址。热点可用而原网络失败，说明原网络的出口、防火墙或 DNS 更值得检查。两个网络都失败时，换另一个节点进行对照；只有个别节点失败，优先向服务提供方确认节点维护、账号有效期或连接限制。不要因为一个节点异常就替换整套系统网络设置。
在 Windows 中可以用 Test-NetConnection 检查已知服务端的 TCP 端口，在 macOS 或 Linux 中可用 nc 检查。执行时使用自己配置中的服务地址和端口，不要把节点凭据贴到公共终端。TCP 可达只证明端口能够建立连接，不能证明应用协议、认证与转发都正常；基于 UDP 的传输也不能由一次 TCP 测试得出可用结论。ICMP ping 被禁用时，节点仍可能正常提供代理。
检查协议兼容与自动选择
导入配置成功不代表每个协议字段都被当前内核支持。配置来自其他客户端、经过订阅转换或包含较新协议时，应检查日志是否提示未知类型、缺少字段或握手不兼容。先更新到所用项目仍在维护的发行包，或向服务提供方取得明确适配当前内核的配置。需要重新选择客户端时可先看安装包下载页中的 Clash Plus，再核对所需协议支持，而不是混用来源不明的内核文件。
自动选择策略可能仍保留上次的测试结果，也可能使用与实际业务不同的探测网址。暂时手动选择一个已验证节点，关闭本次排查不需要的自动切换，再观察真实连接。若节点建立连接后仅在大流量时中断，还需检查丢包、路径 MTU 和服务端限额，不宜继续缩短测速间隔。处理完成后恢复原测试策略，并确认新建连接确实使用了当前选择。
订阅失败：分别检查下载、解析与启用
订阅更新包含三个独立动作：从远端取回内容、将内容解析成配置、让内核加载选定配置。下载完成但配置没有启用，和根本取不到订阅不是同一种问题。先查看配置页的最后更新结果与运行日志，判断失败发生在哪一步。不要连续删除订阅再重新添加，这可能一并删除本地覆写、规则选择与历史设置，也会使原本可用的缓存配置无法恢复。
取不到内容时检查链接与访问路径
从服务提供方的账户页面重新复制完整订阅地址，检查开头、结尾以及复制时是否带入换行。二维码识别出的内容也应确认是订阅 URL，而不是网页地址。订阅通常携带访问凭据，不要上传到在线检测站或公共转换页面。若需要向支持方反馈，只提供错误码、发生时间和经过遮挡的域名信息，地址中的路径与查询参数也可能包含敏感内容。
遇到 HTTP 状态码时按响应含义处理。认证相关错误应先检查账户与链接是否仍有效；访问频率限制需要等待后再更新；服务器错误则先保留当前配置。浏览器能打开服务网站，不代表订阅接口也能访问，因为两者可能使用不同域名和鉴权方式。浏览器显示一段内容也不等于配置正确，登录页面或验证页面同样可能返回成功状态。
如果订阅域名必须经过代理才能访问，先用已有可用配置连接，再进行更新；如果客户端把更新请求固定为直连，则检查其订阅下载设置。反过来，当前代理已经失效时，强制通过该代理下载也会陷入循环。优先使用客户端提供的直连或代理选项做一次对照，不要同时开启多个客户端来“接力”，避免本地端口与系统代理互相覆盖。
内容拿到了，却提示格式错误
解析失败时先区分完整 YAML 配置、节点集合与客户端专用分享格式。它们不能总是互换导入入口。完整配置应进入配置管理，节点提供器则需要由主配置引用；把一个节点列表当成包含策略组和规则的主配置，可能出现缺少字段或找不到策略的错误。查看提供方的导入说明，选择明确适配当前客户端的链接，不要仅凭文件后缀判断内容类型。
YAML 对缩进和数据类型敏感。手动编辑时使用空格而非制表符，注意列表项与上级字段的层级，避免复制聊天软件中的全角冒号和弯引号。报错行通常只是解析器发现问题的位置，实际缺失符号可能在上一行。不要为修复一处缩进而整体替换全部引号；某些密码、正则或包含特殊字符的名称本来就需要保留引用形式。
更新成功后确认内核实际使用的配置
回到配置列表，明确选中刚更新的条目，再查看日志是否完成重载。某些客户端更新文件后不会自动切换当前配置，界面中的节点列表也可能来自另一份配置。核对策略组名称和新建连接的出口，不要用已经打开很久的网页作为唯一验证，因为原有长连接可能继续沿用旧策略。可以关闭测试标签页，再重新发起一次请求。
若更新后节点齐全但规则丢失，检查本地覆写是否覆盖了整个 rules 或 proxy-groups 列表。数组替换与追加的行为取决于客户端的合并机制，不能假设各客户端一致。先停用单个覆写进行对照，确认问题来自订阅还是合并结果。修复后把必须长期保留的本机设置放入受支持的覆写位置，避免下次订阅更新再次覆盖。
需要进一步确认导入入口与配置选择，可查看安装与配置教程；格式差异与日常更新问题见帮助中心的安装配置问答。订阅下载恢复后再设定合理的自动更新周期，不要把频繁刷新当作节点超时或账户异常的通用解决方法。
速度慢：区分响应延迟与持续传输
网页打开慢、视频缓冲和大文件下载慢，可能对应完全不同的瓶颈。测速面板里的节点延迟主要反映测试请求的响应情况，不能代表可用带宽，也不能保证某个网站的 CDN 路径良好。先明确慢的是首次打开、整个传输过程还是仅某种应用，再在相同网络、相同目标和相同时间段进行对照。不要拿不同站点、不同文件的结果直接比较节点性能。
先把本地网络与后台负载排除
暂停系统更新、云盘同步和其他下载任务，确认无线信号稳定，再用同一个目标重复测试。笔记本可临时改用有线网络，手机可在无线网络和蜂窝网络之间对照。若直连服务也同时变慢，先检查本地链路与运营商出口；若只有代理路径变慢，再比较不同节点。测试过程应尽量串行，多个测速网站同时运行会争用带宽，结果也更容易受连接数影响。
观察客户端所在设备的 CPU 与内存占用。低功耗路由器、较旧手机和虚拟机可能受协议加解密或虚拟网络开销限制，表现为传输上升时单个核心持续繁忙。不能仅看整机平均 CPU 很低就排除算力瓶颈。若在普通电脑上同一节点正常，而路由设备速度明显受限，应检查设备资源与配置复杂度，而不是反复更换 DNS 服务器。
用连接记录确认真实出口
打开连接列表，查看慢请求实际命中了哪个策略。自动选择、负载均衡和故障转移组可能让不同请求走不同出口；浏览器也可能复用切换前已经建立的连接。测试时暂选一个固定节点，结束原下载后重新发起请求，再记录结果。全局模式只能作为规则对照工具，不应当长期用来掩盖规则误匹配，尤其不要忽略本应直连的大体积本地服务。
若首页加载快而图片或视频慢，检查页面子资源对应的域名及其规则。一个页面常由多个来源组成，主域名代理正常并不代表媒体域名也走同一策略。若有的请求直连、有的请求代理，可能出现重复连接、区域不一致或服务端重新选择内容。应围绕实际失败的资源调整规则，而不是把整个顶级域名范围都改成同一出口。
| 观察现象 | 主要检查方向 | 对照方法 |
|---|---|---|
| 首次打开慢，后续正常 | DNS、握手与缓存 | 比较同域名首次与后续请求 |
| 开始正常，随后持续下降 | 拥塞、限流、设备负载 | 串行测试并观察资源占用 |
| 仅一个站点慢 | 目标服务、CDN 与出口路径 | 保持节点不变，换目标对照 |
| 大请求停滞，小请求正常 | 丢包、路径 MTU、传输兼容 | 比较系统代理与 TUN 路径 |
谨慎调整传输与 TUN 参数
某些视频或浏览器使用 QUIC，它通常基于 UDP。节点或当前网络对 UDP 支持不完整时，可能出现反复等待或回退。可以在有明确依据时临时禁用应用内的 QUIC 做对照，但应记录原值，测试后恢复。TCP 下载正常不能证明 UDP 正常；反过来，一项 UDP 业务失败也不意味着整个节点不可用。协议选型需要结合具体业务，不宜只按测速列表排序。
当问题只在 TUN 下出现时，先比较关闭 TUN、使用显式本地代理的结果。路径 MTU 不匹配可能造成大包重传，但修改 MTU 不是所有“慢”的通用办法。只有在抓包、网络环境说明或重复对照支持这一方向时，才逐项调整并保留原值。不要同时更换协议、DNS、MTU 和出口节点，否则即使恢复也难以确认原因，后续更新可能再次出现同类故障。
最后考虑服务端容量、账户流量限制与目标站点本身的下载策略。如果多个设备在同一节点、同一时间都慢，而更换节点后恢复，应把测试时间、目标类型与现象交给服务提供方。反馈中区分“连接建立慢”和“持续速率低”，比仅描述“延迟高”更容易定位。日常使用不需要持续运行测速，真实业务稳定比单次测试结果更有参考价值。
DNS 问题：确认解析来源与实际路径
DNS 故障常表现为部分域名打不开、节点域名解析失败、首次连接等待很久，或切换网络后仍返回旧地址。先区分系统解析、浏览器独立解析与内核解析：它们可以同时存在，使用的服务器也不一定相同。系统命令查询成功只能说明该命令所走的路径正常，不能直接证明 Clash 内核取得了正确结果；浏览器成功也可能只是命中了自身缓存。
比较系统结果与客户端连接记录
先在关闭代理接管的状态下查询目标域名，记录使用的解析器和返回地址，再启用客户端检查对应连接日志。下面的命令用于观察系统侧结果，不会自动查询内核的 DNS 服务。如果需要直接查询内核监听的 DNS 端口，先确认配置中的监听地址与端口，并选择支持指定端口的查询工具。不要把控制接口端口当成 DNS 端口。
nslookup example.com在启用 fake-ip 的配置中，客户端可能返回一个用于映射的保留地址，再由内核将连接还原到域名。看到这种结果不能立即认定 DNS 被污染。关键是后续连接是否被同一个内核接管，且域名映射是否仍有效。若应用拿到了映射地址，却绕过 TUN 或本地代理直接连接，就可能失败。关闭接管后仍使用旧映射缓存，也会出现暂时无法访问。
理解引导解析与上游访问
加密 DNS 的服务器名同样需要先解析。若用于解析节点域名的请求又依赖尚未建立的代理，就可能形成循环。排查时先检查 DNS 上游是否可达、节点域名由谁解析，再检查按规则路由的设置。不要把网上的一整段 DNS 配置直接覆盖进订阅，尤其要核对 proxy-server-nameserver 等字段是否被当前内核支持，以及原配置是否已有相同功能。
下面是使用 mihomo 的客户端可参考的局部字段示例，目的是区分普通域名和代理服务器域名的解析来源，不是完整配置。示例没有启用 TUN，也没有声明 DNS 监听入口，因此不会自行接管系统查询。合并时应编辑原有 dns 节点，不能在文档末尾再复制一个同名顶层键；存在重复键时，不同解析器的处理结果可能不同。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
default-nameserver:
- 1.1.1.1
nameserver:
- https://dns.google/dns-query
proxy-server-nameserver:
- 1.1.1.1示例中的上游需要在当前网络可达，不能把某个公共解析器视为所有网络的固定答案。单位内网、校园网和家庭局域网还可能依赖专用 DNS 解析内部名称。替换全部上游后，公共网站可能恢复，但打印机、内部系统或本地域名反而失效。此时应按域名保留内网解析路径，而不是持续增加公共服务器数量；多个上游也不一定按填写顺序简单备用。
排除缓存、IPv6 与泄漏误判
修改解析路径后，先重新打开目标应用；必要时清理系统 DNS 缓存，再测试新连接。Windows 可使用 ipconfig /flushdns；采用 systemd-resolved 的 Linux 可使用 resolvectl flush-caches，其他系统应按自身服务处理。清缓存只是清除旧结果，不会修复不可达的上游。若刚修改完就恢复，也应再次检查实际路径，避免把短暂缓存变化当成最终解决。
DNS 泄漏需要结合预期策略判断。测试页面显示了某个解析器，只能说明测试请求观察到了该解析路径，不能证明所有业务域名都绕过代理。检查浏览器安全 DNS、系统私有 DNS、TUN 的 DNS 劫持范围及分流策略是否一致。IPv6 也应单独检查：只接管 IPv4 时，应用可能通过 IPv6 走另一条路径。不要把关闭 IPv6 当作固定配置，应先确认客户端与网络的支持情况。
系统代理不生效：检查应用是否进入内核
系统代理是操作系统提供给应用读取的一组代理设置，不是覆盖全部流量的网络隧道。浏览器、命令行工具、游戏和系统服务对这组设置的支持不同，因此“开关已打开”只能说明客户端尝试写入设置，不能证明每个程序都采用了它。先打开客户端连接页，再从目标应用发起一个新请求；是否出现对应记录，是判断接入路径的重要起点。
先检查系统设置是否被正确写入
查看系统网络代理页，核对地址是否为本机、端口是否与客户端混合端口一致。若客户端在其他设备上运行，才需要使用那台设备的局域网地址，并另行处理监听和防火墙。不要把 127.0.0.1 当成远程电脑地址，它始终指当前设备自身。也不要为了本机浏览器接入而开启允许局域网连接，这会扩大监听范围，却不能修复错误的本机端口。
Windows 中，用户代理设置与部分服务使用的 WinHTTP 代理并不是同一套配置；macOS 的代理设置通常绑定网络服务，切换到新的无线或有线连接后需要重新确认。Linux 桌面环境的全局代理也不保证终端程序读取。出现开关自动恢复、端口被改回或代理地址反复变化时，检查是否有另一个代理客户端、浏览器扩展或组织策略在同时管理设置。
如果日志提示本地端口被占用，先查明占用程序，再决定退出该程序还是修改端口。Windows 可用 netstat -ano 查看监听与 PID，macOS 可用 lsof -nP -iTCP:7890 -sTCP:LISTEN 定位指定端口。不要仅根据进程号强制结束陌生系统服务。修改混合端口后还要同步系统代理、浏览器手动设置和终端变量，详细步骤见端口占用排查文章。
终端先用单次显式代理测试
终端工具不跟随系统代理时，先给单次命令明确指定代理，不急着改全局环境变量。下面两条命令分别使用 HTTP 代理和 SOCKS 代理。socks5h 中的字母表示让代理侧处理目标域名解析；它与本地先解析再连接的行为不同，可用于对照 DNS 路径。执行前确认客户端实际开放了对应协议，混合端口通常同时接受两类请求。
curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com显式指定后成功，默认执行却直连，说明应检查工具自身的代理来源。查看 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY，同时考虑大小写变量及工具配置文件。变量的支持顺序随程序而异，NO_PROXY 还可能让指定域名绕过代理。浏览器可用、Git 不可用，也可能来自 Git 自己保存的代理配置，不能仅修改系统开关。
需要 TUN 时再处理权限与路由
对于不读取系统代理的应用，可按客户端文档使用 TUN，但要先证明基本代理链路正常。启用后确认服务权限、虚拟网卡和路由确实建立，而不是只看界面开关。其他 VPN、虚拟机网络与容器网络可能产生路由冲突；应一次停用一个相关功能做对照，记录恢复步骤，不要直接删除未知网卡。若必须保留企业 VPN，优先按其网络管理要求处理。
浏览器独有问题还要检查扩展是否接管代理、是否使用独立的安全 DNS，以及是否保留旧连接。用未加载扩展的新配置文件测试，比仅打开隐私窗口更可靠，因为部分扩展可以获准在隐私窗口运行。浏览器与终端的完整对照流程见系统代理不生效排查文章，基础开关位置见教程的系统代理章节。
结束排查时正常退出客户端，检查系统代理是否按预期恢复。强制结束进程或断电后，系统可能仍指向已经停止监听的本地端口；这类残留会造成关闭客户端后反而无法访问。重新打开客户端再正常关闭系统代理，或在系统设置中恢复原值。开机自启只决定程序何时启动，不等于配置已加载、内核已运行和系统代理已写入，应分别确认这几个阶段。
客户端崩溃：区分界面、内核与系统环境
窗口消失、托盘仍在、连接全部中断和应用完全无法启动，分别可能来自界面进程、内核进程或系统运行环境。先在任务管理器或活动监视器中确认相关进程是否存在，再查看客户端日志目录中的最后记录。不要连续双击启动多个实例，也不要立即清除整个应用数据目录。原配置、错误日志与启动状态往往是定位问题最有价值的材料。
记录触发条件并保留恢复入口
回想崩溃是否紧接着订阅更新、启用 TUN、切换主题、系统升级或恢复休眠发生。固定触发动作比“偶尔崩溃”更容易查明。备份配置与必要的应用设置后，尝试不启用代理接管启动客户端；若窗口能稳定显示，再逐项恢复功能。客户端崩溃后还要检查系统代理残留，避免在收集日志时把浏览器无法访问误当成第二个独立故障。
确认安装包与系统、处理器架构相符。macOS 的 Apple Silicon 与 Intel 包需要正确区分；Linux 还要考虑发行版、包格式与图形环境。安装失败或启动闪退时读取系统提示，不要从不明站点单独下载运行库、驱动或替换动态库。需要更换安装包时，从下载页先查看 Clash Plus，再按实际平台与使用需求比较其他仍在维护的客户端。
配置加载失败与程序崩溃分别处理
界面正常但内核不断退出时，检查配置语法、引用文件与规则提供器路径。订阅里引用的文件下载失败，可能让配置不能完整加载；手动移动配置目录也可能使相对路径失效。先暂停自动更新，切回备份中已知可用的配置，再观察是否稳定。不要删掉所有规则来试图“减轻负担”，应以日志报出的具体文件或字段为起点，逐项恢复。
若客户端提供配置检查功能，先运行检查，再重载内核。命令行内核用户可以在备份后使用下面的语法测试命令；它只检查指定配置，不会替代正常启动。配置含相对路径、提供器或外部数据库时，还要按自己的部署方式指定正确工作目录。图形客户端可能通过额外合并生成最终配置，因此直接检查原订阅与检查运行配置的结果不一定相同。
mihomo -t -f config.yaml控制接口地址、混合端口或 DNS 监听端口冲突，可能表现为内核启动后立即退出。阅读完整错误，而不是仅看最后的退出提示。多个实例、开机任务和服务模式同时启动时尤其容易竞争端口。先保留一种启动方式，确认没有旧进程继续占用，再重新启动。不要把外部控制端口暴露到公共网络来解决本机连接问题，这与启动故障没有直接关系。
检查权限、资源与界面依赖
若仅在打开 TUN 后退出，检查客户端服务是否正确安装、系统是否允许相关权限，以及安全软件的拦截记录。只为明确的程序和操作添加必要授权，不应关闭全部防护。Linux 下还应区分普通用户与管理员运行产生的配置目录和文件所有权；曾经用管理员身份启动 GUI 后，普通用户可能无法写入同一目录，造成保存设置或启动时失败。
长时间运行后崩溃时，观察内存是否持续增长、磁盘是否已满、日志是否大量累积。可以暂时关闭连接详情等高频刷新页面，降低日志级别，判断是界面刷新还是内核连接负载触发问题。不要直接删除正在写入的数据库文件；先退出应用，备份后再按客户端说明清理可重建的缓存。清理前确认目录用途，订阅与用户配置不应当作缓存处理。
需要提交问题时，整理最小复现过程：系统类型与架构、客户端名称、触发动作、是否启用 TUN、经过脱敏的错误片段，以及更换配置后的对照结果。Clash for Windows 与 ClashX Meta 已停止维护，遇到系统兼容问题时应考虑迁移，而不是无限反复安装归档包。迁移前保存原始配置，按新客户端的格式重新导入，不要把整套私有数据目录直接覆盖过去。
移动端专项：VPN 权限、后台与网络切换
移动端受系统 VPN、后台调度与网络切换影响，与桌面系统代理的排查入口不同。先确认应用是否真的建立了 VPN 会话，再查看目标应用是否在接管范围内。状态栏出现 VPN 标识通常说明系统隧道存在，但不证明节点认证、DNS 或目标连接已经成功。先保留一个可用节点，用浏览器和另一款应用分别测试，避免只用单个应用的结果判断整机网络。
Android 检查 VPN 占用与后台限制
Android 启动连接时需要确认系统 VPN 授权。若点了连接后立即停止，检查是否有其他 VPN、防火墙、广告过滤或抓包应用正在占用系统 VPN 槽位。即使这些应用没有远端服务器，也可能使用本地 VPN 技术处理流量。先正常停止另一个应用再测试，不要同时反复开启。受工作资料或设备管理策略影响时，还需要遵循设备管理要求，个人侧设置不一定能覆盖工作侧网络。
连接后锁屏断网、返回应用才恢复，优先检查省电策略、后台运行权限和应用是否被系统回收。按设备系统允许客户端保持必要后台活动，并确认连接通知状态。不同厂商的菜单名称有差异，不能只看“允许通知”就认为后台权限已经齐全。测试时先短时保持屏幕开启，再锁屏复测同一业务；只有锁屏后失败，才更支持后台限制这一方向。
启用始终开启 VPN 或阻止未经过 VPN 的连接后，客户端停止时可能出现预期中的断网。先到系统 VPN 设置确认是否启用了这些选项，分清安全策略与程序故障。排查期间如需关闭，应理解关闭后可能恢复直连，并在测试后还原。分应用代理也要检查允许名单和排除名单：目标应用被排除时，它不会因为其他应用已接入就自动经过代理。
iOS 检查会话状态与应用规则
iOS 可从下载页查看首推的 Clash Plus，官网为 clashplus.io，安装入口见App Store 的 Clash Plus 页面。连接时先完成系统要求的 VPN 配置授权，再回到应用确认当前配置与策略。若连接开关自行关闭，先检查其他 VPN 或设备描述文件是否正在控制网络，不要把重复安装应用作为第一步。
仅 Safari 或某个应用行为不同，应检查该应用的网络设置、缓存与可能参与访问路径的隐私功能。系统私密中继、独立 DNS 设置或其他网络扩展可能让观察到的出口与预期不同，但不能仅凭出口页面的地理标记认定代理失效。先通过客户端连接记录核对域名与策略，再决定是否临时暂停某项功能做对照；每次只改变一项，并保留原设置。
处理 Wi-Fi、蜂窝网络与休眠切换
从 Wi-Fi 切换到蜂窝网络后，旧连接可能因地址和路由变化中断。先停止当前下载或通话，重新发起连接；若仍失败，再在应用内断开并重新连接 VPN。若某个网络需要网页登录，先完成认证，再启动代理。不要把认证页面打不开直接归因于节点，尤其在酒店、机场与校园网络中，VPN 可能让登录请求无法进入本地认证入口。
检查客户端是否获准使用蜂窝数据，以及系统是否对当前网络启用了流量节省或后台限制。若 Wi-Fi 正常、蜂窝失败，使用相同配置与目标对照，并检查节点域名在两种网络下的解析与可达性。部分网络的 IPv6、UDP 或路径 MTU 行为不同，不能直接复制桌面端参数。先比较同一节点的其他传输方式，必要时向服务方提供具体网络类型和错误时间。
移动端重新导入订阅时，同样要确认新配置已经选中，避免 VPN 会话仍加载旧内容。若系统状态正常但某款应用无法连接，回到规则和分应用设置检查，不要继续扩大系统权限。日常模式选择见规则与全局模式教程，常见使用边界见帮助中心的使用技巧。将最终生效的权限、模式与网络条件记下来，后续系统升级或更换设备时便于复查。