FlClash 故障排查
连接、订阅与 DNS

无法上网：先确定故障所在层

“客户端显示已启动”只说明本地服务可能已经运行，不代表订阅、远端连接与系统接管都正常。先选一个平时可以直连的网站和一个需要代理访问的服务，用同一浏览器分别测试，并记下具体错误：域名无法解析、连接被拒绝、证书错误还是等待超时。不要只凭某个网页打不开就认定全部网络中断；服务自身维护、登录失效和地区限制也会表现为访问失败。

先关闭接管，验证基础网络

暂停 FlClash，关闭系统代理与 TUN，再检查系统代理设置是否确实恢复。若退出后浏览器仍指向本机端口，先清除残留代理，否则这次测试并不算直连。使用可信网络访问普通站点，必要时切换手机热点进行对照。直连也失败时，优先处理无线认证、路由器、网线或运营商连接；在酒店、校园等网络中，还应先完成网络登录页面的认证。

如果只有一台设备直连失败，检查系统时间、网络适配器和安全软件的提示；同一网络下所有设备都失败，则更像是上游问题。此时反复导入订阅通常没有帮助。基础网络恢复后再启动 FlClash，并保持原来的测试网站不变，避免把更换测试目标造成的差异误认为修复结果。浏览器已有长连接可能暂时沿用旧状态，验证时应重新发起请求。

再检查当前配置与出站选择

打开配置页面，确认导入成功的配置已被选为当前配置；列表里有文件，并不等于内核正在使用它。进入代理页面，检查规则引用的策略组是否有可用出站，手动选择时不要停在失效选项。先用规则模式测试，再短暂切到全局模式对照：全局可用而规则失败，通常应查规则命中与策略组；两种模式都失败，则继续检查远端连接和本地端口。

直连模式表示请求绕过代理出站，不是更强的连接方式。切换模式仅用于定位，测试结束后恢复日常使用的规则模式。日志中若出现策略不存在、配置解析失败或监听端口失败，应先处理这些明确错误。配置加载失败时，界面可能仍保留旧配置的信息，不能只看配置名称；重新启动内核后检查最新启动日志，确认实际加载结果与预期一致。

用显式代理隔离系统接管问题

在桌面终端执行下面的请求。示例假定混合端口为默认的 7890；若已修改，应使用客户端实际显示的端口。Windows 可将 curl 写为 curl.exe，避免某些终端中的同名别名。该命令直接指定本地代理，不依赖浏览器的系统代理设置；它只能验证这一次请求，不能代表所有应用都已被接管。

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

若提示无法连接本机端口，检查内核是否运行、端口是否一致、监听是否被占用；若已连上代理但后续超时，转查出站或 DNS。命令得到响应而浏览器仍失败，则重点检查浏览器扩展、自带代理和系统代理。响应状态不一定必须是成功页面：服务返回拒绝访问也说明部分链路已经建立，应结合响应内容判断，而不是把所有非成功状态都算成断网。

根据对照结果选择下一步

保留这组对照结果，再进入对应章节。恢复后至少验证一次直连目标、一次代理目标以及原先出错的应用，确认不是单纯靠缓存打开页面。若仍无法分类，可参照FAQ核对基本概念，但不要为追求某个界面状态而同时打开所有接管开关；最少必要设置更容易长期维护。

节点超时：区分入口不可达与握手失败

超时表示某一步没有在等待期限内完成，并不直接说明原因。可能是订阅中的服务器地址过期，也可能是域名解析、传输握手或目标服务响应停住。先记下当前出站、连接网络与测试目标，查看同一时间的日志。若客户端只给出“超时”，应展开附近错误行，判断停在解析地址、拨号连接还是建立安全连接之后，再决定是否需要更换出站。

确认订阅状态与系统时间

先到订阅提供方的管理页面核对服务是否有效、配额是否可用，以及入口是否近期调整。客户端更新订阅成功，只能说明拿到了内容，不能保证内容中的每个入口均可连接。重新更新当前订阅后，应确认当前配置确实刷新，并检查原策略组是否仍选择了旧条目。不要反复删除配置重建，以免丢失便于比较的规则、手动选择与覆盖设置。

