Clash 故障排查
连接与配置诊断

无法上网：确认流量在哪一层中断

先恢复对照环境，再判断故障范围

先关闭客户端的系统代理和 TUN，再退出其他 VPN 或代理程序。打开一个平时可以直连的网站，确认本机 Wi-Fi、网线或蜂窝网络正常。如果关闭后仍无法连接，优先检查路由器、网络认证和系统残留代理，不要继续换节点。公共网络可能要求先打开认证页面；代理启动过早会让认证请求绕路，表现为所有网站同时失效。

基础网络正常后重新启动客户端，确认配置已选中、内核已运行、代理组有可用成员。界面显示“已连接”可能只表示本地服务启动，并不证明远端代理可达。先用规则模式访问同一个网站，再检查连接列表是否出现该请求。列表没有记录时，重点查流量入口；出现记录但连接失败时，继续查策略、节点和解析结果。

用显式代理请求区分入口与出口

确认设置中实际的混合端口，再执行下面的测试。示例使用本机端口 7890；若配置不同，需要把命令中的端口改成实际值。Windows 请使用 curl.exe，避免旧版 PowerShell 中同名命令的行为差异。测试目标也可换成当前打不开的网站，只做一两次请求，不用并发压测。

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

报 Connection refused 通常说明目标端口没有监听，或端口填错；连接本地代理成功后才超时，则可能是出口节点、规则或远端网络问题。收到 HTTP 状态码说明已经完成一部分网络链路，但还要核对状态来自目标网站还是中间服务。证书错误应单独处理，不能用关闭证书验证的方式掩盖原因。

检查模式、代理组与规则顺序

规则模式按配置中的顺序匹配，命中后使用对应策略。若某网站被提前写入 REJECT，换节点不会改变拒绝结果；若代理组当前选中 DIRECT，界面上的代理开关也不会让该连接自动走远端。查看连接详情中的规则和最终链路，比仅观察总开关可靠。自定义规则的策略名称必须与已有代理组完全一致。

可以短暂切到全局模式作对照，并明确选中一个已验证的节点。如果全局可用而规则模式不可用，优先查规则命中、代理组嵌套和直连解析。如果两种模式都失败，继续检查本地入口与节点本身。对照结束后恢复规则模式，避免全局转发改变局域网、办公系统或流量计费行为。

修复后建立可重复的验证

不要把页面偶然刷新成功当成修复完成。关闭原有连接或重启测试应用，依次验证一个直连网站、一个需要代理的网站和一个局域网地址；检查连接列表是否符合预期。浏览器可能复用旧连接，切换策略后新旧请求走不同路径。确认结果稳定后保存配置，并记录有效端口、模式与所选代理组。

节点超时：分开看探测失败与业务失败

先确认超时来自哪一种测试

节点列表中的超时一般来自客户端发起的探测请求，不等于所有业务连接都失败。探测地址不可达、被目标限制或返回条件不符合预期，都可能让可用节点显示异常。先选中该节点访问实际目标，同时查看日志。如果网页可用而探测失败，应核对测试地址和超时设置，而不是直接删除节点或认定订阅失效。

如果实际访问也失败，比较同一代理组内的其他节点。全部失败通常指向基础网络、账户状态、统一配置或本地拦截；只有一个节点失败，更可能是节点端点、协议参数或对应线路异常。不要一次测试整个列表，以免大量并发连接触发限制。选两个不同端点做顺序测试，已经足以建立初步判断。

依据日志区分连接、握手和解析

dial tcp 后跟超时，通常表示 TCP 连接阶段没有及时建立；connection refused 表示连接被主动拒绝，可能是端口不开放或服务未运行；握手失败则说明已经进入协议或 TLS 阶段。找出错误中的目标是节点服务器还是网站服务器，两者对应的排查方向不同，不能只截取最后一个“timeout”。

节点端点使用域名时，先确认该域名能够解析。解析失败会让所有依赖它的连接提前停止；解析到错误地址则可能表现为握手失败。TLS 类协议还要核对系统时间、服务器名称和订阅提供的参数。不要随意删除 servername 或修改指纹、传输路径；这些字段通常需要与服务端一致，猜测修改会增加变量。

判断协议是否适合当前网络

