Clash 故障排查大全

无法上网：从本地入口到规则出口

先确认故障影响范围

客户端界面能打开、代理开关已开启，都不等于网络请求已经成功。先记录发生时间、网络类型、当前配置和失败应用，再分别访问一个通常可以直连的网站与实际失败的网站。关闭代理后重复测试：两类网站都失败，应先处理无线连接、网关或网络认证；只有启用代理后失败，才把重点放在本地监听、规则和远端出口。

暂时退出其他代理客户端、浏览器代理扩展及可能接管网络的工具，避免两个程序反复覆盖系统设置。不要立即删除配置，也不要同时打开系统代理和 TUN 来碰运气。先保留当前日志，从一种接管方式开始复现。企业设备存在管理策略时，应遵循设备管理要求，不要通过移除安全组件来排除冲突。

用显式代理请求绕开系统设置

到客户端设置中读取混合端口，并确认内核已启动。下面命令中的端口是示例，必须替换成实际监听值。显式指定代理可以暂时排除浏览器是否遵循系统代理这一变量。Windows 使用 curl.exe 可避开部分终端中的同名命令别名；其他平台通常直接使用 curl。

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 25 \
  -I https://example.com/

连接本地端口立即被拒绝，说明请求尚未进入代理内核，优先检查内核状态与端口。等待远端时超时，则继续看日志中的目标地址、匹配规则和出口。收到 HTTP 响应但状态不是成功，也表明部分链路已经建立；服务端拒绝、登录要求与内容访问限制不能简单归为本地代理失效。上述命令只检查响应头，遇到不支持该请求方式的网站，再用普通 GET 请求复测。

区分规则命中与出口可用性

打开连接或日志页面，复现一次失败请求，核对域名实际命中了哪条规则、进入哪个代理组、该组选择了什么出口。规则模式下，目标可能被送往直连，也可能命中拒绝规则。短时切换全局模式只用于对照：若全局可用而规则模式失败，重点检查规则顺序和代理组选择；若两者都失败，则继续检查出口连接，不必反复修改分流列表。

同一个网页可能依赖登录域名、静态资源和接口域名。首页能出现而登录按钮一直等待，通常需要检查失败的子请求，而不是只给主页添加规则。可以结合浏览器开发者工具的网络面板查找失败域名，再与客户端连接记录对应。提交截图前遮盖完整网址中的查询参数、账号标识和订阅信息，保留错误名称与规则命中结果即可。

最后用同一目标验证恢复：显式代理请求成功、浏览器成功、其他需要代理的应用成功，分别确认。恢复规则模式并关闭临时调试日志，避免把测试状态当成长期配置。若浏览器仍失败而命令成功，转到系统代理章节；若日志指出解析错误，转到DNS 章节。更短的逐项路线见已连接却打不开网页检查清单。

节点超时：分开检查解析、握手与传输

读清错误发生在哪一段

界面里的超时可能来自检测网址，也可能来自真实业务请求，两者不能互相替代。一次检测失败不一定说明出口完全不可用：检测目标可能限制访问，检测请求也可能受规则影响。先选定一个出口，使用相同目标连续复现少量请求，再打开对应时间的日志，区分服务器域名解析失败、连接服务器超时、协议握手失败和目标站点响应过慢。

连接被拒绝通常表示目标地址返回了拒绝，或中间设备主动拒绝了连接；连接超时则只说明等待时间内没有得到预期响应，不能直接推断服务器已经关闭。认证失败、证书名称不匹配等错误属于另一类证据，不应通过加长超时掩盖。记录错误原文，比单独截取一个红色超时标签更有诊断价值。

检查系统时间与服务器入口

启用系统自动校时，确认日期、时区与实际时间一致。基于证书的连接会校验证书有效期，错误的系统时间能使原本可用的配置持续握手失败。然后确认订阅更新后的服务器地址、端口和传输参数没有被本地覆盖。复制节点时漏掉路径、服务名称或传输层设置，可能表现为底层连接建立，但代理协议始终无法完成握手。

如果需要单独测试服务器端口，可以在 PowerShell 中使用下面命令。示例域名仅用于说明语法，应替换为配置中的服务器地址。测试成功只表示 TCP 端口可连接，并不能证明认证、TLS 或上层代理协议正常；测试失败也不能用来判断仅使用 UDP 的服务。不要为了测试而公开完整节点配置。

