Clash 苹果版故障排查手册

无法上网：先分离直连与代理链路

结论是先退出代理链路做基线测试，而不是立刻重装。关闭客户端中的系统代理和 TUN，再退出客户端；在 iPhone 上断开对应 VPN。用浏览器访问平时能够直连的网站，并检查同一网络的另一台设备。如果两台设备都失败，优先处理无线连接、路由器或运营商网络；如果只有当前设备失败，先检查残留代理、其他 VPN 和本机 DNS。基线未恢复之前，节点测试结果没有可靠的比较意义。

建立可重复的本地网络基线

在 macOS 打开“系统设置 → 网络”，确认当前使用的是 Wi-Fi 还是以太网。酒店、机场与校园网络可能需要网页认证，连接无线网络并不等于已经获得互联网访问权限。暂时断开 VPN 后完成认证，再恢复代理。系统时间也应正确；时间偏差会导致 TLS 证书验证失败，表现为多个 HTTPS 网站同时报错，而不是简单的无线断连。

然后只启动一个代理客户端，暂不开启 TUN。确认配置已选中、内核已运行，再启用系统代理。多个应用同时写系统代理，可能把地址留给另一个已经退出的进程；多个隧道同时启用则会使路由归属更难判断。保留需要的工作 VPN，但测试时应明确记录其开关状态，不能在每轮测试中随意变化。

用显式代理测试区分入口与出口

以下命令分别绕过代理和指定本地 HTTP 代理，只读取响应头。端口 7890 是示例，必须替换为客户端实际显示的混合端口。测试目标可换成已知可访问的网站；命令成功只能说明该目标的这条路径可用，不代表所有应用、UDP 或所有规则均正常。

# macOS：忽略代理环境变量，测试直连
curl -I --noproxy '*' --connect-timeout 10 --max-time 20 https://www.apple.com/

# 显式指定客户端实际监听的混合端口
curl -I --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 20 https://www.apple.com/

如果显式代理立即提示连接被拒绝，问题通常在本地入口：内核未运行、端口填写错误或监听失败。如果等待后超时，则继续查看客户端连接记录，确认流量命中了哪个策略和节点。如果显式代理成功而浏览器失败，重点转到系统代理失效，不要在远端节点上反复试错。若直连成功、代理失败，故障范围已缩小到配置、规则与远端链路。

判断规则、DNS 与隧道分支

短暂将规则模式切为全局模式，并明确选择一个已知可用的代理节点，再访问同一目标。如果全局正常而规则模式失败，应检查目标域名的匹配规则、策略组选择及直连出口；测试结束恢复规则模式。全局模式只是改变分流策略，不会自动让不读取系统代理的应用进入客户端，也不能据此证明 TUN 已经工作。

若浏览器提示找不到服务器，先查DNS 章节；若只有开启 TUN 后失败，关闭 TUN 后复测，并检查辅助服务、默认路由和 DNS 劫持是否与其他隧道冲突。此时不要同时手改网关、清空所有网络服务或删除系统文件。先恢复到“系统代理可用”的最小状态，再逐项增加接管范围。

节点超时：区分探测失败与实际连接失败

节点延迟显示超时，不等于节点一定离线。延迟探测通常是经节点访问某个测试地址，其结果同时受测试目标、DNS、节点出口和超时设置影响。先选中该节点，用浏览器与显式代理各访问两个不同目标，再看连接日志。只有探测失败、实际网页正常时，应检查探测地址与测试方式；实际访问也失败时，才继续检查服务器连接和协议参数。

确认失败发生在哪个阶段

日志中的连接拒绝、拨号超时、证书错误与认证失败含义不同。连接拒绝通常表示目标地址可达但对应端口没有接受连接；拨号超时可能来自网络丢包、防火墙或地址不可达；认证失败指向密码、用户标识或服务端配置；证书错误要检查时间、服务器名称与信任链。保留一条完整错误及前后相关日志，避免只截取界面的“失败”二字。

先确认当前选择的是具体节点，还是自动选择、故障转移或负载均衡策略组。策略组界面显示的名称不一定是本次连接最终使用的出口。打开连接详情，查看目标、命中规则、策略链及实际节点；如果访问被规则导向直连，节点测试结果与该次请求并不是同一条路径，不能混在一起比较。

检查服务器域名与协议字段