某些网络会限制 UDP。若 TCP 类节点可以使用，而依赖 UDP 的协议持续失败，可切换网络复测，区分本地网络限制与服务端异常。Hysteria2、TUIC 等协议的表现不能直接用普通 TCP 端口测试解释；反过来，端口能够建立 TCP 连接，也不能证明代理协议的认证和转发已成功。

办公网络、校园网络和公共 Wi-Fi 可能有明确的访问策略。排查时遵循网络管理要求，不绕过组织限制。可在允许的家庭网络或蜂窝网络中对照同一节点：若只在某个网络失败，把时间、协议类型和错误阶段记下来，有助于服务提供方判断。不要为了测试把本地代理监听开放给整个局域网。

排查代理组中的实际选择

手动选择组、自动测速组和故障转移组有不同逻辑。界面选中的是上层组时，实际出口可能来自另一层自动组；上层显示的名称并不一定是最终节点。展开连接链路，确认哪个成员承担了请求。自动选择结果也可能受探测缓存影响，刷新测试后仍要用一次实际请求验证，不以单个颜色或标签作结论。

检查服务状态和流量额度。账户过期、节点迁移或并发连接数受限，都可能让参数格式正确的节点无法工作。先更新订阅，再对照服务方公布的状态；不要在公开讨论中贴完整节点 URI。节点密码、UUID 和订阅链接都可能授予访问权限，应像账户凭据一样处理。

修复动作与回退边界

优先动作是更新有效订阅、选择已验证节点、恢复服务方提供的原始参数，再切换网络复测。证书错误不能靠长期设置 skip-cert-verify 解决；先检查时间和服务器名称，再由服务方处理证书问题。临时提高超时只适合判断慢响应，不能修复认证失败、域名错误或已关闭的端口。

若只有自动探测异常，可以调整测试地址后重测，但要使用稳定、允许访问的目标。验证时记录“探测是否成功”和“业务是否成功”两项结果。关于延迟、流量倍率和地区的取舍，可继续阅读Clash 节点选择说明；低延迟不代表带宽充足，节点可用也不代表所有网站都接受该出口。

订阅失败：先区分请求失败与配置解析失败

确认导入对象与错误发生位置

订阅更新有两个阶段：先从地址取得响应，再由客户端或内核解析内容。连接超时、证书失败和 HTTP 状态异常属于请求阶段；获取成功后出现 YAML 错误、未知字段或代理组引用错误属于解析阶段。首先完整阅读错误提示，确认是哪一步失败。仅重复点击更新通常不会改变链接过期或格式不兼容的问题。

检查粘贴内容是否包含首尾空格、换行或中文标点。应导入服务方提供的订阅地址，而不是账户后台网页地址、付款页面或节点管理页面。链接中的查询参数可能包含访问凭据，复制时缺少后半段会变成另一个请求。不要在公共终端运行带完整订阅链接的命令，也不要把它贴进截图或公开日志。

按 HTTP 结果判断下一步

状态码只能作为方向，具体含义以服务方实现为准。认证失败或禁止访问可能与凭据、账户状态和请求策略有关；找不到资源可能是地址已变化；请求过多应暂停更新。即使返回成功状态，内容也可能是登录页、维护页或错误说明，而不是配置。浏览器能打开地址，不代表客户端会收到同一份内容。

避免更新路径形成启动依赖

部分订阅地址需要通过代理才能访问。如果当前代理节点恰好失效，更新请求又依赖它，就会出现无法获得新节点的循环。查看客户端是否提供通过代理更新的选项；在网络允许的情况下对照直连更新，或先用保留的可用配置建立连接。不要把无法访问的订阅地址不断转换成不同链接，这会掩盖真正的路径问题。

某些服务按 User-Agent 返回不同格式。优先使用服务后台对应 Clash 或 mihomo 的导入入口，遵循其客户端要求。随机伪装请求头可能拿到适合其他客户端的内容。将私密订阅提交给陌生在线转换服务也会扩大凭据暴露范围；需要转换时，先确认工具来源和数据处理方式。

定位 YAML 与内核兼容性错误