Test-NetConnection -ComputerName example.com -Port 443

不建议把关闭证书验证当成常规修复。证书错误应核对服务器名称、系统信任链、系统时间及网络是否存在受管理的检查设备。对于需要特定 SNI 或传输路径的配置，应向服务提供方确认参数，而不是猜测。使用过期订阅中保留的旧入口时，更新订阅可能解决问题，但更新前仍应备份本地覆盖设置。

通过对照判断本地网络限制

保持同一设备、同一配置、同一目标，只把网络从当前无线连接切换为手机热点。如果热点可用，原网络不可用，故障范围已缩小到原网络路径、认证状态或访问策略。再用同一网络上的另一台设备作对照。不要同时更换客户端与出口，否则测试变量过多，恢复后也无法知道真正原因。

部分网络只允许特定连接方式，UDP 尤其可能受到限制。网页使用 TCP 正常，而依赖 UDP 的应用失败，应先确认出口协议、内核和远端服务是否支持相应流量。TUN 能接管应用的数据包，但不能让不支持 UDP 的出口自动具备该能力。涉及 IPv6 时，还要比较实际连接的地址族，避免把某一条不可达路径误判为所有入口都失效。

如果只有一个入口失败，其他入口在同条件下可用，应保留失败时间、错误类型和网络对照结果交给服务提供方。所有入口都失败且直连正常时，再检查客户端内核、DNS 与本地防火墙。停止高频重复检测，恢复合理的检查频率；持续并发探测不仅干扰日志，也可能触发远端限制，使故障表现更复杂。

订阅失败：检查链接、响应内容与配置合并

区分下载失败和解析失败

订阅更新至少经过请求地址、获取内容、解析配置和应用配置几个环节。下载超时通常发生在前两步；解析失败则可能已经拿到内容，只是返回值不是客户端支持的配置。先记录错误属于网络请求、HTTP 状态、YAML 语法还是内核配置校验，不要把所有错误都归结为链接过期。更新前导出当前可用配置，防止后续操作覆盖最后一份有效副本。

从服务提供方账户页面重新复制订阅链接，注意剪贴板是否混入换行、前后空格或聊天软件的标点。链接通常包含访问凭据，不能粘贴到公开转换网站、在线 YAML 检查器或公开工单。浏览器能打开链接只证明浏览器完成了请求，不代表客户端使用了相同代理、请求头和网络路径，也不能证明响应就是兼容配置。

检查返回内容的真实类型

若客户端支持查看下载错误详情，先看状态码与响应类型。返回网页、登录页面、访问验证页面时，内核可能把首行 HTML 当成 YAML，随后报出看似语法错误的提示。状态为成功也不保证内容正确，服务端可能用成功状态返回说明文字。应在本地检查少量文件开头，判断是配置结构、节点文本，还是网页内容；不要把包含凭据的完整文件上传求助。

不同客户端支持的订阅格式并不完全相同。面向其他协议或应用生成的内容，不能仅改文件扩展名就当作 Clash 配置。应在提供方选择兼容 Clash 或 mihomo 的订阅格式，再重新导入。若配置引用了代理提供器与规则提供器，主配置导入成功后还要检查这些外部资源能否下载；主文件成功不代表它依赖的资源已准备完成。

定位 YAML 与覆盖配置错误

本地编辑后出现解析失败，先检查缩进是否使用空格、同级键是否对齐、列表项前是否保留短横线。含特殊字符的字符串需要正确引用，但不要不加判断地给所有数字和布尔值添加引号。下面是合法的局部结构，用来对照语法，不是可直接连接的完整配置；实际代理组及出口仍由订阅提供。

mixed-port: 7897
mode: rule
log-level: info
allow-lan: false

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

客户端可能把订阅原文、全局覆盖、脚本处理和界面选项合并后交给内核。原文件语法正确，最终配置仍可能因为引用了不存在的代理组而失败。暂时停用最近增加的覆盖或脚本，再应用原始订阅；如果恢复，逐项重新启用，找到造成冲突的那一项。不要直接修改自动更新的原始文件来长期修复，因为下一次更新可能覆盖手工改动。

自动更新失败还要核对应用是否在后台运行、设备是否休眠，以及更新间隔的单位。不同客户端可能按分钟、小时或内部秒数保存参数，不能照搬别处的数值。不要用极短间隔反复请求失效链接；先手动更新成功，再恢复自动计划。具体设置入口与失败分支可查看订阅自动更新间隔说明。