订阅正常下载但所有节点都超时，应先看节点服务器域名能否解析，而不是直接替换全部密码。服务器域名的解析可能使用独立的 proxy-server-nameserver，它与普通网站 DNS 的路径未必相同。若解析结果包含 IPv6，而当前网络的 IPv6 路径异常，可能出现某些网络可用、某些网络长时间等待的现象；应对照记录地址族与错误后再调整。

单个节点失败时，对照订阅原始字段检查地址、端口、传输方式、TLS、SNI 与客户端内核支持情况。不要把节点 IP 直接写成 SNI，也不要为消除证书报错开启跳过证书验证。使用域名验证的协议，连接地址和证书名称可能承担不同作用；随意替换其中一个字段，会把原来的路由问题变成握手错误。

# 查看某个服务器域名的解析结果
# example.com 是示例域名，排查时改为节点的实际服务器域名
dscacheutil -q host -a name example.com

# 仅测试 TCP 端口可达性，不验证代理认证或 UDP
nc -vz -G 5 example.com 443

上述 TCP 测试成功，只说明 TCP 建连成功，不能证明代理协议认证、UDP 转发或目标网站可达；对于基于 UDP 的协议，这项测试甚至不是对应的传输验证。不要据此把服务端判定为完全正常。若命令失败，也应确认使用了真实端口，并结合当前网络是否允许该传输类型进行解释。

通过网络对照定位外部限制

保持节点与配置不变，分别用家庭 Wi-Fi 和手机热点测试。热点正常、原网络失败，说明应检查原网络的访问策略、UDP 限制或路由质量；两个网络均失败且其他节点正常，则更可能是该节点或服务端参数问题。避免连续高速探测大量节点，这可能触发服务端限制，也会制造新的连接负载，影响判断。

协议不受当前内核支持时，应通过下载页选择仍在维护、支持所需协议的客户端；苹果设备可先考虑 Clash Plus，再按场景对比其他方案。内核名称与客户端界面不是同一概念，详见Clash、Meta 与 mihomo 内核差异。替换客户端之前保留原配置，替换后只验证同一节点，避免把选型变化当作网络修复证据。

订阅失败：分别检查下载、解析与激活

订阅故障至少有三层：远程内容没有下载成功、下载内容不是有效配置、有效配置没有被激活。先看错误属于哪一层。HTTP 状态异常、连接超时和证书失败通常属于获取阶段；YAML 行号、字段类型和不支持协议属于解析阶段；更新成功但节点不变，则应检查当前配置选择、覆写规则与代理提供者缓存。反复删除订阅容易丢掉诊断线索，不应作为第一步。

下载阶段：地址、权限与更新出口

从服务提供方重新复制完整订阅地址，检查首尾空格、换行及聊天应用替换过的符号。带查询参数的地址可能包含访问凭据，不能贴到公开讨论区，也不要交给不明在线转换站。浏览器能打开服务商首页，并不能证明订阅接口权限有效；首页、登录状态与订阅下载接口往往是独立的授权路径。

状态码 401 或 403 通常需要检查授权、有效期或访问策略；404 可能是路径变更或地址失效；429 表示请求过于频繁，应等待而不是持续点击更新。若返回成功状态但正文是登录页、验证页面或错误说明，依然不能当作 YAML 导入。查看客户端提供的响应摘要即可，不要在日志中保留完整凭据。

部分客户端允许指定订阅更新走直连还是代理。初次导入时，当前代理可能尚不可用，形成“需要订阅才能连接、需要连接才能更新”的循环。可在允许的网络中用直连更新，或通过已经可用的独立连接获取配置；不要未经判断就让更新请求始终经过正在故障的节点。修改出口后只更新一次，并记录错误是否改变。

解析阶段：区分节点串与完整 YAML

通用 Base64 节点串、单个协议链接和 Clash YAML 不是同一种输入。完整配置可能包含 proxies、proxy-groups、rules 等字段，节点集合则可能需要作为代理提供者接入。应先确认导入入口接受哪种格式，再决定是否转换。相关结构见订阅格式与转换方法，不能仅凭文件后缀判断内容类型。

解析错误给出行号时，应同时检查该行及前一行：缺少冒号、使用制表符缩进、字符串引号未闭合、同层列表缩进不一致都可能使下一行报错。以下是只用于理解层级关系的本地结构示例，并不包含可连接的代理节点；不要覆盖远程完整配置后期待自动出现节点。

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手动选择

激活阶段：确认配置与覆写来源

更新成功后，应确认界面中的当前配置确实是刚更新的一份。有些客户端把下载、保存与启用分成独立操作；代理提供者也可能有自己的刷新周期。查看当前策略组成员和加载日志，而不是只看订阅卡片的更新时间。如果节点数量变化但规则没变，可能是模板或覆写机制保留了本地规则，并非远端更新失败。

