Clash 客户端系统排查手册

01 / CONNECTION

开启 Clash 后完全无法上网

先区分“内核未工作”和“流量进入后处理失败”

打开客户端后所有网页都无法访问，最有效的第一步不是换节点，而是观察请求有没有进入 Mihomo 内核。进入客户端的日志页面，刷新一个普通网页。如果日志没有出现任何新连接，故障通常位于系统代理、TUN 接管、浏览器代理设置或本机端口这一层；如果日志持续出现请求，但结果是超时、拒绝连接或 DNS 错误，说明流量已经到达内核，应继续检查节点、规则和 DNS。

接着暂时关闭系统代理或退出客户端，确认设备能否恢复直连网络。关闭后仍不能访问，问题更可能来自 Wi-Fi、网线、路由器、认证门户或系统网络栈。关闭后立即恢复，则说明故障与客户端接管有关。此时不要急着卸载，先查看当前监听端口。常用的 mixed-port 同时接受 HTTP 与 SOCKS 连接，系统代理里填写的端口必须与配置和客户端设置一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

Windows 可在 PowerShell 或命令提示符执行 netstat -ano | findstr :7890，macOS 与 Linux 可执行 lsof -nP -iTCP:7890 -sTCP:LISTEN。看到 Mihomo 对应进程处于监听状态，才能说明本地代理入口已经建立。没有监听时，回到客户端查看内核启动错误；端口被其他程序占用时，可结束冲突进程，或同时修改客户端混合端口和系统代理端口。关于冲突进程的完整定位方法，可继续阅读端口被占用排查。

用直连、全局和规则模式确定故障层级

在内核正常运行的前提下，先切到直连模式测试。直连模式可用，说明本机代理入口和 DNS 基本能够工作，故障更可能出在节点或规则；直连模式也不可用，则重点检查 DNS、TUN 路由和系统代理。随后切到全局模式并选择一个明确可用的代理节点。如果全局模式可以访问、规则模式不行，说明请求被错误规则送到了不可用策略组，或最终匹配到了不合适的 DIRECT、REJECT 策略。

规则模式下应从日志中找到目标域名对应的匹配结果。例如访问代码托管站点时，日志会显示命中的规则类型和最终策略组。不要只看策略组名称，还要继续展开策略组，确认它实际选择的是哪个节点。策略组可能仍停留在一个已经失效的手动选择项，也可能由于健康检查地址不可达而没有可选结果。修改后重新发起请求，旧连接不会自动代表新配置结果。

处理 TUN、局域网和防火墙边界

TUN 模式通过虚拟网卡接管更多应用流量，覆盖范围比系统代理大，但也更容易受权限、路由表和安全软件影响。若开启 TUN 后断网，先关闭 TUN，仅保留系统代理测试。关闭后恢复，说明节点本身通常不是首要问题。Windows 可检查客户端是否取得创建虚拟网卡所需权限；macOS 需要确认网络扩展或系统服务已被允许；Linux 则要检查 TUN 设备、路由规则和进程权限。修复后再开启，不要让系统代理与多个第三方 VPN 同时接管默认路由。

allow-lan 只决定其他局域网设备是否可连接本机代理，并不影响本机是否能够通过代理上网。需要向局域网提供服务时，还要确认监听地址、防火墙入站规则和路由器的客户端隔离设置。排查期间建议先保持 allow-lan: false，减少变量。最后检查系统日期和时区；时间偏差过大会让 TLS 证书校验失败，表现为大量网站同时握手失败。完成上述步骤后，再恢复规则模式、TUN 和局域网共享，每次恢复一项并重新测试。

02 / TIMEOUT

节点超时、握手失败或无法测速

测速失败不等于所有业务连接都失败

客户端里的节点测速通常访问一个固定测试地址，并在限定时间内完成 DNS、TCP、TLS 或 HTTP 请求。测试地址被当前网络限制、返回方式改变，或者节点不允许访问该地址时，界面会显示超时，但其他网站仍可能可用。因此先用真实业务请求验证：在全局模式选择该节点，打开两个不同站点，同时观察日志。若网页可访问而测速失败，应调整健康检查地址或间隔，而不是立即判定节点失效。