YAML 使用空格缩进，不要混入制表符。错误行号有时指向解析器最终无法继续的位置，真正原因可能在上一行的引号、冒号或列表缩进。先检查报错行前后几行，再检查顶层结构。下面只是合法的规则片段，不是可独立连接的完整配置；其中代理策略名称必须对应现有配置中的组名。

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

如果 YAML 语法正常，但提示不支持某协议或某字段，确认实际运行的内核。客户端名称、界面版本与内核能力不是同一个概念，旧内核可能无法使用 mihomo 扩展语法。不要单纯删除报错字段让配置勉强加载；它可能是协议所需参数。可阅读mihomo 与原版内核差异了解兼容边界。

保护本地修改并完成更新验证

远程订阅更新可能覆盖直接编辑的内容。客户端若支持覆写、合并或本地规则，应把自定义项放在对应层，而不是改下载缓存。更新后检查节点列表、代理组成员和规则是否仍符合预期，再选一个节点完成实际连接。订阅文件加载成功只表示解析通过，不表示远端节点全部在线。

若新配置失败而旧配置仍可用，先恢复旧副本，保留新的错误记录再处理。不要一次清空所有配置和缓存，避免失去对照。更多分支见订阅更新失败自查清单；修复后降低不必要的自动更新频率，确认重启客户端仍能加载同一份有效配置。

速度慢：按节点、线路与本机三层定位

建立同条件对照，避免混用指标

网页打开慢、视频缓冲和文件下载慢不一定是同一个问题。先记录具体目标、时间段和操作：是首个页面等待长，还是开始下载后吞吐持续偏低。测试期间暂停其他下载、云同步和系统更新，保持设备位置与网络一致。跨时段、跨网站的结果不能直接拿来比较，否则无法判断变化来自节点还是目标服务。

延迟测试主要反映探测请求的往返与处理时间，不是带宽测量。延迟较低的节点仍可能拥塞，带宽较高的节点也可能因跨地域往返而打开网页较慢。选择两个不同线路的节点，访问同一个允许测试的目标，分别观察首响应和持续传输。避免反复进行大流量测试，订阅流量会按服务方规则消耗。

先查节点负载和网络线路

只有一个节点慢，而其他节点和直连正常，优先检查该节点线路或负载。如果晚间变慢、其他时段恢复，可能与共享出口和运营商路径拥塞有关。切换同地区另一线路比只换相邻地区更有诊断价值。地区标签不能保证物理线路、出口地址或目标内容服务相同，应以实际连接结果为依据。

全部节点慢时，用关闭代理后的普通网络访问作基线。若直连下载也慢，检查 Wi-Fi 信号、频段、路由器负载与接入网络；有条件时用网线对照。若仅某个网站慢，可能是其内容分发路径、限速或出口识别策略。换一个目标可帮助排除本机通用问题，但不能据此保证原目标一定可用。

区分 DNS 等待与传输瓶颈

首次打开慢、再次打开明显变快，可能与 DNS、TLS 握手或缓存有关。查看日志是否在解析阶段长时间等待，检查域名是否频繁重试。下载已经建立后持续慢，则更应关注线路吞吐、丢包和服务端限制。不要看到速度问题就更换所有 DNS；解析器变化还可能改变内容分发地址，使对照条件不再一致。

可以通过一次显式代理请求记录时间，不用安装额外工具。下面命令输出总时间与首字节时间，数值由真实请求产生。经过 HTTP 代理时，域名解析可能发生在代理内核或远端，不能把这些结果当作独立的 DNS 测试；它们只用于比较同样请求在不同节点上的表现。

curl --proxy http://127.0.0.1:7890 --max-time 30 -o /dev/null -sS \
  -w '首字节: %{time_starttransfer}s\n总时间: %{time_total}s\n' \
  https://example.com

Windows 使用 curl.exe，把输出目标 /dev/null 换成 NUL，并将命令写成一行。测试返回很小的页面，主要观察响应等待，不用于判断大文件带宽。如果首字节正常而特定下载始终慢，继续检查目标限速、下载工具并发设置和代理规则是否命中同一出口。

检查本机接管与资源占用

比较系统代理与 TUN，但不要同时改协议、DNS 和代理组。若仅 TUN 模式慢，检查是否同时运行其他 VPN、虚拟网卡工具或安全软件，以及日志是否重复处理同一连接。任务管理器中的高 CPU 或持续磁盘写入也可能影响网络体验；短期调试日志结束后恢复正常日志级别，避免长时间大量写入。