远程配置通常会被下次更新覆盖，持久调整应放在客户端支持的覆写、合并或扩展配置中。排错时先停用非必要覆写，保留原文件副本，再加载原始订阅作对照。若原始配置能运行、合并后报错，逐项恢复覆写定位冲突；不要同时修改远端文件和本地模板，否则难以确认最终生效内容。

速度慢：把延迟、吞吐与应用行为分开测

低延迟不保证大文件下载快，高延迟也不一定意味着吞吐低。网页体验还受 DNS、握手次数、资源数量与目标服务限制影响。排查前先描述症状：是首次打开慢、持续下载慢、视频缓冲，还是仅某个应用卡顿。保持同一设备、同一网络、同一目标与相近时间比较，避免把不同测速站、不同内容分发线路的结果直接排序。

建立最小测试矩阵

先在关闭代理的状态访问可直连目标，确认本地 Wi-Fi 和宽带没有明显瓶颈。再固定一个节点，对比同一目标的显式代理与正常浏览器访问；接着只替换节点，重复相同操作。如果所有节点都慢而直连正常，检查客户端接管方式及本地负载；如果只有一个节点慢，重点检查节点出口和目标之间的线路，而不是调整整个系统网络。

同时查看“活动监视器”的 CPU、内存与网络页。后台同步、系统更新和云盘上传可能占满上行，进而拖慢网页确认包；这类情况并不一定表现为下载带宽满载。暂停已确认的大流量任务后复测即可，不要结束无法识别的系统进程。诊断日志也不宜长期保持最详细等级，高频写盘会增加负担并积累敏感连接信息。

识别 DNS、握手与下载阶段

可用下列命令输出 DNS、TCP、TLS 与总耗时作为线索。通过 HTTP 代理时，部分字段描述的是到本地代理的过程，目标域名解析可能由代理完成，因此不能把 time_namelookup 当作完整远端 DNS 耗时。应结合客户端日志判断卡在哪一段，而不是仅根据一项数值下结论。

curl --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nfirst=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.apple.com/

如果 TLS 很快、首字节等待长，目标服务器响应与出口路径值得进一步检查；如果连接阶段反复重试，考虑丢包、地址族与节点连通性。单个小请求不能代表持续吞吐，测速文件也可能被服务端限速。不要为了得到更漂亮的数字频繁并发下载，这会消耗订阅流量，还可能触发目标服务限制。

处理 UDP、MTU 与架构差异

视频、会议与游戏可能使用 UDP 或 QUIC，而浏览器普通 HTTPS 测试未覆盖这些路径。确认应用流量是否进入 TUN、节点是否支持所需转发，以及当前网络是否限制 UDP。若应用有受支持的传输回退选项，可临时对照；不应把关闭所有 UDP 当作通用优化，因为这会改变应用行为，甚至导致通话无法建立。

MTU 不匹配可能造成小请求成功、大传输停顿，但它不是所有慢速问题的答案。仅当切换网络、日志及传输现象均支持这一判断时，才在支持该设置的 TUN 配置中小步调整，记录原值并逐次测试。Apple 芯片 Mac 应优先使用 arm64 构建以减少转译变量，不过换架构不能提升远端线路容量；选型差异可查阅横向评测。

最终应留下能复现的结论，例如“同一目标在热点正常、家庭网络持续停顿”，而不是“所有节点都不快”。前者能指导检查路由器、网络策略或路径问题；后者仍混合了节点、目标与时间等多个变量。调整完成后恢复日常日志等级，再用真实工作应用验证，不以单次测速作为结束标准。

DNS 问题：检查解析链、fake-ip 与泄漏边界

DNS 排查先回答三个问题：谁发起查询、查询交给哪个解析器、结果由谁用于连接。系统 DNS、浏览器安全 DNS、客户端内置 DNS 和节点服务器域名解析可能同时存在。网页打不开不一定是解析失败，DNS 测试页面显示某个地区也不一定证明请求绕过了预期路径。应先检查目标域名能否解析，再关联客户端连接记录与实际出口。

区分系统解析和客户端解析

macOS 可用 scutil --dns 查看解析器及作用范围。输出中可能包含默认、接口限定与 VPN 提供的解析器，不能只读取第一项就判断全部域名的去向。公司内网域名可能依赖分域解析，随意把所有 DNS 改成公共解析器会破坏内部资源访问。浏览器若启用独立安全 DNS，也可能不走同一条系统解析路径。