开启操作系统的自动日期与时间，检查时区及实际显示时间。安全连接依赖证书有效期判断，设备时间明显偏离时会出现握手错误，也可能被界面概括为连接失败。时间恢复后重新建立连接，不必立即重装客户端。若日志提示证书名称或证书链问题，应检查订阅参数及网络是否存在认证拦截，不要通过关闭证书验证来掩盖真实风险。

比较单个出站、整组出站与不同网络

在同一网络、同一测试目标下选择另一个出站，仅更改这一项。一个失败而其余可用，通常应检查该入口状态；全部失败时，问题也可能位于本地网络、订阅整体状态或公共解析环节。再用可信手机热点重复一次：热点可用而原网络失败，说明故障更靠近原网络策略、路由或上游限制，但仍不能仅凭一次结果判断具体阻断方式。

不要只依据内置测试按钮判断业务是否可用。测试地址、超时阈值和实际访问的服务可能不同；测试成功也不保证某个应用的登录接口或实时连接正常。应再用浏览器或显式代理请求访问实际目标。若只有特定站点失败，查看是否被直连规则提前匹配，或者目标服务限制当前出口；这一分支不应继续按“全部节点不可达”处理。

按日志中的连接阶段处理

出现 no such host、解析超时等提示时，先查入口域名解析；出现 connection refused 时，通常说明连接到达的地址或中间设备主动拒绝了请求，应核对服务器端口与服务状态；出现等待超时，则可能是路径不通或对端未响应。错误文字只是线索，不能替代完整上下文，也不要把目标网站拒绝访问误当成代理服务器拒绝连接。

如果日志明确指向握手失败，检查协议类型、传输方式、服务器名称与订阅中的附加参数是否完整。某些转换服务可能丢失特定协议字段，手动编辑时也容易引入缩进或类型错误。优先恢复提供方原始、适用于 mihomo 的配置再测试。不要凭其他教程随意修改服务器名称、指纹或传输参数；这些字段必须与服务端配置匹配，而不是任选一种就能工作。

排除本地阻断并形成可复现记录

检查防火墙或终端安全软件是否在升级后阻止了客户端或内核进程。优先查看阻止记录并按程序路径建立必要规则，不要长期关闭整套防护。公司设备可能由统一策略管理，普通账户无法更改；应遵守网络管理要求。若另一个 VPN 正在运行，先断开后重试，避免默认路由或虚拟网卡竞争；测试时仍保持只有一个代理内核运行。

记录“原网络与热点”“单个与多个出站”“测试地址与实际业务”三组结果，通常就能把问题交给正确的维护方。需要按清单逐项操作时，可阅读节点超时排查笔记。如果所有入口都在多个网络下失败，而基础网络正常，应联系订阅提供方确认服务，不要继续通过增大超时值掩盖不可达问题。

订阅失败：分开检查获取、解析与启用

订阅导入实际上包含三个环节：客户端获取远程内容，内核解析配置，用户选择并启用配置。不同阶段的失败需要不同处理。“无法下载”应检查网络与地址，“解析错误”应检查返回内容和格式，“导入后没有出站”则要检查配置结构与当前选择。先保留完整错误提示，不要只记一个失败图标；清楚区分阶段可以避免反复更换同样无效的导入方式。

地址能否获取正确内容

从提供方复制完整订阅链接，注意聊天软件可能插入换行、漏掉尾部参数，或把地址与说明文字一并复制。链接前后的空格应清除，但不要擅自删除查询参数。若收到的是网页分享地址而不是订阅地址，客户端可能下载到登录页。浏览器能打开某个页面，也不代表客户端拿到的是代理配置；应检查提供方是否要求登录、特定请求头或专用订阅入口。

根据响应情况定位：未授权或禁止访问通常与凭据、账户状态、访问策略有关；资源不存在可能是链接过期；请求过多则应停止连续刷新并等待提供方恢复。网络超时与这些响应不同，不应全部归为密码错误。某些订阅域名需要现有代理才能访问，可使用仍有效的配置完成一次更新，但不要把订阅下载依赖自身这件事作为唯一启动路径。

内容下载成功后检查格式

适合 mihomo 的完整配置通常采用 YAML，但并不是任何包含代理地址的文本都能直接作为配置使用。某些入口返回其他客户端格式、编码后的链接集合或错误说明页面；这类内容下载成功仍会解析失败。优先选择提供方明确标注适用于 Clash 或 mihomo 的入口。客户端可能支持多种导入方式，是否支持某种格式应以实际界面与内核能力为准。

