Clash 显示“已连接”，通常只表示 iOS 网络扩展、TUN 接口或本地代理已经启动。这个状态不能证明订阅仍然有效，也不能证明当前策略组选择了可用节点。请求还要依次经过 DNS 解析、规则匹配、策略组和远端节点，其中任意一层失败，都可能表现为 Safari 一直加载、应用提示网络错误，或者只有部分网站打不开。
排查时不要连续修改多个设置。先记录当前配置名称和策略模式，每完成一步就用同一个网页复测。推荐先打开 Safari 访问 http://captive.apple.com/hotspot-detect.html，正常响应通常会显示“Success”；再访问一个常用 HTTPS 网站。HTTP 与 HTTPS 分开测试，可以初步区分网络入口、DNS、TLS 和代理线路问题。
第一步：确认问题只在 Clash 开启后出现
做一次关闭与开启对照
- 保持当前 Wi-Fi 或蜂窝网络不变，关闭 Clash 的代理开关。
- 在 Safari 打开两个此前失败的网站，并刷新一次。
- 重新开启 Clash，等待状态稳定 5 秒，再访问相同地址。
- 记录是“关闭后正常、开启后失败”，还是两种状态都失败。
如果关闭 Clash 后仍然无法访问，故障多半位于本地网络、运营商连接或网站本身。先检查飞行模式、Wi-Fi 登录页和蜂窝数据权限。公共 Wi-Fi 经常要求先完成认证；此时可暂时关闭 Clash，访问任意 HTTP 页面触发登录页，认证完成后再打开代理。
如果关闭后正常、开启后立即失败，继续按本文顺序检查。若只有某个应用失败，则进入 iOS 的「设置」→「蜂窝网络」，确认该应用和 Clash 客户端具有蜂窝数据权限。还要留意应用是否仅在 Wi-Fi 下工作，以及当前 Wi-Fi 是否启用了需要重新认证的门户。
| 对照结果 | 优先检查 | 暂不处理 |
|---|---|---|
| 关闭与开启都失败 | Wi-Fi 认证、蜂窝数据、系统网络 | 规则与策略组 |
| 关闭正常，开启失败 | 节点、规则、DNS、VPN 状态 | 路由器重置 |
| 网页正常，单个应用失败 | 应用权限、规则命中、UDP 支持 | 整份配置删除 |
| 域名失败，部分 IP 可达 | DNS 配置与劫持 | 频繁切换节点 |
第二步：检查订阅是否有效并完整更新
订阅能显示在客户端里，不代表订阅地址仍可读取。服务到期、订阅链接失效、服务器返回登录页面，或者更新过程中网络中断，都可能让客户端继续保留旧配置。旧节点全部失效时，界面依然可以显示策略组和“已连接”，但实际连接会超时。
核对更新时间与更新结果
- 进入客户端的配置或订阅页面，确认当前启用的是预期配置，而不是较早导入的本地副本。
- 查看最后更新时间。若订阅方已经更换节点，而本地更新时间停留在数天前，应手动更新一次。
- 更新后确认策略组仍包含节点。只有组名、没有可选节点，通常说明订阅内容为空或解析失败。
- 出现 HTTP
401或403时，检查订阅权限与地址；出现404时，通常需要重新取得订阅链接；出现5xx时，等待服务端恢复后再试。
更新订阅前不要先删除旧配置。更稳妥的顺序是保留旧配置，新建一个配置槽导入更新后的地址，确认可以正常加载后再切换。这样即使新订阅返回了不兼容字段，也可以快速退回原配置查看差异。
第三步：确认策略组确实选择了可用节点
Clash 配置常见的策略组类型包括 select、url-test、fallback 和 load-balance。其中 select 需要手动选择；自动测试组则依赖测试地址、测试间隔和节点可达性。组内显示节点名称，只说明配置已载入，不代表节点握手成功。
先用手动选择排除自动测试干扰
- 打开策略组页面，找到规则最终引用的主代理组，例如“节点选择”或“PROXY”。
- 不要只在二级地区组里切换。确认最外层主组没有停在
DIRECT、REJECT或已失效的自动组。 - 手动选择一个明确的单节点，连续测试两到三个不同地区的节点。
- 每次切换后等待 3 至 5 秒，再重新打开网页，避免复用旧连接造成误判。
延迟测试只能说明测试 URL 在当时可达。显示 80 ms 的节点仍可能无法访问目标网站，也可能缺少 UDP、TLS 握手异常或出口被限制。相反，测试超时也可能是测试地址被拦截，而节点本身仍可访问其他站点。因此应同时看真实网页结果和连接日志，不能只看延迟数字。
识别常见连接错误
| 日志或现象 | 常见原因 | 处理动作 |
|---|---|---|
i/o timeout |
节点地址不可达、端口被阻断或线路超时 | 切换节点，并在 Wi-Fi 与蜂窝网络间对照 |
connection refused |
远端端口未监听或节点已经下线 | 更新订阅，停用该节点 |
TLS handshake timeout |
线路丢包、SNI 或服务端 TLS 异常 | 换节点，检查系统时间 |
| 测速正常但网页超时 | 规则走错策略组或目标站限制出口 | 查看该请求的规则命中记录 |
第四步：检查模式与规则命中
规则模式下，请求从上到下匹配，命中后不会继续检查后面的规则。一条范围过大的 DOMAIN-SUFFIX、IP-CIDR 或 GEOIP 规则，可能让目标请求进入错误的策略组。最后的 MATCH 或 FINAL 也必须指向真实存在且可用的组。
用全局模式做短时对照
将模式从“规则”临时切换到“全局”，并让全局策略选择一个已确认可用的节点。如果网页恢复，说明节点和基础代理链路大致正常，问题集中在规则命中或策略组引用。如果全局模式仍然失败，应回到节点、DNS 或系统 VPN 层继续排查。
全局模式只用于定位，不适合作为最终修复。确认原因后切回规则模式，打开连接记录，找到失败域名对应的策略与规则。例如日志显示请求命中 DIRECT，但当前网络无法直连该目标，就需要调整规则顺序或更换规则集；若命中一个空策略组，则应修正配置中的组名引用。
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY上面的规则会先让 example.com 及其子域名进入 PROXY，再让符合 GEOIP CN 的目标直连，其余请求进入 PROXY。如果把宽泛的直连规则放在目标域名规则之前，后面的规则可能永远没有机会命中。
第五步：区分 DNS 故障与代理故障
DNS 故障的典型表现是域名打不开、应用提示找不到服务器，但已有连接或少数使用固定地址的服务仍然工作。Clash Meta（mihomo）常见的增强模式为 fake-ip 与 redir-host。在 iOS 的 TUN 或网络扩展环境里，DNS 请求还可能受到系统加密 DNS、其他 VPN 配置和局域网劫持影响。
先看日志里有没有解析错误
no such host通常指向域名解析失败。context deadline exceeded可能是上游 DNS 超时，也可能是上游请求必须经过一个不可用的代理组。- 只有局域网域名失败时，检查是否需要由路由器 DNS 解析，例如
192.168.1.1。 - 切换网络后恢复，通常说明原 Wi-Fi 的 DNS、认证状态或 UDP 传输存在限制。
如果客户端提供「设置」→「参数设置」→「DNS」一类入口，先记录当前值，再检查 DNS 是否启用、增强模式是否与配置匹配、上游地址格式是否完整。不同客户端菜单名称会有差异；当配置由订阅管理时，优先修改独立副本，避免下一次订阅更新覆盖本地调整。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8
fallback:
- tls://1.1.1.1:8531053 是示例监听端口，不应与其他本地 DNS 服务冲突。传统 DNS 常用 UDP 或 TCP 53 端口，DNS over TLS 常用 853 端口。不要在不了解订阅结构时同时改动 nameserver、fallback、proxy-server-nameserver 和 fake IP 范围；先替换一个可达的上游并复测，才能知道是哪项变化生效。
若 iPhone 安装了独立的加密 DNS 描述文件，可前往「设置」→「通用」→「VPN 与设备管理」查看。排查期间可暂时停用其他 DNS 或 VPN 配置，只保留当前 Clash 网络扩展。测试完成后再恢复原设置。
第六步：检查 iOS VPN 与 TUN 状态
iOS 同一时间通常只允许一个主要 VPN 隧道接管流量。企业 VPN、其他代理客户端、内容过滤器或安全软件可能与 Clash 的网络扩展冲突。状态栏出现 VPN 标记，只能证明某个 VPN 配置处于活动状态，不能据此确定当前生效的是哪一个配置。
在系统设置中核对当前配置
- 打开「设置」→「通用」→「VPN 与设备管理」→「VPN」。
- 确认当前连接项属于正在使用的 Clash 客户端。
- 断开其他 VPN，关闭其他代理客户端的按需连接。
- 返回 Clash，先关闭代理，等待 5 秒，再重新开启。
- 若仍卡在连接状态，重启 iPhone 后只启动 Clash，不要同时打开其他网络工具。
使用 TUN 模式时，客户端需要建立虚拟网络接口并接管相应流量。配置中的路由排除项过宽，可能让请求绕过 TUN；过窄则可能影响局域网设备访问。若只有打印机、NAS 或路由器管理页打不开，检查是否保留了局域网地址直连，例如 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。
若问题只发生在蜂窝网络，进入「设置」→「蜂窝网络」，确认 Clash 客户端可使用蜂窝数据。双卡设备还应确认当前数据线路已经正常注册。切换 SIM 数据线路后，先断开再重建 VPN，让网络扩展取得新的默认路由。
第七步：用日志把故障定位到具体一层
完成前面的对照后，日志通常能把问题缩小到一个明确阶段。打开客户端的连接或日志页面，清空旧记录，然后只访问一个测试域名。记录时间、域名、命中规则、策略组、节点名称和最终错误。不要同时打开多个应用，否则后台请求会迅速淹没目标记录。
按请求阶段读取日志
- 没有任何请求记录：流量可能没有进入 Clash。检查 VPN 配置、TUN 状态和应用网络权限。
- 有域名但无法解析：检查 DNS 上游、加密 DNS 配置和 DNS 相关日志。
- 已经显示规则命中：核对命中的策略组是否符合预期。
- 已经选择节点但连接超时：切换节点与网络，判断是节点失效还是当前线路阻断。
- TCP 建立后出现 TLS 错误：检查系统时间、目标域名、节点线路与证书提示，不要直接接受来源不明的证书。
如果客户端支持日志级别，排查时可暂时从 info 调到 debug，复现一次后立即调回。持续使用 debug 会产生大量记录，也会让真正关键的错误更难筛选。提交问题时，隐藏订阅地址、认证信息、节点密码和个人域名，只保留错误类型与必要上下文。
最终清单：按结果决定下一步
- 关闭 Clash 也无法上网：先处理 Wi-Fi 登录、蜂窝权限或系统网络。
- 订阅更新报错：核对订阅权限、返回内容和配置格式。
- 手动节点可用、自动组不可用：检查测试 URL、组类型与测试间隔。
- 全局模式可用、规则模式不可用：查看请求命中并调整规则顺序。
- 域名失败且日志出现解析超时：检查 DNS 上游与系统加密 DNS。
- 日志没有请求：检查 iOS 当前 VPN 配置和 TUN 是否真正接管流量。
- Wi-Fi 失败、蜂窝正常：检查公共网络认证、路由器 DNS 与端口限制。
- 所有节点都连接超时：更新订阅，并向节点服务提供方确认线路状态。
最有效的排查顺序是先做关闭与开启对照，再验证订阅和节点，然后检查规则、DNS，最后处理系统 VPN。每一步只改变一个变量，并用相同网站复测。这样可以避免把节点故障误判成 DNS 问题，也不会因为一次性重置全部设置而失去可复现的线索。