# 查看 macOS 当前解析器及作用范围
scutil --dns

# 通过系统接口查询示例域名
dscacheutil -q host -a name www.apple.com

# 仅在修改配置后需要清理旧缓存时执行
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清缓存只能移除旧结果，不能修复错误的上游或路由。dig 等工具适合查询指定解析器，但默认行为不一定等同于 macOS 应用使用的完整系统解析链。看到命令行与浏览器结果不同，应先确认查询路径与缓存，不要直接判断其中一个工具失效。使用加密 DNS 时，也要确认解析器域名本身有可用的引导解析路径。

理解 fake-ip 的接管条件

mihomo 的 fake-ip 模式可向应用返回映射地址，再由内核把连接关联回域名。这些地址不是目标服务器真实地址，看到它们本身不表示 DNS 被污染。关键在于后续连接是否仍由同一个内核接管；若应用缓存了映射地址而客户端已退出，或系统 DNS 指向客户端但监听服务停止，就可能出现断开代理后仍无法访问的情况。

# mihomo DNS 片段示例；不是完整订阅配置
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

该示例仅在本机回环地址监听，且选用的上游必须在当前网络可达。普通系统 DNS 设置通常不能直接填写 1053 这样的自定义端口；只启用这个监听，不会自动让所有系统查询进入它。需要由客户端提供的 DNS 接管、TUN 劫持或其他明确配置连接起来。图形客户端还可能覆写相关字段，应以实际加载配置与启动日志为准。

按症状选择修复分支

如果只有局域网设备名、打印机或公司域名失败，应检查本地发现、分域解析和 fake-ip 过滤策略，而不是把全部域名加入直连。仅将已确认不兼容的域名加入客户端支持的过滤列表，并保留内部 DNS 路径。若节点域名也无法解析，先修复节点引导解析；不能依赖尚未连接成功的节点去解析它自身的服务器地址。

如果代理连接正常但外部检测显示了意外解析器，先关闭浏览器独立 DNS 做一次对照，再查看 TUN DNS 接管范围、IPv6 和绕过规则。DNS 查询走直连与业务连接走代理是两个独立决定，是否符合需求应按实际隐私边界判断。某个检测站只覆盖它设计的查询方式，不能据此保证其他应用的所有 DNS 都已被接管。

修复后至少验证普通域名、此前失败的域名和必要的内网域名，再断开并重连一次客户端，确认系统解析器能正确恢复。长期运行时应选择一种可解释的 DNS 方案，避免系统、浏览器、路由器与客户端同时设置互相依赖的转发链。需要修改 TUN 接管方式时，结合macOS TUN 授权说明检查实现路径。

系统代理不生效：确认设置、监听与应用入口

macOS 的系统代理是供应用读取的网络设置，不是全设备强制转发。浏览器可能遵循它，命令行、游戏或带独立网络栈的应用则未必遵循。先用显式代理确认客户端入口可用，再检查系统设置是否写入当前网络服务；如果入口正常而某个应用仍直连，应检查该应用的代理机制，必要时再考虑 TUN，而不是反复切换系统代理开关。

确认设置写入了当前网络服务

打开“系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理”，检查网页代理与安全网页代理的主机和端口。不同 macOS 界面文字可能略有差异，但应始终检查正在联网的服务；Wi-Fi 中的代理不会自然等于以太网的设置。切换扩展坞、热点或网络位置之后，旧服务的配置可能仍在，但当前流量已经走了另一项服务。

# 查看当前代理设置摘要
scutil --proxy

# 列出网络服务，供对照系统设置中的名称
networksetup -listallnetworkservices

# 查看本机示例端口是否有 TCP 监听
lsof -nP -iTCP:7890 -sTCP:LISTEN

输出中的 HTTP、HTTPS、SOCKS 和自动代理配置可能分别启用。手动代理与 PAC 同时存在时，应确认应用实际采用哪一种，而不是默认手动设置必然覆盖自动配置。由组织管理的设备还可能受描述文件约束；此时应遵循组织网络要求，不宜强行删除管理配置。客户端不能写入代理时，日志通常比开关外观更能说明权限问题。

核对监听地址与混合端口

监听主机通常使用 127.0.0.1，端口取自客户端实际配置。不要把外部节点服务器端口填写成系统代理端口，也不要混用控制接口端口。端口被另一个进程占用时，内核可能启动失败，或者系统代理指向了错误应用；结合监听命令中的进程名称确认归属，再通过相应应用正常退出，不要直接结束未知进程。