大量连接、小文件并发和后台同步会增加内核与设备负担。先关闭不相关应用，再重复原来的单一任务。路由器或低功耗设备上，协议加密和连接规模可能受处理能力限制。不要直接照搬桌面电脑的高并发设置，也不要把所有安全防护永久关闭作为提速方法；应通过进程、规则和时间对照定位冲突。

处理 MTU 与分流边界

若小请求正常、大页面或长连接容易卡住，尤其只在 TUN 或某个网络下出现，可考虑 MTU、路径丢包或 UDP 处理问题。先用另一网络和另一协议复测，得到稳定差异后再小幅调整支持的 MTU 设置，并保留原值。没有适用于所有设备的通用最优数字，盲目降低可能增加开销而不解决问题。

最后核对慢请求的规则命中。有些下载实际直连，有些媒体请求被分配到不同代理组，不能把全部体验归因于当前手选节点。恢复临时设置后重测同一目标，并在相近时间再验证一次。分层记录方式可参考Clash 网速慢的分层诊断，避免把短暂波动当成永久故障。

DNS 问题：检查解析路径与 Fake-IP 映射

先认清系统解析与内核解析的区别

浏览器、安全软件、操作系统和代理内核都可能参与解析。同一域名在终端中能解析，不代表应用会使用同一个结果；应用开启加密 DNS 后，也可能绕过系统解析器。先记录失败域名、错误信息和当前接管模式。若日志中没有对应解析请求，应先查应用解析路径，而不是立即替换内核中的所有 DNS 配置。

用系统工具查询可以建立基线，但要理解测试范围。nslookup 通常向系统指定的 DNS 服务器发出查询；它不能完整模拟浏览器的加密 DNS，也不一定经过当前 HTTP 代理。查看返回的服务器与地址，再和客户端日志对照。若域名能解析却连接失败，继续查路由、规则、TLS 或目标服务，避免混淆层次。

nslookup example.com

理解 Fake-IP 的正常表现

Fake-IP 使用映射地址把域名与连接关联起来，便于内核按域名匹配规则。开启后看到映射范围内的地址不一定是错误，也不能用普通直连方式验证该地址是否是真实服务器。应用拿到映射地址后，连接应继续被同一内核接管；如果只接管解析、不接管后续连接，映射地址就可能被送到错误路径。

切换增强模式、重启内核或更换配置后，应用可能仍缓存旧映射。先关闭相关应用，按平台支持的方式清理缓存，再重新建立请求。Windows 可以清理系统 DNS 缓存，但浏览器和应用可能还有独立缓存，需要重启或在其网络设置中处理。不要反复切换模式却保留全部旧连接，这会让新旧映射混在一起。

ipconfig /flushdns

针对兼容性问题设置过滤

局域网设备发现、某些游戏和依赖真实地址的应用可能需要例外。优先为明确受影响的域名配置 fake-ip-filter，不要将所有域名都排除。下面片段展示映射范围和局域网后缀过滤，不包含上游解析器，不能单独替换完整 DNS 配置。修改前核对当前内核支持的过滤语法。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

私有 DNS 与企业内部域名往往需要组织提供的解析器。公共解析器不能替代内部 DNS，改成公共服务后反而可能让办公系统失效。记录故障是否只发生在公司网络，确认域名后缀与 VPN 的解析要求。局域网发现还可能依赖 mDNS 或广播，单纯添加域名过滤不保证能够恢复所有设备发现功能。

排查上游与节点域名的启动依赖

加密 DNS 上游自身也可能使用域名，其地址需要先被解析；节点服务器域名同样需要在代理建立前获得有效结果。如果解析节点域名又依赖尚未建立的代理，就可能形成循环。mihomo 的 default-nameserver、proxy-server-nameserver 等配置承担不同职责，先确认当前内核语义，再有针对性地调整。

启用按规则处理 DNS 请求时，也要检查解析器连接最终走向。不要同时增加多个互相引用的策略，再期待内核自行解决依赖。日志如果反复查询同一上游域名、却没有完成连接，应优先检查启动解析路径。上游超时则需要对照当前网络是否允许访问，而不是只看服务器名称是否常见。