如果实际请求也超时，先比较同一配置中的多个节点。只有单个节点失败，常见原因是远端入口不可达、协议参数不匹配、证书名称不一致或节点已失效；全部节点同时失败，则更像本地网络限制、订阅字段解析异常、系统时间错误或运营商网络路径问题。再切换网络测试，例如从家庭宽带切换到手机热点。换网络后恢复，说明配置和客户端大体可用，应重点分析原网络的 DNS、IPv6、UDP 或出口限制。

根据日志阶段判断错误位置

“timeout”只是最终结果，真正有用的是超时发生在哪个阶段。连接远端 IP 就超时，通常是 TCP 路径不可达或入口端口被阻断；出现 TLS 握手错误，要检查服务器名称指示、证书域名和系统时间；出现 authentication failed，说明认证信息与服务端不一致；能建立节点连接但目标网站超时，则还要考虑远端 DNS、目标站点限制和策略链。复制日志时应保留报错类型和目标域名，但不要公开订阅地址或认证字段。

协议配置中，地址、端口、认证信息、传输层参数必须作为一组保持一致。手工编辑 YAML 时，缩进错误可能让某个字段落到错误层级，客户端仍能导入，却无法按预期建立连接。建议与订阅原始内容对照，不要凭经验把不同节点的 TLS、网络类型或插件参数混合。节点名称只是显示文本，名称看起来相同不代表参数相同。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

url-test 会根据测试结果自动选择候选项，interval 是重新检查的秒数，过短会产生额外连接，过长则无法及时发现状态变化；tolerance 用于避免几个延迟接近的节点频繁切换。排错期间可以先改成手动 select，逐个验证节点，排除自动组选择造成的干扰。若所有节点都显示同样的瞬时失败，也要确认测试地址能够在当前网络直接解析。

分别验证 TCP、UDP、IPv4 与 IPv6

网页浏览主要依赖 TCP，但语音、游戏、部分 DNS 与 HTTP/3 会使用 UDP。节点能打开网页，不代表 UDP 转发一定正常。遇到网页正常而通话、游戏或 QUIC 异常时，可以临时关闭应用的 QUIC，或在规则中让相关流量改用明确支持 UDP 的节点。反过来，如果节点配置要求 UDP，但当前网络严格限制 UDP，也会出现连接质量不稳定而非完全离线。

IPv6 是另一条常见分支。域名同时返回 A 与 AAAA 记录时，系统或内核可能优先尝试 IPv6。如果本地有 IPv6 地址但出口路由不完整，连接会先等待失败再回落 IPv4，看起来像节点很慢。可临时在 Mihomo 配置中设置 ipv6: false 做对照测试。关闭后明显恢复，并不代表应永久关闭 IPv6，而是应继续检查路由器的前缀分配、默认路由和 DNS 返回。确认 IPv6 链路完整后再恢复。

最后检查设备时钟、防火墙和其他网络过滤程序。安全软件可能允许浏览器联网，却阻止 Mihomo 内核连接外部地址；企业或校园网络也可能只开放常见端口。可在允许的网络环境中做交叉验证。如果节点在两台设备、两种网络上都失败，而同配置其他节点正常，通常可以把问题收敛到该节点本身，此时应更新订阅或联系订阅提供方，而不是反复重装客户端。

03 / PROFILE

订阅导入失败、更新失败或配置为空

先确认拿到的是配置内容还是网页内容

订阅导入失败时，先不要在浏览器里反复打开链接。客户端需要的是可解析的 YAML、兼容订阅文本或由订阅服务返回的配置内容；如果地址返回登录页、错误页、验证码页或 HTML 跳转页面，HTTP 状态即使是成功，客户端也无法把它当作配置解析。查看客户端更新日志中的状态码、响应类型和解析错误，可以迅速区分“没有下载到内容”和“内容下载到了但格式不兼容”。

常见的下载层问题包括链接复制不完整、查询参数在聊天工具中被截断、订阅过期、设备时间错误、DNS 无法解析订阅域名，以及网络环境无法连接该地址。可以在不公开链接的前提下，将地址重新从服务页面复制到客户端。不要手工删除看似多余的问号、等号或参数，它们可能参与鉴权。若浏览器访问后要求登录，应回到服务页面获取专门的客户端订阅地址，而不是复制浏览器地址栏里的管理页面 URL。

区分格式错误、字段不兼容和覆盖失败