以下最小片段说明本地代理入口，不包含远端节点。mixed-port 同时接受 HTTP 与 SOCKS 代理协议；它不等同于 DNS 端口，也不代表外部网站应直接访问这个端口。图形客户端若提供独立的端口设置，应先在那里调整，避免生成配置与手动编辑相互覆盖。

mixed-port: 7890
allow-lan: false
mode: rule

处理应用独立代理与终端环境

终端程序可能读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY 等环境变量，也可能只接受自己的参数。检查时不要把带密码的变量值贴到公开日志。临时命令参数更适合诊断，因为作用范围明确；确认有效后，再按工具文档设置持久代理。注意 HTTPS_PROXY 对应的代理入口仍可能使用 http://127.0.0.1:7890。

浏览器扩展、应用内部代理与系统代理可能相互覆盖。先关闭扩展代理，用新窗口复测；必要时完全退出应用后重新打开，避免旧连接继续复用。应用连接已经建立后才切换规则或节点，不一定立即改变已有连接的出口。诊断时应新建请求，并通过连接记录确认，而不是只刷新一个长期保持连接的页面。

当应用确实不支持系统代理时，可以使用客户端提供的 TUN 接管，但要先确认辅助服务已安装、授权正常且没有其他隧道冲突。不同客户端可能采用辅助服务或系统提供的网络机制，不能一律要求安装同一种扩展。退出客户端之后应检查代理设置是否恢复；若网络断开，先关闭残留代理，再按本章重新核对入口，不要把恢复动作变成永久关闭安全功能。

客户端崩溃：区分界面退出、内核停止与系统拦截

窗口消失、内核停止和系统拒绝启动是三类问题。界面退出后内核可能仍在运行；内核崩溃时界面也可能继续显示旧状态。先记录具体发生时机：启动即退出、导入配置后退出、开启 TUN 后退出，还是休眠唤醒后失效。不要立即删除整个数据目录，配置、日志与崩溃报告是判断触发条件的关键资料，重装应用本身也未必会清除这些状态。

确认架构、来源与系统提示

Apple 芯片 Mac 优先选择 arm64 或 Apple Silicon 构建，Intel Mac 选择 x86_64；可在“关于本机”确认芯片类型。Universal 构建可能包含两种架构，应以应用说明为准。通过macOS 下载入口重新选择安装包，避免在多个旧副本之间交替启动。客户端选择可先考虑 Clash Plus，其他客户端应结合系统要求和维护状态比较。

系统提示应用损坏、开发者验证或权限受限时，先核对下载来源和客户端发布说明，不要直接执行关闭系统安全机制的命令。企业设备还可能受应用执行策略约束。安装包架构不匹配、系统版本不满足要求和安全拦截，都可能表现为无法启动，但解决方向不同；需要保留原始提示文字，而非统称为“闪退”。

先收集证据，再做最小化启动

在 macOS“控制台”中查看崩溃报告，或通过客户端的日志入口导出与故障时间相符的片段。关注报告对应的是图形界面、mihomo 进程还是辅助服务。记录触发步骤和最近一次变更，如新增覆写、切换内核、修改 DNS 或启用 TUN。日志可能包含域名、服务器和订阅信息，分享前逐项脱敏，不应把完整用户目录打包发送。

保留配置副本后，先关闭自动启动、自动连接和 TUN，使用最小配置启动，再逐步恢复订阅与覆写。如果最小配置正常、原配置导致退出，应缩小到具体字段或规则集合；如果尚未加载配置就退出，则优先检查应用本体、运行环境与系统报告。客户端若提供安全模式或恢复设置入口，应先使用受支持方式，不要猜测数据目录名称。

检查辅助服务与资源异常

只有开启 TUN 才失败时，检查辅助服务是否属于当前安装的客户端、是否在升级后需要修复，以及其他 VPN 是否抢占路由。普通用户不应手动替换系统扩展文件或降低系统启动安全级别。通过客户端提供的安装、修复或卸载服务入口操作；若界面要求的权限与发布说明不一致，应暂停并核实来源，而不是持续授权重试。

长时间运行后退出，还应观察内存压力、日志体积及连接数量趋势。大量规则提供者频繁刷新、异常重连或详细日志持续写入都可能增加负载。先减少诊断之外的变量：恢复普通日志等级，暂停非必要的刷新，再复现同一工作负载。不要用清空所有规则或关闭证书验证来掩盖问题，否则即使界面不再退出，也失去了原来的安全与分流边界。