出现行号与列号时，围绕报错位置检查缩进、冒号、列表符号和字段类型。YAML 缩进使用空格，不要混入制表符；中文全角标点也不能代替语法标点。下面仅展示规则片段的结构，不是完整订阅：它依赖配置中已经存在的 Proxy 策略组。直接把片段当成整份配置导入，无法凭空生成可用出站。

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

配置已导入但没有实际启用

回到配置列表，确认导入的项目可以打开，并将它选为当前配置。若导入的是本地文件，后续远程订阅更新不一定会改变这份文件；需要弄清当前使用的是链接配置、文件副本还是带覆写的配置。开启连接后检查最新日志，确认没有解析错误。列表中的更新时间只能反映某次操作，不能单独证明运行中的内核已切换到新内容。

如果配置能启用但代理页面为空，检查是否确有代理条目或代理提供者，以及策略组是否引用它们。有些配置把出站拆到远程提供者中，主文件成功下载后，还要进一步获取子资源；子资源的域名、权限或格式失败，也会留下空组。此时应在日志里查提供者名称与更新错误，而不是只刷新主订阅。分享日志时，名称和下载地址也需要脱敏。

避免更新覆盖与规则重复

需要长期保留的本地设置，应尽量使用客户端提供的覆写机制，而不是直接修改会被订阅覆盖的正文。覆写也可能造成冲突：重复添加规则、引用不存在的策略组，或者把原有字段替换成错误类型。排查时先停用自定义覆写，使用原始订阅测试；原始内容正常后逐项恢复。不要同时更换订阅转换服务与覆写文件，否则很难定位是哪层改变了配置。

恢复后执行一次手动更新，确认配置仍能重新加载，并检查规则与出站选择是否保留预期行为。如果只有自动更新失败，再看后台运行条件和下载所使用的网络路径。订阅中可能包含私有域名与认证数据，不应上传到公开在线解析器。初次导入流程见订阅导入与连接设置；分流逻辑不符合预期时，再参照rules 匹配顺序说明检查。

速度慢与中断：区分带宽、路径和业务限制

“慢”需要拆成可观察的现象：首次打开网页等待很久、下载持续缓慢、视频频繁缓冲，或连接使用一段时间后中断。它们对应的瓶颈可能不同。先用同一设备、同一网络、同一目标重复测试，并暂时停止系统更新、云盘同步与其他大流量任务。不要拿不同网站的下载结果直接比较，也不要用某次内置连接测试的结果代替实际应用体验。

建立直连与代理的同条件对照

先测试允许直连的可靠目标，确认无线信号与基础网络稳定，再对需要代理的目标测试。若直连也慢，优先检查路由器负载、无线干扰与上游带宽；可尝试有线连接或靠近接入点。若只有代理慢，再比较同组中的另一出站。测试应连续观察一段时间，避免将短时拥塞或网页缓存命中误判为明显改善，也不要在切换出站时同时更换网络。

不同测试目标可能位于不同地区或使用不同内容分发网络，结果自然会有差异。某个大文件下载快，并不能证明实时会议或游戏路径同样稳定。对于频繁掉线的应用，应记录中断是否发生在锁屏、网络切换、设备休眠或固定空闲时间之后。若总与同一系统事件相邻，排查重点应从远端带宽转向后台策略、虚拟网卡和连接恢复机制。

检查实际命中规则与出口

在连接记录或日志中查目标域名对应的规则、策略组与最终出站。浏览器主页和视频资源可能来自不同域名，主页打开快而播放慢，并不一定是同一条连接出问题。规则匹配按顺序进行，前面的宽泛规则可能让后面的细分规则没有机会执行；修改后必须新建连接验证。已经建立的连接通常不会因为规则更新而自动迁移到新出站。

自动选择组还可能因为探测目标与实际业务不同而选择不理想的出口。可以暂时手动固定一个出站，观察问题是否消失，再决定是否调整探测策略。目标服务也可能针对出口地区、并发或账户限速，这不是增加本地端口或改变界面设置能够解决的。若只有某个服务慢，应优先比较该服务的不同资源与客户端，而不是给整份配置添加大量例外。