下载成功但提示 YAML 解析错误，通常要看报错行号。YAML 使用空格表达层级，Tab、冒号后缺少空格、未闭合引号和列表缩进不一致都可能导致整个配置无效。含冒号、井号或特殊符号的节点名称宜使用引号包裹。若错误指向自定义覆写内容，应暂时关闭覆写，直接导入原始订阅；原始内容能工作，说明故障位于本地覆写，而不是订阅源。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "DIRECT"

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

配置能够解析但客户端显示零节点，要判断订阅本身是否只包含规则、是否经过了不兼容的格式转换，或者节点字段被转换工具丢弃。不同客户端支持的扩展字段并不完全一致。Clash Plus、Clash Verge Rev、FlClash 与其他 Mihomo 图形客户端通常能处理常见 Mihomo 配置，但某些旧客户端无法识别新的协议字段。涉及 YAML、分享链接与其他配置格式时，可参考订阅格式转换说明，转换后重点复核代理列表、策略组引用和规则目标是否仍然存在。

更新失败时保留上一份可用配置

成熟的排错方式不是直接覆盖唯一配置，而是让旧配置和新配置并存。先给当前可用配置命名并保留，再新建一个 Profile 导入更新后的订阅。这样即使远端返回空内容或新规则不兼容，也能立即切回旧配置。关于 Profile、订阅链接与本地 config.yaml 的关系，可阅读多配置切换与管理方法。

订阅显示更新成功但节点没有变化，可能是客户端仍在使用另一个 Profile，也可能是更新后没有重新载入内核。确认当前激活配置的名称、更新时间和文件路径，再执行一次“应用”或“重新载入”。如果配置包含远程规则集或代理提供者，还要继续查看这些子资源是否更新成功；主配置下载成功，不代表其中引用的远程文件一定可达。远程文件失败时，日志通常会给出具体 URL 类型、状态码或解析错误。

网络受限时，不建议把订阅内容粘贴到来源不明的在线解析工具。需要转换时优先使用可信的开源工具或本地部署方式，并在转换结果中检查策略组是否引用了不存在的节点、规则末尾是否保留 MATCH、DNS 字段是否符合当前内核。完成修复后，先在规则模式访问一个直连站点和一个代理站点，再测试配置更新，避免只凭客户端显示“成功”判断整套配置正常。

04 / PERFORMANCE

连接成功但速度慢、网页卡顿

把吞吐、首包时间和连接稳定性分开看

“速度慢”可能指三种不同问题：大文件下载吞吐低、打开网页前等待很久，或者连接时快时慢。吞吐主要受节点带宽、线路拥塞和协议开销影响；首包慢更常见于 DNS、IPv6 回落或连接建立；波动则可能来自无线信号、自动策略组频繁切换、丢包和移动网络状态变化。先明确是哪一种，再选择测试方法。只看一次网页测速结果，很难区分这些因素。

建立基线时，先关闭其他下载、云同步和系统更新，使用同一设备、同一网络、同一测试目标，分别记录直连与代理结果。直连本身就慢，应先处理本地网络；直连稳定而所有节点都慢，检查本地到节点入口的路径、客户端接管方式和订阅线路；只有一个节点慢，则切换同策略组内其他节点。测试过程中保持模式不变，否则规则可能让不同目标走不同出口，结果无法横向比较。

检查规则是否让大流量走错策略

规则模式下，网页主体、图片、视频和下载地址可能来自不同域名。首页经代理打开，并不代表所有资源都经过同一个节点。日志中若出现资源域名命中直连、拒绝或另一个策略组，页面会表现为局部加载缓慢。可在开发者工具的网络列表中找到等待时间最长的域名，再到 Mihomo 日志里核对规则命中。修复时优先调整精确域名和域名后缀规则，不要一开始就添加范围过大的规则。

规则自上而下匹配，较宽泛的规则放在前面会遮住后面的精确规则。例如某个 DOMAIN-SUFFIX 已经匹配请求，后续针对完整域名的规则不会再执行。修改后要重新载入配置并建立新连接。若只刷新页面，浏览器可能复用旧连接，使新规则看起来没有生效。必要时关闭对应标签页，等待旧连接结束后重试。

处理 DNS、连接复用与传输方式