确认恢复时，不只看更新时间，还要确认目标配置已经被选中、内核成功应用、代理组引用存在。若服务端返回的内容持续错误，应向提供方提交脱敏后的状态码、报错行号与请求时间。更多格式判断见订阅解析失败自查步骤；基础订阅概念可回到帮助中心查阅。

访问速度慢：区分建连等待与持续传输

先描述慢发生在什么阶段

网页长时间空白后突然完整出现，与文件开始很快随后下降，是两类不同的问题。前者更可能涉及域名解析、连接重试、握手或某个关键资源阻塞；后者更可能涉及出口容量、网络丢包、远端限速或本地无线质量。先明确是所有网站、单个网站还是某类应用变慢，再用相同目标、相同文件和相同网络作比较，避免把不同服务端的差异当成客户端性能差异。

浏览器开发者工具中的网络时间线可以区分等待连接、等待首字节和下载内容。某个统计脚本或字体资源一直等待，也可能拖住页面的完成标记。客户端日志可以补充出口与规则信息，但不会替代浏览器对页面依赖的观察。先找到真正耗时的请求，再确定它走直连还是代理，往往比重复切换整个配置更有效。

保持入口与目标不变做对照

暂停系统更新、云盘同步和其他占用带宽的任务，用单个下载任务验证。无线环境不稳定时，靠近接入点或使用有线网络作一次对照。不要在同一时刻运行多个测速工具，也不要根据一次探测结果给出口排序。检测网址的响应时间只代表该次检测的路径，不等于大文件吞吐，也不等于实际业务站点的体验。

需要观察显式代理请求时，可以使用 curl 输出分阶段耗时。下面命令保留正常页面输出，并在末尾打印时间；实际测试时换成固定目标。通过 HTTP 代理访问 HTTPS 时，部分时间包含代理协商，不能把某个字段直接当成远端服务器的独立耗时。应在同条件下看重复测试的变化，而不是用一个数字作绝对结论。

curl --noproxy "" --proxy http://127.0.0.1:7897 \
  --connect-timeout 10 --max-time 30 \
  --write-out '\nconnect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

如果直连请求也慢，应先检查本地网络和目标站点；只有某个出口慢，可切换同配置中的其他可用出口比较。若某个网站在所有出口都慢，但其他站点正常，可能涉及目标服务负载、地区路径或应用自身限制。此时重装客户端通常没有依据。保留目标、时间和出口选择，便于后续复测，而不是只记录一句速度慢。

检查规则绕路与传输差异

规则把本可直连的资源送到远端，可能增加建连距离；把需要代理的接口送直连，则可能触发长时间重试。查看主页面与接口域名是否被拆到了不一致的出口，尤其是需要会话一致性的登录服务。调整时只修正明确错误的域名规则，不要把大段未知地址加入全局绕过列表；修完后重新建立连接，旧连接可能继续沿用原出口。

浏览器可能优先尝试使用 UDP 的 HTTP/3，再回退到其他连接方式。如果出口或网络不支持该路径，等待回退会造成间歇性首开缓慢。应先核对客户端、出口协议与网络能力，再做有记录的浏览器对照测试。关闭某项协议只能帮助判断原因，不应不加说明地作为所有设备的统一优化方案。

TUN 环境下出现小页面正常、大请求卡住，才进一步考虑路径 MTU 或相关网络设备行为。不要直接套用网上的 MTU 数值，也不要同时改 DNS、协议栈和 MTU。先保留原值，使用系统代理对照；若只有 TUN 复现，再结合日志和网络环境逐项调整。代理转发并不能消除原网络的丢包，虚拟网卡也不会自动提升链路容量。

恢复后的验收应使用实际业务：打开同一网页、登录同一服务、下载同一资源。清除临时测试条件并恢复日常规则，只保留确实改善且能解释作用的设置。若问题只在固定时段出现，记录时段比连续修改客户端更有价值；若仅某个应用异常，再检查该应用的缓存、扩展及独立代理设置。

DNS 问题：理清系统、应用与内核解析路径

先确定谁在解析域名

DNS 问题常表现为域名打不开、首次访问等待很久，或同一网站在不同应用中结果不同。系统 DNS、浏览器安全 DNS、应用内置解析和 mihomo DNS 可能同时存在。先记录失败域名、报错类型与使用的接管方式。直接访问某个 IP 成功只能作为线索，不能替代 HTTPS 域名测试，因为证书、主机名和服务端虚拟主机都可能依赖域名。