理解协议、丢包与网络切换

持续下载慢可能与远端负载、路径拥塞或丢包有关；首次请求慢则还可能涉及 DNS、握手与连接复用。移动网络和公共无线网络的表现也会随时段变化。不要随意把协议参数、连接复用或传输设置全部打开；参数必须与服务端支持情况相符。涉及 UDP 的业务还需确认出站和接管路径确实支持它，HTTP 代理可用不等于所有 UDP 业务都会经过相同路径。

网页正常但部分应用卡住时，可以在其他条件保持不变的前提下，对比系统代理与 TUN 的结果。若只在 TUN 下失败，再检查路由、DNS 与虚拟网卡，而不是立刻调整远端。MTU 不合适可能造成部分请求停滞，但应在有明确分段或路径线索时再测试，记录原值、一次只改一项，并保留回退方案。盲目降低 MTU 并不是通用提速方法。

用短时日志观察，不做长期高负载诊断

需要定位具体请求时，可短时提高日志详细程度，重现一次问题后立即恢复日常级别。高频日志、反复探测全部出站以及同时运行多个客户端，都会增加本机负担，也会污染对照结果。观察系统资源时，应看故障发生前后的变化及对应进程，不要仅凭内存占用数值判断泄漏。长期运行后逐渐变慢与打开即慢，应分别记录。

确认改善后恢复正常日志、停止重复测试，并在常用业务中验证。若问题仅在繁忙时段出现，保留时间与网络条件交由提供方分析，比单独发送“速度慢”的截图更有用。无法稳定复现时先收集条件，不要为了立即得到结论持续改动配置，否则原先可用的路径也可能被破坏。

DNS 问题：核对解析路径与域名规则

域名解析异常常表现为部分站点打不开、首次访问等待很久，或日志出现找不到主机。首先区分三个对象：订阅下载域名、代理服务器域名、最终目标网站域名。它们可能走不同的解析路径；目标网站解析正常，并不能证明服务器域名也能解析。先确定错误涉及哪一个域名，再检查对应请求，而不是把所有解析器一起替换。

区分系统解析与内核解析

操作系统、浏览器和 mihomo 可能分别使用自己的 DNS 设置。系统命令查询成功，只能说明这条查询路径正常；浏览器启用安全 DNS 后，也可能绕过系统解析。TUN 的 DNS 接管又可能把请求交给内核处理。排查时先记录浏览器安全 DNS、系统 DNS、内核 DNS 与 TUN 的当前状态，短时统一到可理解的测试路径，验证后再恢复需要的设置。

下面的命令用于观察系统查询与显式指定解析器的差异，不是推荐在所有网络长期固定某个公共 DNS。若第二条失败，也可能是当前网络限制了直接 DNS 请求。Windows、macOS 与多数 Linux 环境可使用 nslookup；精简系统若未安装该工具，应使用系统已有的解析诊断工具，不要为了测试从不明来源下载可执行文件。

nslookup example.com
nslookup example.com 1.1.1.1

检查加密解析与启动依赖

加密 DNS 的地址本身如果使用域名，连接它之前可能仍需要基础解析。代理服务器也使用域名时，若其解析请求又被强制交给尚未建立的代理，就可能形成循环依赖。此类故障常见于启动阶段全部超时，已有缓存时却偶尔能用。应检查配置是否提供了合理的引导解析和代理服务器域名解析路径，避免解析上游完全依赖自己尚未建立的出站。

下面是局部 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://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

理解 fake-ip 与应用兼容问题

fake-ip 会向应用返回映射地址，让内核在后续连接中识别原始域名。这类地址不是目标网站的真实公网地址，不能据此认定解析被破坏。若某个应用拿到映射地址后绕过内核直连，或者把地址交给其他设备使用，就可能失败。应先确认相关流量是否完整进入同一接管路径，再考虑针对明确不兼容的域名使用过滤规则，而不是把全部域名加入例外。

切换解析模式、网络或接管方式后，系统与浏览器可能仍缓存旧地址。关闭相关应用并重新请求，必要时按系统方法刷新解析缓存。Windows 可在确认需要后使用 ipconfig /flushdns；其他系统的命令随服务实现不同，不应直接套用。缓存刷新不是修复上游错误的替代办法，如果每次都要清缓存才能短暂访问，应继续查地址映射与流量路径是否一致。