网页长时间停留在“正在连接”，常见原因是 DNS 查询慢或 IPv6 尝试失败。先使用本手册 DNS 章节的方法对比域名解析，再临时关闭 IPv6 验证回落问题。若日志显示频繁重复解析同一域名，应检查 DNS 缓存是否被其他软件清理，以及浏览器是否启用了独立的安全 DNS。浏览器和 Mihomo 同时使用不同解析路径时，可能出现解析结果与分流判断不一致。

部分网络对 UDP 质量不稳定，而浏览器会优先使用 HTTP/3。表现通常是某些站点首次加载很慢，刷新后又恢复。可以临时关闭浏览器 QUIC 或让相关流量回落 TCP 做对照。若回落后稳定，应进一步判断是本地网络、节点 UDP 支持还是远端路径问题，而不是长期依赖单一开关。TUN 模式也会增加一层虚拟网卡处理，低性能设备上可能影响高吞吐场景，可与系统代理模式做同条件比较。

减少本机资源和策略切换干扰

客户端界面卡顿与代理吞吐不是同一问题，但系统资源紧张会同时影响两者。观察 CPU、内存和磁盘占用，确认没有多个 Mihomo 内核实例并行运行。大量规则、频繁刷新的规则提供者和过短的健康检查间隔会增加后台工作。把自动测速间隔设置到合理范围，排查时暂时改为手动策略组，可以避免测试期间节点自动切换。

无线网络应同时检查信号强度、频段和干扰。距离路由器较远时，代理连接对丢包更敏感，网页可能反复重传。用网线或靠近接入点测试，能快速区分无线问题。移动热点则可能受到省电、信号切换和运营商网络状态影响。若同一节点在有线网络正常、无线网络慢，继续修改节点配置通常没有帮助。

最后采用逐层复原：先用手动节点、系统代理、规则模式和默认 DNS 得到稳定基线，再逐项恢复自动测速、TUN、自定义 DNS 与规则覆写。每次至少完成一次网页、文件下载和长连接测试。只有这样才能确认优化没有用一种场景的改善换来另一种场景的故障。

05 / DNS

DNS 解析失败、污染或 Fake-IP 异常

先确认错误发生在系统 DNS 还是 Mihomo DNS

DNS 负责把域名转换为地址。使用系统代理时，一部分应用可能先由操作系统解析域名，再把结果交给代理；使用 TUN 与增强 DNS 时，查询通常更多地进入 Mihomo。排查前先从日志确认请求是否出现域名、是否有 DNS 错误，以及查询由哪条路径处理。命令行中的 nslookup、dig 默认测试系统配置的解析器，不一定等同于 Mihomo 内部结果，因此命令测试与客户端日志要结合阅读。

Windows 可执行 nslookup example.com，macOS 与 Linux 可执行 dig example.com A 和 dig example.com AAAA。如果系统查询失败但 Mihomo 代理请求正常，问题可能只影响直连应用；如果系统查询正常而 Mihomo 日志报错，应检查配置里的 nameserver、proxy-server-nameserver 和出站路径。查询返回地址不代表连接一定成功，还需要确认规则使用的解析结果和实际出口一致。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1

以上是便于理解字段关系的基础示例。nameserver 用于一般查询，proxy-server-nameserver 可用于解析代理服务器域名，避免节点地址本身依赖一条尚未建立的代理链。实际配置还应根据网络环境选择可达解析器。若解析器只能通过代理访问，而代理服务器域名又需要它解析，就会形成依赖环路，表现为全部节点同时无法连接。

理解 Fake-IP 的用途和边界

Fake-IP 模式会向应用返回保留地址段中的临时地址，再由 Mihomo 根据映射关系恢复原域名。这样能让分流继续使用域名信息，也便于 TUN 接管不遵循系统代理的应用。看到 198.18.0.0/16 范围地址通常不是污染，而是该模式的正常现象。真正的问题是应用把这个临时地址长期缓存、绕过 Mihomo 直接连接，或者某些局域网服务依赖真实地址判断。

遇到打印机、局域网发现、企业内网或特定应用在 Fake-IP 下异常，可以先切换到其他增强模式做对照，再为必要域名设置过滤。过滤范围应尽量精确，避免把大量公共域名排除后失去域名分流优势。修改 Fake-IP 相关配置后，需要清理应用与系统 DNS 缓存，并重启相关连接；仅重新载入规则不一定会清除旧映射。