系统工具查询成功，也不代表客户端解析路径正常。显式 HTTP 代理通常可以把目标域名交给代理处理；SOCKS 请求是否在本地解析，则与调用方式有关。浏览器启用了独立的安全 DNS 时，还可能绕开系统解析结果。排查时应选择一条路径进行测试，并在记录中说明测试工具，避免把不同解析来源的结果混在一起比较。

理解主要 DNS 参数的边界

nameserver 指定常规上游，default-nameserver 可用于解析上游服务器自身的域名，避免域名型上游缺少引导解析。proxy-server-nameserver 用于代理服务器域名的解析，与业务网站的解析不是同一个问题。fallback 及其过滤条件参与候选结果选择，不是简单地在所有请求超时后才顺序调用的备用名单。

下面片段展示 fake-ip 模式的最小观察结构，不包含完整 TUN 与分流配置。上游地址只用于说明参数，应根据网络可达性选择。监听地址限制在本机，避免不必要地向局域网提供 DNS 服务。若客户端已经通过界面或覆盖文件管理 DNS，应在同一入口修改，不要让多份配置互相覆盖。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

fake-ip 返回的是内核维护映射的虚拟地址，不是网站服务器真实地址。看到测试网段地址本身并不等于解析受到破坏；真正需要确认的是后续连接是否仍进入维护该映射的内核。若应用拿到虚拟地址后绕过 TUN 直连，或内核重启后应用仍使用旧缓存，就可能出现解析看似正常但连接失败的情况。

按缓存与接管顺序恢复

先应用配置并确认内核启动，再清理系统和应用中与故障相关的缓存，然后重新建立请求。Windows 可以使用下面命令清理系统解析缓存；浏览器自身的缓存和连接池可能仍需重启浏览器才能排除。其他系统应采用对应平台的方法，不要把 Windows 命令当作通用步骤。频繁清缓存只能改变表象，不能修复错误的上游或接管路径。

ipconfig /flushdns

TUN 的 DNS 劫持通常针对指定的 DNS 流量，不代表所有应用自带的加密解析都被统一接管。内核 DNS 监听在非标准端口，也不会让系统自动把查询发送到这个端口；还需要配套的系统设置或 TUN 转发配置。日志没有 DNS 请求时，先验证请求是否进入内核，再讨论更换上游，避免改了没有被使用的配置。

局域网设备名、公司内网域名和组播名称需要单独考虑。公共解析器通常不知道内部名称，把全部查询强制送往公共上游可能导致打印机或内部服务失联。应根据实际域名和网络要求设置解析策略或 fake-ip 过滤，保留原有内网解析路径。过滤某个域名只改变相关处理方式，不自动保证系统能够解析该名称。

验收时分别测试常规网站、原失败域名和需要使用的内部服务，再确认代理服务器域名也能稳定解析。若只能在关闭某个 DNS 设置后恢复，记录该设置对哪条路径生效，再决定保留方式。参数组合与 DNS 劫持的进一步解释见mihomo DNS 配置详解，不要仅为消除一条错误日志而替换整个 DNS 段。

系统代理不生效：核对端口、应用与接管方式

先验证本地监听，再看系统入口

系统代理开关的作用是写入系统代理设置，不等于所有程序都会遵循。先用显式代理请求确认内核端口可用，再检查系统中的代理主机是否为本机回环地址、端口是否与客户端一致。修改混合端口后，系统设置、浏览器扩展与终端环境变量可能仍保留旧值。必须同步检查这些入口，而不是只确认客户端设置页显示了新数字。

端口冲突时，内核可能启动失败，也可能由另一个进程占用了预期端口。在 Windows PowerShell 中可以查看监听进程；在 macOS 或 Linux 上可以使用 lsof。示例端口仍需按实际值调整。找到进程后先识别所属应用，不要直接终止未知系统进程；关闭冲突应用或改用空闲端口，再重新应用设置。

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

# macOS / Linux
lsof -nP -iTCP:7897 -sTCP:LISTEN

分清浏览器、终端与系统服务

浏览器代理扩展可以覆盖系统设置，某些应用还提供独立的代理菜单。终端工具常读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY，但具体支持情况由工具决定。环境变量通常在进程启动时继承，修改后已运行的终端或编辑器不一定立即更新。不要因为浏览器正常，就推断后台服务也使用了同一代理。