定位 DNS 泄漏与解析结果异常

DNS 泄漏指解析请求走了非预期路径，不等于“结果里出现本地运营商名称”。网页测试只能提供线索，可能受缓存、浏览器加密 DNS、IPv6 和测试服务观察方式影响。结合系统 DNS 设置、客户端查询日志和应用设置，确定请求由谁发出、通过哪条链路出去，再判断是否偏离设计。

IPv6 开启时应同时检查 AAAA 记录和 IPv6 路由。仅处理 IPv4 代理入口，不代表 IPv6 请求也被接管；反过来，直接关闭 IPv6 也可能影响原本正常的网络。先对照同一域名的地址类型与连接结果，按平台配置完整接管或明确直连策略。概念解释可查Fake-IP 术语条目。

系统代理不生效：核对入口、端口与 TUN 路由

系统代理并不接管所有应用

系统代理是操作系统提供给应用的一组代理设置，是否使用取决于应用实现。部分浏览器会读取它，部分命令行工具、游戏和自带网络栈的程序不会。若浏览器可用而某个应用不可用，先检查该应用是否有独立代理选项，不要仅根据系统代理开关认定内核异常。需要覆盖更多流量时才评估 TUN。

先执行显式代理请求。如果显式请求正常，而依赖系统设置的请求失败，说明本地代理服务和部分出口链路可用，故障更可能位于系统设置或应用入口。若显式请求也无法连接，则检查监听端口、内核启动和配置加载。界面开关与操作系统实际值可能短暂不同，尤其在异常退出或多程序抢占时。

检查端口与监听地址

mixed-port 同时提供 HTTP 与 SOCKS 入口，port 和 socks-port 则分别配置。不要把外部控制接口端口误填为代理端口，它用于管理内核，不用于转发普通请求。设置变化后确认内核已重新加载；旧进程未退出时，也可能继续占用原端口，造成界面显示与实际监听不一致。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info

这是本机使用的基础片段，需合并到已有配置。只在本机访问时保留回环监听，不必开放局域网。allow-lan 影响其他设备能否访问，并不是修复本机系统代理的必需开关。若出现端口占用，用系统工具查对应进程，再决定调整端口或停止冲突程序，不要随意结束未知系统服务。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

核对平台设置与命令行环境

Windows 中用户代理设置与 WinHTTP 代理属于不同入口，读取其中一套的程序可能不受另一套影响。macOS 的代理设置绑定网络服务，切换 Wi-Fi、网线或新建服务后要检查当前服务。Linux 桌面代理设置与终端环境变量也可能分离。排查时确认目标应用读哪一层，不要把不同接口当作同一个开关。

命令行工具通常需要显式参数或环境变量。下面变量仅影响当前终端及其后续启动的子进程，不会修改所有应用。已有终端或后台服务可能仍保留旧值；NO_PROXY 中的例外也可能让目标绕过代理。用于域名远端解析的 SOCKS 地址可采用 socks5h，是否支持取决于工具。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

TUN 的权限、路由与排除项

TUN 通过虚拟网络接口接管流量，需要相应权限和路由配置。客户端可能通过服务模式或系统授权完成这些操作，仅在界面中打开开关不代表路由安装成功。先看日志是否有权限、网卡或路由错误，再检查实际接口。企业设备可能限制虚拟网卡，应遵循设备管理规则，不强行绕过限制。

切换 TUN 前关闭其他 VPN，并保存系统代理状态。启动后验证普通应用、命令行和局域网是否正常；若办公网段失效，检查自动路由与排除范围。将整个私有地址范围排除未必适合每个网络，可能影响本来需要通过 VPN 到达的资源。应按实际拓扑配置，不复制与当前环境无关的网段列表。

异常退出后的恢复与验证

客户端退出后无法上网，常见原因是系统仍指向已停止的本地端口。先在系统网络设置中恢复原代理状态，再确认应用能直连。TUN 残留则需通过客户端正常关闭、恢复网络服务或重启设备处理，避免手动删除未知路由。开机自启时还要检查启动顺序，网络尚未就绪可能让首次连接失败。

