先确认客户端与故障层
合盖后先等 Wi-Fi 或以太网重新连上，再判断代理。按“物理网络 → 代理入口 → TUN 数据链路 → DNS → 第二个 VPN”的顺序检查，每次只改一项；菜单图标显示已连接，不代表路由、代理和 DNS 都已恢复。
先在“关于”中确认产品名和版本。若使用 ClashFX，本文以 1.1.11 为基线：发布说明和对应源码记录了等待网络就绪后的唤醒检查、Mihomo API 与 TUN 接口验证、数据面探测及有界恢复；源码也有系统代理恢复逻辑。这些修复针对已知客户端故障，不会修复 Wi-Fi 未恢复、节点不可用、门户拦截或 VPN 路由冲突。ClashX Pro 历史安装包内部版本为 1.118.0.1，已停更；标准版 ClashX 1.140.0 是另一条发行线，版本号不能互相替代。
第一步：确认唤醒后的物理网络
先打开一个平时可直连的网页，确认 Wi-Fi 已关联到正确网络、以太网已接通，并留意是否需要重新登录酒店或办公网门户。以下命令只读取当前状态：
networksetup -listallnetworkservices
scutil --dns
scutil --proxy在网络服务列表中认出当前使用的 Wi-Fi 或以太网；名称前的星号表示该服务已停用。若系统本身尚未联网，先用 macOS 的网络界面恢复连接，再排代理。不要先改 DNS、路由或网卡配置。
第二步：查系统代理是否指向失效端口
系统代理模式依赖应用使用 macOS 代理设置。查看 scutil --proxy 中 HTTP、HTTPS、SOCKS 的启用状态、地址和端口；若地址是 127.0.0.1，记下端口，并与 ClashFX 当前设置里的 HTTP 或 mixed port 对照。下面以 7890 为例，按实际端口替换：
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --connect-timeout 5 --max-time 15 -sS -o /dev/null -w 'HTTP %{http_code}\n' --proxy http://127.0.0.1:7890 --noproxy '' https://www.apple.com/
curl --connect-timeout 5 --max-time 15 -sS -o /dev/null -w 'HTTP %{http_code}\n' --proxy '' --noproxy '*' https://www.apple.com/两条 curl 使用同一 HTTPS 网址：第一条明确连本机代理，第二条让 curl 不使用显式代理。若系统代理指向某端口但 lsof 没有监听，常见原因是代理尚未启动或设置残留旧端口；若显式代理测试成功而浏览器失败，优先核对 macOS 代理状态、浏览器代理/PAC 与例外列表。监听存在只说明端口有人接听，不保证上游可用；连接拒绝通常指向端口/服务，超时还可能是路由、节点或 DNS。HTTP 4xx/5xx 也不等于传输层失败。
重要： --noproxy '*' 只跳过 curl 的显式代理设置，不能绕过活动 TUN。比较显式代理与真正直连前，请先在 Clash 客户端界面暂时暂停 TUN，保持暂停直至两条测试完成，再恢复原模式；否则所谓直连仍可能被 TUN 接管。
| 现象 | 优先判断 |
|---|---|
| 本机代理连接被拒绝 | 端口填错、核心未监听或唤醒后尚未启动 |
| 代理 curl 成功，应用失败 | 系统代理未应用、PAC/例外规则或应用不读取系统代理 |
| 两条都超时 | 先排物理网络；若 TUN 开着，第二条仍可能走 TUN |
Apple 的 scutil 手册说明 --proxy 会报告当前系统代理，--dns 会报告当前 DNS 配置。
第三步：区分 TUN 控制面与数据面
TUN/增强模式工作在系统网络路径上，scutil --proxy 看不到它是否正常。回到客户端状态页确认增强模式仍开启、核心/API 有响应，并查看唤醒时段的日志是否出现 TUN 接口缺失、接口已关闭、bad file descriptor 或 socket operation on non-socket。界面/API 正常但流量停住，仍可能是 TUN 数据面失效。
ClashFX 1.1.11 的发布记录说明：唤醒或网络变化后会同时校验 Mihomo API 和实际 TUN 接口；接口消失或显示禁用时，会重建增强模式。运行时检查还会比较 DIRECT 出站和 DNS，并在确认核心故障后有限恢复，不会把系统网络不可用直接当作核心故障。可在网络已稳定后，用客户端界面将增强模式关闭、等待状态更新，再开启一次；每次只切换一个模式。依据：1.1.11 发布说明与健康检查源码。若只某个应用失败，也检查该应用是否支持系统代理及配置规则是否将目标送往 DIRECT。
第四步：排查 DNS 与 Fake-IP 缓存不一致
scutil --dns 可查看默认和按域名匹配的 supplemental resolver；重点看唤醒后使用的 nameserver、搜索域和接口范围是否符合当前网络。可把下列结果当作比较线索，而不是所有应用的最终结论：
dig +time=2 +tries=1 www.apple.com
dscacheutil -q host -a name www.apple.comdig 的查询路径不等同于每个应用调用 macOS 系统解析器的路径，也不能单独证明 TUN 内 DNS 劫持、分流或应用缓存正常。若配置启用 Fake-IP，198.18.0.0/16 内的答案可能是代理核心生成的合成地址，不是网站真实公网 IP；Mihomo 文档列有 fake-ip 与该地址池设置。睡眠前的应用缓存、唤醒后的系统 resolver 以及核心 Fake-IP 映射若暂时不同步，可能造成“部分域名或旧连接失败”。
若只有特定域名或某个 App 出错，对比 dig 与系统查询，并先用客户端界面的“重载配置/重启核心”或可用的 DNS 开关做一次可恢复验证；记下原设置，确认无效后恢复。不要据一次 dig 结果就改全局 DNS 或清空所有网络设置。参考 Mihomo DNS 配置文档。
第五步：排除第二个 VPN 或网络扩展冲突
企业 VPN、其他代理客户端、安全软件网络扩展和 Clash 的 TUN 可能同时改路由、DNS 或默认网卡。用 networksetup -listallnetworkservices 识别相关服务，再在各自应用界面查看是否已连接；列表只能说明服务存在，不能单独证明隧道正在接管流量。网络已经恢复后，暂时断开另一个 VPN，只保留一个负责路由的隧道，再按同一网址复测。若问题随第二条隧道断开而消失，优先检查两者的分流、DNS 与自动连接设置；不要删除 VPN 配置或同时重置多项设置。
五分钟复测与提交诊断
- 等 Wi-Fi/以太网和登录门户就绪，确认不启用代理时的基础网络状态。
- 在
scutil --proxy核对回环地址与端口；用lsof看端口是否监听，再跑显式代理 curl。若端口不匹配，只从客户端界面关闭再开启系统代理。 - 若使用 TUN，在客户端确认接口/核心状态；网络稳定后只做一次增强模式关闭再开启。记住 curl 的
--noproxy不能绕过活动 TUN。 - 仅域名异常时，看
scutil --dns、dig和系统查询差异；通过客户端 UI 重载 DNS/核心后复测。 - 仍失败时，断开第二个 VPN 单独对照，并保存唤醒时段的脱敏日志。
提交给维护者时附上 macOS 版本、客户端准确名称/版本、活动模式、唤醒时间及时区、网络服务类型、两条 curl 的成功/错误类别、监听端口是否存在和相关日志片段。分享前检查诊断包：删除订阅链接、访问令牌、密码、节点地址或身份信息，以及本机用户名、主机名、IP/MAC。即使客户端提供脱敏报告，也先人工复核。不要把关闭 IPv6、执行 sudo killall、批量重置网络或绕过 Gatekeeper 当作通用唤醒修复。
常见问题
怎么判断是系统代理断了还是 TUN 断了？
scutil --proxy 只能确认系统代理设置；本机代理端口是否监听可用 lsof 检查。TUN 需看客户端的增强模式与接口状态，API 在线不代表数据路径正常。
curl 加 --noproxy '*' 后就是直连测试吗？
它只让 curl 不使用显式 HTTP/SOCKS 代理；活动 TUN 仍可能接管这条连接。要对照物理直连，需先从客户端 UI 暂时关闭 TUN。
dig 能解析，为什么浏览器仍然打不开？
dig 不一定经过浏览器使用的系统 resolver、域名分流、Fake-IP 或应用缓存路径。继续比对 scutil --dns 与系统查询，并检查客户端 DNS/TUN 状态。
升级到 ClashFX 1.1.11 就能解决所有唤醒断网吗？
不能保证。该版记录了特定的睡眠唤醒、TUN 接口和系统代理恢复改进；底层网络、节点、DNS 配置或另一个 VPN 的故障仍需分别处理。
资料来源与适用范围
资料核对日期：2026-10-04。版本功能以文中标注的稳定版或官方资料为准；网络排查需在自己的配置与环境中验证。