Windows 的用户代理设置与部分系统服务使用的 WinHTTP 设置并不相同。排查某个服务时，可以先用 netsh winhttp show proxy 查看其环境，但不应把导入、重置 WinHTTP 当作普通浏览器的固定修复步骤。macOS 要核对当前使用的网络服务，而不是修改一个没有连接的接口；Linux 桌面代理是否生效，还取决于桌面环境与应用实现。

TUN 模式需要单独检查权限与路由

不遵循系统代理的应用可以考虑 TUN，但开启前要确认客户端的服务组件或权限要求已经满足。只看到 TUN 开关打开，不代表虚拟网卡与路由已经成功建立。查看日志是否出现设备创建失败、权限不足或路由冲突。协议栈选项会影响兼容性，应按客户端支持的选项逐项测试，不要同时改协议栈、DNS 与出口。

其他 VPN、虚拟机网络、容器网络和安全软件可能与 TUN 路由重叠。先退出非必要的网络工具，再比较系统代理与 TUN 的行为。内核必须能够连接自身的远端服务器，错误的路由可能把这个连接再次送回代理，形成循环。使用客户端提供的自动路由与接口探测机制时，也要确认它识别的是当前有效网络接口。

局域网共享需要额外开启允许局域网连接，并正确设置监听地址与防火墙范围。其他设备里的 127.0.0.1 指向它们自身，不能用来访问这台电脑上的代理。不要为了共享直接关闭整套防火墙，也不要把本地代理端口开放到公网。只允许可信局域网访问，并注意共享网络变更后原有访问规则是否仍然合适。

退出客户端后无法恢复上网，先检查系统代理是否残留在已停止监听的本地端口。手动关闭残留设置，再确认其他应用是否也写入了代理或自动配置脚本。恢复连接后重新启动一个客户端验证，避免多个开机启动项互相覆盖。关于系统代理和 TUN 的基础差异，可在帮助中心继续查阅；日常首次开启顺序见快速上手教程。

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

先判断退出的是哪一部分

窗口关闭、托盘仍在、内核停止与整个进程退出，是不同故障。先观察托盘图标和系统进程列表，再确认日志是否继续写入。点击关闭按钮后窗口隐藏到托盘，通常属于设置行为，不是崩溃。界面仍然可用但内核反复重启，则应优先检查配置应用错误、资源路径与权限，而不是把所有现象都归到图形界面。

记录崩溃前的最后一个动作：导入订阅、更新应用、切换 TUN、恢复休眠还是登录系统。保留应用日志末尾与系统错误记录的对应时间，不必提交整个配置目录。日志中可能出现服务器地址、访问域名和配置路径，应先脱敏。遇到可以稳定复现的操作，清晰的复现顺序比大量重复截图更有用。

备份后做最小化启动

退出客户端并确认相关进程结束，再复制配置目录到单独位置。备份应包含订阅、覆盖文件和必要的用户设置，但不要把它上传到公开网盘。接着使用客户端支持的独立配置目录或重置方式启动测试环境；若不清楚数据目录位置，先查看设置中的打开配置目录入口。不要直接删除用户目录中的未知文件来尝试修复。

最小环境能启动时，先导入一份确认有效的配置，再逐项恢复覆盖、脚本和界面设置。只要某项恢复后问题重现，就已获得明确范围。配置错误应按报错行与最终合并结果修复；界面数据库或窗口状态问题，则不必改动代理协议。若安装包包含独立内核，避免手工替换成来源和兼容性不明确的文件。

需要在本地验证 mihomo 配置语法时，可以使用内核提供的测试参数。下面命令假定当前目录存在可执行文件和测试配置。测试会检查配置能否被内核接受，但不会保证服务器可达、规则符合预期或订阅资源始终可下载。命令输出同样可能包含敏感路径，转发前应检查内容。

# macOS / Linux
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

检查架构、运行环境与权限

重新下载前先确认操作系统与处理器架构，特别是 Intel 与 Apple Silicon，以及安卓设备的安装包架构。安装成功不代表所有依赖都满足；图形运行环境、系统组件和安装位置权限也可能影响启动。应根据应用给出的具体缺失组件或系统错误处理，不要批量安装不明来源的修复工具。