需要常驻服务的 Linux 环境可参考mihomo 与 systemd 部署说明。修复完成后退出并重启客户端一次，确认监听端口、代理设置和路由均能正确恢复；最后检查停止代理后的网络也正常，形成完整的启停闭环。

客户端崩溃：区分界面、内核与系统服务

先判断退出的是哪一部分

窗口消失不一定意味着内核停止，托盘图标存在也不一定意味着内核正常。检查客户端日志和系统进程，区分界面闪退、内核退出、后台服务启动失败。界面问题通常影响操作和显示；内核问题直接影响代理监听；服务问题可能只影响 TUN 或特权功能。记录发生在启动、导入配置还是开启某项功能之后。

优先通过正常退出结束残留进程，再启动一次。多个实例可能竞争配置文件、控制接口或代理端口，让第二个实例看起来像崩溃。若后台仍在运行，不要同时安装另一客户端并开启同样的接管功能。先确认旧实例是否退出，再复测，避免把进程竞争当作软件兼容性问题。

用配置对照判断是否由新修改触发

崩溃发生在更新订阅或编辑配置之后时，先恢复上一份能启动的副本。如果旧配置正常、新配置失败，检查语法、规则集加载、协议兼容和文件路径。某些客户端会在界面中提示配置错误，而内核已经拒绝启动；这不是必须重装才能解决的故障。保留报错行号与附近结构，隐藏节点凭据后再分析。

命令行部署的 mihomo 可以用测试模式检查配置，下面命令不会替代完整运行验证。程序名称和路径应按安装位置调整，Windows 可能需要调用 mihomo.exe。GUI 客户端也可能提供内置检查功能，应优先使用它，避免另一个内核读取同一配置目录造成干扰。

mihomo -t -f ./config.yaml

如果纯规则配置可以加载，而加入某个规则集后失败，检查规则集路径、格式和下载结果。相对路径通常与配置目录有关，不能假设工作目录永远相同。把一次新增内容分批恢复，找出具体触发项，比清空全部文件有效。切勿删除所有配置后再发现订阅地址与本地覆写没有备份。

检查架构、系统支持与权限

下载时区分系统平台与处理器架构。Apple Silicon、Intel 和 ARM 设备可能需要不同包；运行错误可能来自架构不匹配、系统组件缺失或系统版本不受支持。先到下载中心核对对应包与要求，不凭文件名相似就替换。新安装优先考虑 Clash Plus，再依据平台需求选择其他客户端。

配置目录无法写入、磁盘空间不足或日志目录权限异常，也可能让启动失败。检查当前用户是否能读写客户端自己的数据目录，不把整个系统目录改成所有用户可写。Linux 服务运行用户与交互登录用户可能不同，配置在终端中可读，并不代表 systemd 服务也能读取；要按实际服务身份核对权限。

安全软件与资源问题要用证据处理

安全软件可能拦截虚拟网卡、后台服务或程序启动。先查看隔离记录与系统通知，核对被阻止的文件和动作；不要长期关闭整套防护。企业设备由管理员管理时，应提供日志申请确认。若仅 TUN 开启后退出，重点检查网卡与特权服务；若窗口一打开就失败，则优先查图形组件和用户数据。

内存或 CPU 持续升高时，检查是否启用了过于详细的日志、加载了过大的规则集或存在连接循环。资源上涨只是现象，需要和连接数量、日志内容及触发操作关联。先恢复普通日志级别，关闭重复接管程序，再观察是否改善。对低内存设备，减少不必要的配置规模往往比继续增大缓存更合理。

有边界地重置与迁移

重置应先备份，再只移动疑似损坏的用户状态或缓存文件，让客户端重建。优先使用界面提供的重置功能，并阅读它会删除哪些内容。远程订阅、本地规则、代理组选择和系统服务配置不是同一份数据；迁移到其他客户端时，也不能假设所有界面偏好都能跟随 YAML 自动转移。

Clash for Windows 与 ClashX Meta 属于已停止维护的客户端，遇到新的系统兼容问题时应考虑迁移到维护中的方案。迁移前导出配置和自定义项，按下载页的平台顺序选型；先验证基本代理，再恢复 TUN 与启动设置。不要把旧客户端和新客户端同时设为开机接管网络。

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

从 VPN 授权与配置加载开始