处理缓存、浏览器安全 DNS 和泄漏路径

系统、浏览器、Mihomo 和上游解析器都可能缓存结果。排错时应按层清理，而不是只清一处。Windows 可执行 ipconfig /flushdns；支持 systemd-resolved 的 Linux 可执行 resolvectl flush-caches；macOS 可通过重启相关解析服务或重新连接网络刷新。浏览器通常还有独立主机缓存和连接池，关闭所有浏览器进程后重开更容易得到干净结果。

浏览器安全 DNS 会直接向指定解析服务发起加密查询，可能绕过操作系统与 Mihomo 的预期路径。排查阶段可暂时使用系统解析设置，确认规则和 Fake-IP 正常后，再决定是否恢复浏览器独立解析。若必须保留，应确保该流量本身被正确分流，并理解浏览器解析结果可能与内核规则提供者采用的地址库不同。

如果问题只发生在 IPv6 域名，检查本机是否真正拥有可用的 IPv6 默认路由，而不是只获得了地址。临时设置 dns.ipv6: false 或全局 ipv6: false 可以帮助定位，但两者影响范围不同：前者主要控制 DNS 返回，后者影响更广。最终配置应与实际网络能力一致。完成修复后，用直连域名、代理域名、局域网主机和同时含 A/AAAA 记录的站点各测试一次，避免只解决单一网站。

06 / SYSTEM ROUTING

系统代理已开启，但部分应用不生效

系统代理只影响主动读取代理设置的应用

系统代理不是全局网络开关。浏览器和多数桌面应用会读取系统 HTTP/HTTPS 代理，但游戏、命令行程序、虚拟机、部分商店应用和自带网络栈的软件可能忽略它。因此“浏览器能用、某个应用不能用”通常不是节点整体故障，而是应用流量没有进入 Mihomo。先在操作该应用时观察日志：没有任何连接记录，说明需要处理应用代理、环境变量、回环限制或 TUN；有记录但失败，则回到规则、DNS和节点层。

系统代理地址一般指向本机回环地址与混合端口，例如 127.0.0.1:7890。如果客户端修改了 mixed-port，系统设置也要同步。部分客户端会自动写入系统代理，但异常退出后可能留下旧端口。此时界面显示“系统代理关闭”并不代表操作系统里的旧值已经清除，应进入系统网络设置确认。代理自动配置脚本与手动代理也不应同时指向不同入口。

按平台检查真实生效值

Windows 可在“设置”的代理页面检查手动代理，也可执行 netsh winhttp show proxy 查看 WinHTTP 配置。浏览器使用的系统代理与 WinHTTP 并非完全相同，某些服务只读取后者，因此要根据应用类型判断。Microsoft Store 与部分 UWP 应用还受本机回环限制影响，可使用客户端提供的回环工具，或按Windows UWP 回环限制处理方法进行配置。修改后应完全退出目标应用再重开。

macOS 需要在当前网络服务的代理设置中检查 HTTP、HTTPS 与 SOCKS 项。切换 Wi-Fi、网线或其他网络服务后，每个服务拥有独立配置，之前写入的代理不一定继续生效。可用 scutil --proxy 查看当前系统结果。Linux 桌面环境的代理设置只对遵循桌面配置的应用有效，命令行工具通常使用 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，大小写变量也可能被不同程序分别读取。

# 仅对当前终端会话设置示例
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 测试完成后清除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

命令行设置应与实际监听协议对应。将 HTTP 地址写到 SOCKS 参数，或反过来，会导致连接被拒绝或协议解析错误。使用 curl -I https://example.com 做基础测试时，可以加显式代理参数与不加参数各执行一次，以区分环境变量问题和本地代理入口问题。测试后清理临时变量，避免后续终端任务意外继续使用旧代理。

应用不支持代理时再考虑 TUN

TUN 适合接管不读取系统代理的流量，但它依赖虚拟网卡、路由和 DNS 配合。开启前先确保系统代理路径稳定，避免把两个问题叠在一起。开启后若只有局域网访问异常，检查私有地址规则是否走直连；若虚拟机或容器无法联网，检查其网络是否经过宿主机默认路由，以及 TUN 是否排除了对应接口。企业 VPN 与 TUN 同时工作时，双方都可能修改默认路由，需要明确哪个网络负责哪些目标。