Clash for Windows 与 ClashX Meta 属于归档选择，遇到新系统兼容问题时，应优先评估仍在维护的替代客户端，不要把旧配置原样覆盖到新应用。不同客户端的配置合并、辅助服务和存储方式可能不同。先导入最小可用订阅，再迁移规则与偏好；这样可以把原配置问题与新客户端兼容性分开识别。

如果仍能稳定复现，应整理系统与架构、客户端名称、触发步骤、最小配置和脱敏日志，通过项目或应用公开支持入口反馈。不要编造版本信息，也不要用“最新版”替代界面显示的真实标识。恢复后再开启自动连接，并测试一次正常退出和重启，确认不会留下失效的系统代理或不可用的后台服务。

移动端专项：iPhone、iPad 与 Android 网络切换

移动端先看系统 VPN 状态与应用内连接状态是否一致，再检查当前网络是 Wi-Fi 还是蜂窝数据。iOS 的代理应用通过系统允许的网络扩展机制工作，不能照搬 macOS 的辅助服务和终端命令。iPhone 与 iPad 可先选择 Clash Plus，商店与官网入口见iOS 客户端；配置格式、可用规则与功能开关应以应用自身支持情况为准。

iOS 已连接但不能访问

先在应用内断开连接，再到“设置 → 通用 → VPN 与设备管理”检查是否存在其他活动 VPN。多个应用安装的配置可以共存，但同一时刻的隧道与按需连接策略可能互相影响。暂时停用另一个应用的自动连接后复测；不要删除组织下发的配置。首次连接时若尚未完成系统 VPN 添加授权，应用内的准备状态也不代表系统隧道已建立。

若只在蜂窝网络失败，检查“设置 → 蜂窝网络”中该应用的数据权限，以及当前套餐和系统数据模式；若只在某个 Wi-Fi 失败，先断开 VPN 完成门户认证。网络切换后旧连接可能仍绑定原接口，重新连接客户端并新建请求通常比反复刷新旧页面更能验证恢复情况。记录切换前后结果，避免同时换节点导致对照失效。

iOS 后台机制与桌面不同，应用界面不在前台不代表网络扩展一定停止，也不能把卡片从多任务界面移除当成可靠的服务重启流程。应使用应用内连接开关，并在系统设置中确认实际状态。设备发热或耗电异常时，查看是否有持续重连、配置频繁更新或其他大流量应用，不要只因状态栏显示 VPN 就判断是代理本身导致。

本地网络、隐私功能与分流边界

访问打印机、电视或局域网服务失败时，检查相关应用的“本地网络”权限与客户端的局域网绕过规则。通过 IP 访问和通过设备名称发现可能走不同机制，前者成功并不保证组播发现正常。应分别测试，保留必要的本地解析和路由；不要为修复一个设备把全部私有网络流量强制送往远端出口。

iCloud 私密转送及“限制 IP 地址跟踪”等系统隐私功能可能改变部分流量的路径，但不等同于通用代理隧道。若怀疑冲突，可记录原状态后暂时关闭相关选项做对照，测试完成恢复；不能把它们当作所有连接故障的原因。诊断重点仍是应用请求是否进入当前客户端、命中哪条规则，以及目标使用了哪个出口。

Android 与跨设备配置差异

Android 可按下载页顺序选择 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。后台连接中断时，检查系统电池管理、后台数据权限和应用自身 VPN 设置，不同厂商的路径可能不同。私人 DNS、其他 VPN 及始终开启的 VPN 策略也需要记录。只在锁屏后失败，应优先复现后台限制，而不是先修改所有节点协议。

Mac、iPhone 与 iPad 共用订阅，并不表示应共用全部运行参数。桌面监听端口、控制接口、文件路径和辅助服务字段不应机械复制到手机。建议共享节点与必要规则，把平台运行选项留在各客户端本地；同步设计可参考苹果设备配置同步方案。导入后必须检查实际加载结果，不能只看到订阅名称一致就认定行为一致。

仍无法解决时，先建立一份最小复现记录：设备系统、当前网络、客户端、选中策略、失败目标及大致时间，再附脱敏错误摘要。不要急于重置全部网络设置，因为这会清除其他连接配置并扩大恢复成本。若需要重新走一遍安装与连接流程，返回快速上手；若只剩特定域名或节点异常，按本页对应章节继续，而不是从头重装所有设备。