移动端通常通过系统 VPN 接口接管流量。首次连接需要完成系统授权，订阅导入成功并不等于授权已完成。先确认配置选中、代理组有可用成员，再开启连接，观察系统是否显示 VPN 状态和客户端是否出现连接记录。若授权被拒绝或由设备管理限制，先解决系统层问题，不重复导入同一订阅。

同一设备上的其他 VPN、工作配置、安全过滤和某些广告过滤工具可能竞争接管能力。测试时保留一套网络接管工具，关闭其他同类服务再试。浏览器扩展类过滤不一定与 VPN 冲突，应按实际实现区分。设备受组织管理时，遵循管理策略，不通过删除管理配置来强行启动代理。

Android 后台与省电限制

Android 上锁屏后断开、回到应用后恢复，常与后台限制有关。检查客户端通知是否持续存在，以及系统是否限制其后台活动；按设备提供的电池设置允许必要后台运行。各厂商入口不同，不照搬另一品牌菜单。调整后要锁屏等待、解锁访问并检查日志，而不是只观察前台开关。

“始终开启 VPN”和“无 VPN 时阻止连接”会改变断线后的行为。若启用了阻止连接，客户端停止后整机断网可能是系统策略的正常结果。排查时先了解该选项，再决定是否暂时关闭做对照；诊断结束后恢复原本需要的保护策略。不要把系统主动阻止流量误判为 DNS 或节点全部损坏。

Android 客户端还可能提供按应用代理或绕过列表。若只有某个应用没有日志，检查它是否被排除，尤其是工作资料中的同名应用。启用绕过后，该应用的行为不能用代理组解释。Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的界面和配置支持不同，迁移时逐项核对功能，不直接复制全部偏好。

iOS 连接与客户端选择

iOS 使用 Clash Plus 时，先按系统提示添加 VPN 配置，再导入有效订阅并选择策略。系统 VPN 状态说明接管通道存在，但仍需要通过实际请求验证出口。更换配置后如果旧请求仍失败，可关闭测试应用再重新打开，避免连接复用干扰。遇到工作设备限制时，先确认是否允许添加个人 VPN。

客户端选择与安装入口见iOS 下载说明，Clash Plus 官网为 clashplus.io。若应用内配置失败，分别记录导入错误和连接错误，不把两类问题混合处理。账号、订阅服务和客户端是不同环节，应用安装完成不会自动提供可用节点。

Wi-Fi、蜂窝与热点分开验证

在 Wi-Fi 正常、蜂窝失败时，检查客户端蜂窝数据权限、系统数据限制和服务方是否限制来源网络。反过来只有 Wi-Fi 失败，则检查门户认证、路由器 DNS、网络协议限制和该网络的管理要求。保持同一节点、同一目标，分别记录两个网络结果，能够缩小问题范围；不要切网络的同时又换配置。

Wi-Fi 与蜂窝切换可能改变本地地址、IPv6 状态和 NAT 映射，已有连接不一定能继续使用。切换后等待系统网络稳定，重新发起请求；若反复无法恢复，再关闭并开启客户端连接，查看是否重新建立出口。只有切换瞬间失败与切换后持续失败是不同现象，应分别记录。

手机开启热点不代表下游设备自动通过手机 VPN。是否转发取决于操作系统和实现方式，不能用手机自身网页可用来证明电脑已走代理。下游设备应独立验证出口；需要共享代理时，先确认客户端支持的局域网入口和网络隔离设置，并限制访问范围，避免在公共热点上开放代理端口。

局域网与修复验收

投屏、打印、局域网管理和游戏发现可能依赖直连、广播或本地解析。若开启代理后这些功能失效，检查绕过局域网、路由和 Fake-IP 例外；不要仅为恢复投屏把全部流量改成直连。先定位具体应用和目标地址，再添加必要例外。局域网发现与公网网页访问要分别验收。

最后进行四项验证：前台访问、锁屏后恢复、Wi-Fi 与蜂窝切换、客户端停止后的网络行为。确认自定义规则不会被订阅更新覆盖，并保留一份可用配置。常见概念可查帮助中心；若是首次安装或迁移，回到快速上手教程重新建立基础链路，再恢复后台、分应用与局域网设置。