应用已经进入日志但规则结果不符合预期时，检查进程匹配规则的支持情况。不同系统对进程名、进程路径和沙盒应用的识别能力不同，不能只依赖进程规则。域名和 IP 规则通常更容易跨平台复现。若应用使用固定 IP 或自带加密 DNS，日志里可能缺少可用于域名分流的信息，此时应结合目标地址、端口与进程规则处理。

最后检查本地防火墙是否允许应用访问回环地址，也要确认代理没有监听到错误的接口。只供本机使用时，回环监听更稳妥；需要局域网设备连接时，才启用局域网访问并设置入站规则。故障修复后，分别验证浏览器、命令行和原本失败的应用。三类入口都正常，才能说明系统代理与接管链路完整。

07 / RUNTIME

客户端崩溃、内核启动失败或反复退出

先判断是图形界面退出还是 Mihomo 内核退出

图形客户端和 Mihomo 内核是两个层次。界面卡住或退出时，内核进程可能仍在运行，系统代理也可能继续指向它；反过来，界面正常显示不代表内核已经成功启动。发生故障后先查看任务管理器或活动监视器，确认界面进程与内核进程状态，再检查本地端口是否监听。若界面退出但端口仍在，应先关闭残留进程再重启，避免第二个实例因端口占用再次失败。

启动日志通常会直接指出原因：配置解析失败、端口占用、文件权限不足、规则文件损坏、TUN 创建失败或数据库无法读取。记录第一条明确错误，而不是只截取后续连锁报错。配置解析失败时，先切回上一份可用 Profile；端口占用时查找冲突进程；权限错误则检查配置目录和缓存目录是否可写。不要为了修复一个文件权限问题直接删除整个配置目录。

建立可启动的最小配置

无法确定是配置还是客户端问题时，可以使用最小配置验证内核。最小配置只保留监听端口、模式、一个直连策略与最终规则，不加载远程规则集，也不开 TUN。它能启动，说明程序文件和基础权限通常正常，问题位于原配置的某个字段或外部资源；它仍不能启动，则继续检查安装、运行库、系统权限与端口。

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT

该配置只用于诊断本地启动与直连入口，不提供代理节点。验证完成后不要把它当作日常订阅使用。恢复原配置时，可按模块逐步加入 DNS、代理、策略组、规则提供者和 TUN。加入某一部分后重新出现错误，故障范围就被缩小。YAML 报错行有时只是解析器发现问题的位置，真正的缩进或引号错误可能位于前几行，因此要连同上下文一起检查。

处理缓存、规则文件与配置目录

规则数据库或远程资源下载中断，可能留下不完整缓存，导致内核启动时读取失败。先从日志确认具体文件，再只删除对应缓存，让客户端重新下载。大范围清空目录会同时丢失 Profile、覆写和界面设置，增加恢复成本。操作前应退出客户端并备份配置目录；如果客户端支持导出配置，优先使用导出功能。

升级或更换客户端后发生崩溃，也要考虑旧设置与新客户端不兼容。不要在 Clash Plus、Clash Verge Rev、FlClash 等不同客户端之间直接复制整个应用数据目录。更稳妥的方式是重新安装合适的客户端，再导入原始订阅或经过检查的 YAML。客户端下载应从下载页按操作系统选择，不要把另一个平台的配置目录结构当作通用格式。

处理高负载、休眠恢复和异常退出

客户端长时间运行后崩溃，应观察是否与规则更新、网络切换、休眠唤醒或大量连接同时发生。把日志级别长期设为过度详细会增加磁盘写入，日常使用通常保持 info，仅在短时诊断时提高详细程度。设备从休眠恢复后，如果虚拟网卡或默认路由没有恢复，可以先关闭再开启 TUN，而不是立刻重启系统。

若崩溃能够稳定复现，记录触发步骤、操作系统、客户端名称、使用的接管模式和错误日志。提交问题时提供最小复现配置，并删除订阅地址、节点认证和个人路径信息。无法稳定复现时，先停用自定义覆写、远程脚本和过密健康检查，观察基础配置是否稳定。通过逐项恢复找到触发条件，比反复完整重装更容易得到可复用的解决办法。

08 / MOBILE

Android 与 iOS 移动端专项排查