区分解析异常与地理规则失效

GEOSITE 主要依据域名分类，GEOIP 依据地址库进行判断，二者不是同一类 DNS 功能。域名可以正常解析，但因为数据库缺失、分类名称错误或前置规则已命中而走错出站。应在连接记录里确认实际匹配规则，并检查数据库加载与更新日志。规则末尾的兜底策略也必须存在，否则没有命中前面规则的请求仍会失败。

修复后分别验证服务器域名、目标域名与原先异常的应用，并观察重启后的首次连接。数据库更新与分类排查可继续阅读GeoIP 与 GeoSite 更新指南。若只有特定网络的 DNS 失败，应保留该网络的限制条件，不要把临时测试配置直接推广到所有设备。

系统代理不生效：检查应用是否进入内核

系统代理通常向愿意读取系统设置的应用提供 HTTP 代理入口，并不是所有流量的强制转发。某些终端、游戏、服务进程或自带网络栈的应用不会使用它。TUN 则通过虚拟网络接口与路由接管更多流量，但依赖权限、驱动和路由状态。先用显式代理请求确认本地内核可用，再判断应用是否遵循系统代理，避免把接管范围差异当成客户端启动失败。

核对监听地址、端口与占用

在 FlClash 中检查混合端口，并与应用填写的代理端口逐字对照。本机应用通常使用 127.0.0.1；这是当前设备自身，不是局域网中的电脑地址。端口为默认值并不保证监听成功，另一个客户端或后台进程也可能已占用它。下面的命令用于查看监听进程：Windows 在终端执行第一条，macOS 或安装了相应工具的 Linux 可执行第二条。

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN

查询结果中的进程编号应与预期程序对应。不要看到端口被占用就直接结束未知进程，先确认名称与用途；系统服务或其他用户进程可能有正常任务。可以退出其他代理客户端，再重启 FlClash，或修改端口并同步更新应用设置。混合端口同时接受 HTTP 与 SOCKS5 请求，不意味着系统所有应用会自动知道这个入口。

检查应用自己的代理与绕过列表

浏览器代理扩展、开发工具、下载器和命令行环境变量可能覆盖系统设置。先停用相关扩展或恢复应用的“使用系统代理”，再重新启动应用测试。终端中若设置过代理环境变量，关闭客户端后这些变量也不会自动消失。不同终端会话可能继承不同值，因此“一个窗口能用、另一个不能用”应先比较环境，而不是立即修改内核配置。

如果使用 SOCKS5 代理，还要区分由应用本地解析域名还是交给代理解析。支持 curl 的环境中，可用下面的写法让域名经代理解析，以便与本地解析路径对照。不要仅将 HTTP 代理的地址前缀改成 SOCKS 后就认为行为完全一致。系统或应用的绕过列表也可能让内网域名、特定地址直接连接，排查前应记录这些例外。

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

TUN 已打开但应用仍未接管

确认内核启动日志没有权限不足、虚拟接口创建失败或路由写入失败。需要管理员权限或辅助服务的平台，应按客户端提示授予，而不是仅看开关是否变色。若刚升级或移动了程序目录，服务指向的路径可能需要重新确认。另一套 VPN、虚拟机网络或企业安全软件可能同时修改路由，先关闭冲突项做对照，不能假设开着更多接管工具就覆盖更完整。

浏览器使用系统代理可用，而 TUN 不可用时，重点检查 TUN 路由与 DNS 接管；反过来只有 TUN 可用时，多半应查应用是否忽略系统代理。对于 Windows 中部分商店应用，回环隔离也可能影响其访问本机代理；应依据具体应用与系统提示检查回环权限，不要对所有应用批量解除隔离。可先换一个普通浏览器验证本地入口，缩小问题范围。

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

手机连接电脑代理时，手机里填写的是电脑当前的局域网地址和混合端口，而不是手机自己的回环地址。电脑需要开启允许局域网连接，并确保防火墙只在可信网络放行必要端口。访客无线网络或接入点隔离可能阻止设备互访；即使两台设备显示同一无线网络名称，也不代表它们处于可互通的网络。换网后电脑地址变化，也要重新核对。

