先判断“已连接”具体代表哪一层
Clash 客户端里的“系统代理已开启”“VPN 已连接”或“内核运行中”，只说明本地代理入口已经启动，不等于远端节点可用，也不等于浏览器流量已经进入 Clash。完整链路至少包含应用、系统代理或 TUN、mihomo 内核、规则匹配、DNS、代理节点和目标网站七个环节。任何一层中断，界面开关都可能继续显示为开启。
排查时不要同时修改节点、DNS、规则和 TUN。一次只处理一层，并在每一步保留可复现的测试结果。推荐准备三个目标：一个本地路由器地址、一个可直连网站和一个需要经过代理策略的网站。这样可以快速判断问题位于本地网络、直连链路还是代理链路。
用四个现象缩小范围
| 现象 | 优先检查 | 常见断点 |
|---|---|---|
| 所有网站都打不开 | 本地端口、系统代理、TUN | 代理端口未监听或流量被错误接管 |
| 直连网站能打开，代理网站失败 | 节点、订阅、策略组 | 节点失效、策略组选中 DIRECT |
| IP 地址能访问，域名打不开 | DNS | 解析超时、DNS 劫持或 Fake-IP 链路不完整 |
| 浏览器可用，其他应用失败 | TUN、应用代理支持 | 应用不读取系统代理，或 UDP 未被接管 |
第一步：确认节点、订阅与策略组确实可用
先进入客户端的代理或策略页面，找到当前实际承担流量的策略组。很多配置的顶层组名是“节点选择”“Proxy”或“GLOBAL”，下面还会套一层自动选择、故障转移或地区分组。首页显示某个节点名称，不代表最终出口一定是它；应逐层打开策略组，确认链路中没有误选 DIRECT、REJECT 或一个已经失效的子策略组。
不要只看延迟数字
延迟测试通常访问配置中的测试 URL。显示 80 ms 或 200 ms，只能说明该测试在当时得到响应。目标站连接仍可能因 TLS 握手、线路拥塞、服务端限流或 UDP 支持差异而失败。排查时手动选择一个已知稳定节点，连续访问两个不同域名，再观察连接日志。
- 延迟显示“超时”：先切换另外两个不同地区的节点，排除单节点故障。
- 所有节点同时超时：检查本机基础网络、订阅有效期和节点服务器域名解析。
- 延迟正常但网页失败：继续查看策略匹配、DNS 和 TLS 错误，不要反复测速。
- 只有 UDP 应用失败：节点协议或服务端可能没有提供可用 UDP 转发，也可能是 TUN 配置未接管 UDP。
重新拉取订阅并核对更新时间
订阅过期不一定表现为“导入失败”。客户端可能继续保留旧配置，界面仍能显示节点列表。进入「配置」→「订阅」或「Profiles」页面，手动执行更新，记录更新后的时间和返回信息。若状态码是 401 或 403，应检查订阅权限；若是超时，先用直连网络打开订阅域名；若返回内容无法解析，则可能拿到了登录页、提示页或格式不兼容的文本。
更新后确认当前激活的是新配置，而不是列表中同名的旧副本。部分桌面客户端需要在配置列表中再次点击启用。若配置使用 provider，还应检查 provider 的更新时间，因为主配置更新成功不代表远程节点集合也同步成功。
第二步：检查本地代理端口和系统代理
桌面端最常见的断点是：内核监听在一个端口，操作系统或浏览器却指向另一个端口。常见配置会使用 HTTP 端口 7890、SOCKS5 端口 7891，或者只启用一个 mixed-port，例如 7890。端口号并非固定标准，必须以当前配置和客户端设置页显示的值为准。
先绕过浏览器，直接测试本地端口
在 Windows PowerShell、macOS 终端或 Linux shell 中，可以用 curl 指定代理。下面假设 mixed-port 为 7890：
curl -I --max-time 10 -x http://127.0.0.1:7890 https://example.com
curl -I --max-time 10 --proxy socks5h://127.0.0.1:7891 https://example.com如果返回 HTTP 响应头，说明应用到本地代理、代理到目标站的基本链路已经连通。若立即出现“Connection refused”，通常是端口未监听或写错；等待 10 秒后超时，则继续查看节点和 DNS；如果 HTTP 代理成功而 SOCKS5 失败，核对配置是否确实启用了 socks-port。
一次本地代理请求在网络正常时通常会在 0.2 至 3 秒内返回响应头。这个范围不是节点质量标准，但若每次都稳定卡到 10 秒超时，就应查看内核日志，而不是继续等待浏览器自行恢复。
核对系统里的实际代理地址
- Windows 11 24H2：打开「设置」→「网络和 Internet」→「代理」，检查“使用代理服务器”的地址和端口。常见地址是 127.0.0.1，端口应与客户端一致。
- macOS 15：打开「系统设置」→「网络」→ 当前网络 →「详细信息」→「代理」，检查网页代理与安全网页代理。客户端自动管理时，不要再手动填写另一组端口。
- Android 15：Clash 类客户端通常通过系统 VPN 接口接管流量，不需要在 Wi-Fi 的手动代理里再填写 127.0.0.1。
- 浏览器：确认没有同时启用代理扩展。扩展指向旧端口时，会覆盖或绕开系统代理。
如果关闭系统代理后可以正常直连，开启后所有请求立即失败，说明断点大概率位于本地代理端口之后。此时查看日志中是否出现连接拒绝、握手超时或找不到策略组。若关闭系统代理后仍无法访问任何网站，应先修复 Wi-Fi、网线、网关或系统 DNS，而不是继续调整 Clash。
第三步：把 DNS 问题从代理问题中分离出来
“IP 能通、域名不通”是典型 DNS 线索。Clash Meta，也就是当前常见的 mihomo 内核，可以在本地执行域名解析、规则匹配和 Fake-IP 映射。客户端只要漏掉 DNS 劫持、上游解析不可达或 Fake-IP 流量接管中的一环，就可能出现浏览器一直转圈、部分应用提示网络不可用的情况。
先看域名是否能得到答案
在终端执行系统解析测试。Windows 可用 nslookup example.com，macOS 和 Linux 可用 dig example.com。如果配置采用 Fake-IP 模式，得到 198.18.0.0/16 范围内的映射地址可能是正常现象；这个地址需要继续进入 mihomo，由内核恢复域名并执行规则。看到 198.18.x.x 不应直接判断为解析错误。
真正需要关注的是查询持续超时、返回 SERVFAIL，或者系统获得 Fake-IP 后流量没有进入 TUN。若关闭 TUN 后系统仍缓存 Fake-IP，网页可能暂时无法访问。可先停用代理，再刷新系统 DNS 缓存，然后重新启动内核与 TUN。
核对配置中的 DNS 结构
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
fallback:
- tls://8.8.8.8:853这段示例展示的是字段关系，不应不加判断地覆盖现有订阅。端口 1053 仅是常见本地监听值。排查时确认 dns.enable 已开启、监听端口未被其他程序占用、上游地址在当前网络可达。若配置引用域名形式的 DoH 服务，还要保证用于解析该域名的 bootstrap 路径可工作，避免“解析 DNS 服务器域名又依赖该 DNS 服务器”的循环。
当日志里出现持续的 DNS timeout，可临时切换到配置提供方建议的另一组上游进行对照。只改 nameserver，保留节点、规则和 TUN 不动。若切换后立刻恢复，问题集中在原上游或其访问路径；若仍失败，则检查 53 端口劫持、防火墙和 TUN 路由。
第四步：排除 TUN、系统代理和其他 VPN 的冲突
系统代理主要影响主动读取代理设置的应用。游戏、命令行程序、部分商店应用和 UDP 流量可能忽略它。TUN 模式通过虚拟网卡和路由接管更多流量，但也更容易与企业 VPN、虚拟机网络、容器网络、加速器及安全软件发生冲突。
用开关组合定位接管层
- 先关闭 TUN，只开启系统代理。测试浏览器与前面的 curl 命令。
- 若浏览器恢复，说明节点和 HTTP 代理基本正常，问题集中在 TUN 路由、DNS 劫持或权限。
- 再关闭系统代理，只开启 TUN。测试浏览器和一个不读取系统代理的应用。
- 若两者单独正常、同时开启异常，检查客户端是否重复设置路由，或是否存在两套 DNS 接管。
- 最后恢复客户端推荐组合，不要长期依赖反复切换解决配置错误。
mihomo 的 TUN 配置常见字段包括 enable、stack、auto-route、auto-detect-interface 和 dns-hijack。不同系统与客户端支持的 stack 选项会有差异。若当前使用 gVisor 路径异常，可在客户端支持的前提下切换 system 进行对照；修改后需要完整重启内核，而不只是关闭再打开系统代理。
Windows 上启用服务模式或 TUN 后，虚拟网卡与路由写入需要相应权限。可在「设置」→「网络和 Internet」→「高级网络设置」中确认虚拟适配器状态。macOS 首次使用通常需要在「系统设置」→「通用」→「登录项与扩展」→「网络扩展」中允许相关扩展。Android 则应确认状态栏存在 VPN 标识，并在系统 VPN 页面检查是否有另一个常驻 VPN 占用唯一接口。
检查默认网卡识别
笔记本从有线网络切到 Wi-Fi、连接热点或唤醒后，默认出口可能改变。若 auto-detect-interface 没有正确识别当前网卡，TUN 流量可能被送回虚拟接口，形成路由循环。典型表现是开启 TUN 后延迟测试全部超时，关闭后立即恢复。此时先重启内核；仍未恢复时，断开不用的虚拟网卡和旧 VPN，再重新建立网络连接。
第五步：从日志里确认规则、握手和连接错误
前四步仍未定位时，应把日志级别临时调整为 info 或 debug。常见客户端入口位于「设置」→「日志级别」或「设置」→「参数设置」→「内核」。打开日志后只复现一次失败请求，再立即查看对应域名，不要让测速和后台更新产生大量无关记录。
重点识别这些日志线索
| 日志线索 | 含义 | 下一步 |
|---|---|---|
| match DIRECT | 请求被规则判定为直连 | 核对规则顺序、规则集更新和目标域名 |
| match REJECT | 请求被拒绝规则拦截 | 检查广告拦截或自定义规则 |
| connection refused | 目标端口主动拒绝连接 | 切换节点，检查服务端端口与协议参数 |
| i/o timeout | 连接或读取超过时限 | 区分 DNS、节点服务器和目标站超时 |
| no such host | 域名解析失败 | 检查 nameserver、网络权限和 DNS 劫持 |
| TLS handshake timeout | TLS 握手未在时限内完成 | 测试其他节点，检查时间、MTU 与线路质量 |
规则是自上而下匹配，通常命中第一条后停止。自定义的 DOMAIN-SUFFIX、IP-CIDR 或进程规则放在通用规则之前，可能把目标错误地送往 DIRECT 或 REJECT。排查时可以暂时选择全局模式并指定一个可用节点：若全局模式恢复，节点和基础代理链路大致正常，问题更可能位于规则或 provider；若全局模式仍失败，则继续检查节点、DNS 和 TUN。
全局模式只适合短时对照，不适合作为最终修复。确认问题后，应回到规则模式，修正规则集来源、策略组名称或自定义覆写。配置中的策略名必须与规则引用完全一致，大小写、空格和符号差异都可能导致加载错误或回退行为。
最后按固定顺序复测，避免“碰巧恢复”
完成修改后，先停止内核 5 秒，再重新启动。随后按“本地网络、DNS、本地代理端口、节点、规则、TUN”的顺序验证。不要只看一个网页是否打开，还应测试直连与代理两类域名、浏览器与非浏览器应用，以及 Wi-Fi 切换后的表现。
- 关闭 Clash，确认基础网络能访问本地网关和直连站点。
- 启动内核，确认配置加载完成，没有 YAML 字段或 provider 错误。
- 指定 127.0.0.1 和当前 mixed-port 执行 curl 测试。
- 确认订阅更新时间、当前节点和顶层策略组选择。
- 检查域名解析结果与 DNS 日志，区分正常 Fake-IP 和真实超时。
- 先用系统代理复测，再单独开启 TUN，确认冲突出现在哪种组合。
- 恢复规则模式，从日志确认请求命中了预期策略。
如果故障只在公司、校园或酒店网络出现，还应考虑该网络对 UDP、特定端口或加密 DNS 的限制。用手机热点进行一次对照最有效：同一设备、同一配置在热点上正常，而在原网络失败，范围就能收缩到局域网出口、认证页面或网络策略。完成认证后再启动 Clash，也能避免酒店 Wi-Fi 的登录页面被代理规则拦住。
这套顺序的核心是先验证最短链路，再逐层增加接管能力。节点、DNS、系统代理和 TUN 各自都能制造相似的“已连接却无法上网”，但测试结果不会相同。保留每一步的端口、时间、日志和开关组合，通常比反复重装客户端更快找到真正断点。