Windows 上可结合事件查看器定位故障模块；macOS 可检查系统崩溃报告与应用启动记录；Linux 可查看用户会话日志以及从终端启动时的输出。通过终端启动可以暴露图形依赖错误，但不应长期以管理员权限运行整个桌面程序来掩盖问题。服务组件需要权限时，应使用客户端提供的安装和管理流程。

安全软件隔离了某个组件时，先核对隔离记录、安装来源和触发原因，不要一律关闭防护。安装目录不可写或被同步软件占用，也可能使更新后文件不完整。先完全退出应用，再通过下载中心选择匹配系统的安装包重新安装；保留数据备份，避免卸载过程清除仍需排查的配置与日志。

Clash for Windows 与 ClashX Meta 已停止维护，遇到新系统兼容问题时，应考虑迁移到仍适配当前环境的客户端，选型首推 Clash Plus，Linux 可查看 Clash Verge Rev 与 FlClash。迁移时先导入配置并完成基础连通测试，再逐项恢复自定义功能。不要直接复制不同客户端的整份界面设置目录；配置语法兼容不代表内部数据格式相同。

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

Android 先核对 VPN 与应用范围

Android 客户端通常通过系统 VPN 接口接管流量。首次连接需要系统授权，授权被取消或被设备策略限制时，应用界面可以正常显示，但不会建立有效接管。先看系统 VPN 状态与客户端日志，再检查是否有其他 VPN、工作资料网络或应用占用了同一使用范围。不要仅凭通知栏图标判断出口和 DNS 已经正常。

Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的配置格式和设置入口存在差异。导入时应选择对应格式，不能假定所有安卓客户端都接受相同配置。启用按应用代理后，确认故障应用被列入预期范围；有些界面采用包含名单，有些采用排除名单，读反选项会造成浏览器可用、某个应用始终直连的现象。

系统的始终开启 VPN 与阻止未通过 VPN 的连接，是独立的控制项。启用了阻止选项后，隧道断开时网络被阻止可能是系统按策略工作，而不是无线连接损坏。排查时先记录原设置，再在了解影响的前提下进行对照。受单位管理的设备应遵循管理要求，不要修改工作资料的安全策略。

后台中断与安装失败分别处理

锁屏后失效、回到客户端立即恢复，优先检查电池优化、后台活动限制与厂商自启动管理。允许必要的后台运行后，重新测试一次完整的锁屏与唤醒过程。把所有省电设置全部关闭并不能准确定位问题，也可能影响续航。若后台进程仍在，但从无线切到蜂窝网络后失败，重点应转向网络重建和 DNS，而不是继续增加后台权限。

安装提示不兼容时，检查系统要求与处理器架构；覆盖安装失败还可能涉及不同签名或安装来源。卸载前导出配置，因为应用数据可能随卸载删除。不要为绕过安装错误而随意降级或替换未知安装包。安卓可在Android 下载分区对照客户端与架构，首次导入步骤仍按教程执行。

iOS 检查隧道配置与资源限制

iOS 可从iOS 下载分区进入 Clash Plus 的商店页面，客户端官网为 clashplus.io。连接问题先检查系统中的 VPN 配置是否对应当前客户端，再确认应用获得建立隧道的授权。旧配置残留、其他网络工具或设备管理策略都可能影响连接，应按系统显示的具体状态判断。

iOS 的网络扩展与前台界面不是同一个运行部分，界面可以打开并不表示隧道持续正常。较大的配置、过多规则资源或频繁更新，可能增加扩展负担。先用较小且确认可用的配置复测，逐步恢复外部资源。不要把后台限制问题简单解释成订阅损坏，也不要在缺少日志时不断重新安装应用。

无线、蜂窝与门户认证分开测试

公共无线网络可能要求先完成浏览器认证。认证前开启代理，登录页面可能无法出现；先按网络要求完成认证，再启用客户端。无线与蜂窝网络的 IPv6、DNS 和访问路径可能不同，切网后应重新建立测试请求。不能因为同一配置在家中可用，就排除办公网络或热点上的路径限制。

手机热点也不保证把手机自身 VPN 的流量接管能力共享给连接设备，具体行为取决于系统实现。电脑连上手机热点后，仍应按电脑端的系统代理或 TUN 设置独立验证。移动端恢复后，用锁屏、唤醒、切网和故障应用各测试一次；仍失败时，整理系统类型、客户端名称、网络条件与脱敏日志，再回到本手册对应章节继续缩小范围。