详细共享步骤见混合端口与局域网连接说明。退出客户端前先关闭接管；若异常退出后网络失效，检查系统代理是否残留指向已关闭的本机端口，再检查虚拟网卡与路由。恢复正常后验证一次客户端运行状态与退出状态，确保两种状态都符合预期，而不是只能依赖程序一直运行才能上网。

客户端崩溃：分离界面、内核与配置故障

启动失败至少有三种情况：程序窗口完全没有出现，界面出现后立即退出，或界面正常但内核不断停止。它们涉及的故障层不同。先记录安装包来源、处理器架构、系统类型以及最近一次变更，包括更新客户端、导入配置、移动目录和调整安全策略。不要在未备份前清空应用数据；崩溃后的配置与日志往往是定位问题最有价值的材料。

先检查安装包与运行环境

从安装包页面按系统和处理器架构选择客户端，不要只依据文件名中是否带某个平台判断。macOS 需要区分 Apple Silicon 与 Intel，Android 需要与设备 ABI 对应，Linux 还要考虑发行版的包管理方式。架构不匹配可能无法安装，也可能依赖兼容层运行后出现异常。系统升级后才发生的问题，应先检查客户端与当前环境的兼容情况。

检查安装目录、配置目录与临时目录是否可写，磁盘是否有足够可用空间。把程序放在只读位置、网络共享目录或受限文件夹中，可能导致资源写入失败。若安全软件隔离了组件，应查看具体告警与来源，再决定恢复或重新安装；不要直接关闭所有系统保护。公司管理的设备可能禁止虚拟网卡或后台服务，这种限制需要由管理策略解决。

判断是窗口退出还是内核退出

界面仍在但连接停止时，先看内核日志是否出现配置错误、端口占用或启动权限错误。导入一份错误配置就触发内核停止，并不等于整个应用损坏。可以停止自动连接，切换到之前已知可用的配置再启动。窗口本身消失时，则应检查系统应用崩溃记录与应用日志；两类记录的时间应对应，避免把较早一次错误当作本次原因。

Windows 可查看事件查看器中的应用程序错误，macOS 可查看控制台中的相关崩溃报告，Linux 若由桌面或服务管理器启动，可检查相应启动输出与用户日志。不同安装方式保存位置不同，应以客户端实际提供的日志入口为准。反馈时截取报错附近的上下文即可，不必打包整个用户目录；日志可能含有访问域名、路径与订阅信息，需要先脱敏。

使用副本测试配置与数据目录

先导出或复制当前配置、订阅信息和必要设置，再尝试停用近期添加的覆写、规则提供者与自动任务。原始订阅可启动而叠加配置会崩溃时，应逐项恢复扩展设置，找到最小触发条件。不要一次恢复所有内容后继续猜测。若客户端支持选择独立数据目录，可以在保留原目录的前提下测试；具体入口以当前客户端为准，不要套用未知启动参数。

需要重建数据时，先完整退出客户端与残留内核进程，再将原数据目录改名保留，而不是直接删除。重新启动后的空白环境仅用来判断是否与旧数据相关，不能凭空建立可用代理。测试完成后不要直接把旧目录全部覆盖回来，否则可能重新带入触发问题的文件；应按配置、规则与设置分别迁移，并保留每一步结果。

区分后台终止与可重复崩溃

长时间运行后窗口消失，可能是系统资源不足、会话退出或电源策略结束进程。观察同一时间是否有其他应用被关闭，以及系统是否进入休眠。内存增长应结合运行时长、连接数量与日志级别分析，单次占用偏高不能证明持续泄漏。若每次打开某个页面或加载某份配置都会退出，应记录最短复现步骤，这比随机重复重启更容易被维护者验证。

重新安装前先确认备份可读取，并记下旧设置。安装新包后先用最小配置验证启动，再恢复原有数据。需要临时改用其他客户端时，可参照客户端对比；跨平台选择优先考虑 Clash Plus，再根据系统与现有配置评估 Clash Verge Rev 或 FlClash。不同客户端的界面设置与覆写方式并不完全相同，不宜直接复制整个私有数据目录。

修复后至少测试冷启动、配置更新和正常退出三个环节。若只有恢复旧数据后再次出错，应继续缩小到具体设置，而不是反复重装。对偶发崩溃，保留时间与当时操作，等待更多证据；没有可复现条件时，不应把某个网络参数当作已经确认的根因。

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