先处理系统对后台网络的限制

移动端代理通常通过系统 VPN 接口接管流量。客户端退到后台后断开，首要检查省电和后台运行限制，而不是节点。Android 不同厂商会额外限制后台活动，需要允许客户端后台运行、取消电池优化，并确认系统状态栏中的 VPN 标记仍然存在。部分系统还会在锁屏、清理任务或切换网络时终止后台服务，需把客户端加入受保护应用或自启动列表。

iOS 会统一管理 VPN 配置。切换 Wi-Fi 与蜂窝网络后短暂重连属于网络路径变化，但持续无法恢复时，应回到客户端重新连接，并检查系统 VPN 配置是否仍指向当前应用。若设备同时装有多个 VPN、DNS 或内容过滤应用，系统通常只能让部分网络扩展按特定顺序工作。排查阶段先关闭其他接管工具，只保留一个客户端。

分别测试 Wi-Fi、蜂窝数据和局域网

只在 Wi-Fi 失败而蜂窝数据正常，常见原因是路由器 DNS、IPv6 路由、认证门户或局域网限制。先关闭代理完成 Wi-Fi 门户认证，再重新连接客户端。只在蜂窝数据失败，则检查移动数据权限、系统省流量模式以及订阅节点在该网络下是否可达。双卡设备还要确认当前数据卡是否发生切换，网络切换后旧连接可能需要重新建立。

移动端访问打印机、电视或其他局域网设备失败时，检查局域网权限和私有地址分流。iOS 应允许客户端访问本地网络；Android 还可能需要附近设备或局域网相关权限。规则中私有地址应保持直连，避免把路由器管理页和本地服务送到远端代理。使用 Fake-IP 时，如果某个本地域名依赖路由器解析，可为该域名设置精确过滤或改用真实 IP 验证。

处理应用分流、UDP 与通知延迟

Android 客户端常提供按应用代理或绕过列表。某个应用不走代理时，确认它没有被加入绕过；只有该应用无法联网时，先关闭应用分流，让全部应用经过同一策略做对照。系统应用、工作资料和双开应用可能使用不同用户空间，普通应用列表不一定覆盖它们。修改应用范围后应停止并重新建立 VPN 连接。

语音、视频通话和游戏依赖 UDP 的比例更高。网页正常而实时通信失败，应检查节点 UDP 支持、蜂窝网络质量与规则结果。部分移动网络在 IPv4、IPv6 或 NAT 类型上与 Wi-Fi 差异明显，同一节点表现可能不同。可临时换到另一个明确支持 UDP 的节点，或让应用回落到 TCP 做对照，但不要把所有超时都归因于 UDP。

通知延迟还可能与应用自身后台策略有关。代理连接正常不代表目标应用被允许后台唤醒。先确认通知权限、后台数据和省电设置，再看 Mihomo 日志中是否有对应连接。如果锁屏后日志完全停止，重点检查客户端后台存活；如果日志存在但目标应用没有通知，则继续检查应用推送服务的规则和系统通知设置。

导入、更新与存储权限注意事项

移动端从浏览器或聊天应用打开订阅时，分享流程可能把链接交给错误应用。更稳妥的方式是在客户端内使用订阅导入入口，并确认链接完整。Android 从本地文件导入时，要允许访问所选文件；iOS 从“文件”应用导入时，应等待云端文件实际下载完成。配置更新后仍显示旧节点，检查当前激活 Profile，并手动重新载入。

移动设备存储紧张时，规则资源更新和日志写入可能失败。清理空间前先确认配置已备份，不要直接删除客户端数据。若应用频繁崩溃，可先停用复杂覆写与大型远程规则集，用最小配置验证 VPN 接口能否正常建立。需要重新选择应用时，Android 可在Android 客户端列表查看 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard；iOS 可在iOS 下载区域查看 Clash Plus。

移动端排错的最后一步是完整重建连接：断开客户端，关闭其他 VPN 或 DNS 工具，切换一次飞行模式，重新连接当前网络，再启动客户端并选择一个手动节点。依次测试浏览器、目标应用、锁屏恢复与网络切换。若浏览器始终正常而某个应用持续失败，问题已收敛到应用分流或应用自身网络策略；若所有应用随网络切换同时失败，则继续检查 VPN 重连、后台限制和节点在该网络下的可达性。