移动设备的故障不仅来自订阅和出站，也常受 VPN 权限、电源管理、应用分流及无线与蜂窝切换影响。本章以 Android 上的 FlClash 为主；iOS 的客户端入口见iOS 安装选择，首推 Clash Plus。不要把 Android 的界面路径直接套用于 iOS，也不要把浏览器成功访问理解为所有应用都已进入同一条代理路径。

确认 VPN 授权与唯一接管关系

首次启动连接时，Android 通常会要求确认 VPN 连接权限。若误点取消，返回客户端重新启动并按系统提示授权。系统 VPN 状态与客户端内核日志应一起查看：状态栏存在 VPN 标识，不代表远端出站已经可用。若系统里还有另一款 VPN、过滤工具或企业网络组件，应检查是否占用了同一用户环境的 VPN 通道，避免两个应用反复争夺连接。

在系统 VPN 设置中检查始终开启与阻止未通过 VPN 的连接等选项。这些选项会影响客户端停止后的网络表现：若启用了阻断，断开后不能直连可能是预期策略，而不是无线网络损坏。诊断时先记录原状态，经确认后再临时调整；测试结束恢复需要的保护行为。受组织管理的设备可能不允许修改，应遵守设备管理要求。

只在锁屏后失效时检查后台策略

先让屏幕保持开启，验证连接一段时间，再锁屏重复相同测试。只有锁屏后断开，且唤醒后恢复时，优先检查电池优化、后台运行和自动启动权限。不同厂商命名不一致，应在系统应用设置里寻找对应项，而不是照搬其他手机的路径。允许必要的后台活动后重新测试，不必把整台设备所有应用的节能限制全部取消。

区分“系统结束了客户端进程”和“进程仍在但远端连接空闲断开”。前者通常会伴随通知消失、进程重新启动或 VPN 状态变化；后者可能在重新发起请求后恢复。锁屏期间无线网络休眠、蜂窝数据限制也会产生相似现象。记录通知、VPN 标识和实际应用请求的变化，才能决定检查电源管理还是连接恢复，单看主界面按钮不足以判断。

切换无线与蜂窝后重新验证路径

网络切换会改变本机地址、默认路由与 DNS，旧连接可能不能继续使用。先等待系统网络稳定，再在客户端重新建立连接，并关闭目标应用后重试。若无线可用、蜂窝失败，检查客户端是否被禁止使用移动数据，以及订阅入口在蜂窝网络能否访问；反过来仅无线失败时，应排除需要网页认证的热点、设备隔离和该网络自身的访问限制。

部分应用同时使用 IPv4、IPv6 或 UDP 路径，表现可能与浏览器不同。不要为了测试直接长期关闭系统 IPv6；先检查失败请求的日志、接管范围与出站支持，再做单项对照。Android 的私人 DNS 设置也可能与当前解析路径产生差异，临时调整时保留原值。若只有某个应用异常，还要检查它自己的安全 DNS、内置代理或受限后台数据设置。

应用分流与局域网代理的边界

如果启用了按应用代理，确认当前使用的是包含列表还是排除列表。应用装在工作资料、分身或其他用户空间时，可能不是同一个应用实例；主空间的选择不一定覆盖它。修改列表后重新启动相关应用或重新建立 VPN，避免旧连接继续沿用原路径。系统下载服务与浏览器也可能由不同进程发起连接，不能仅凭浏览器已勾选推断所有下载都会被接管。

手机连接电脑共享代理时，无线设置中的 HTTP 代理一般只影响遵循该设置的应用，不等同于手机建立了完整 VPN。手机填写电脑的局域网地址与实际端口，并保证双方处于可互通的可信网络。离开该网络后若仍保留手动代理，浏览器可能继续尝试访问不存在的电脑地址；应按网络分别管理设置，而不是把家中代理地址用于所有热点。

完成修复后依次验证亮屏、锁屏、无线切蜂窝以及客户端停止后的网络行为。若只解决了前台浏览器访问，后台同步与其他应用仍需独立测试。首次使用可返回入门指南完成连接验证；需要确认内核与客户端分工时，可阅读Clash 开源生态关系梳理。保留最终有效设置与回退方法，下一次网络变化时就能按同样顺序重新定位。