STATE DEFINITION

先确认“已连接”具体指什么

Clash 客户端显示“运行中”“已连接”或出现 VPN 标记，通常只能说明内核已经启动、配置文件已经载入，或者系统已授予 VPN 接口权限。它并不等于浏览器流量已经进入 Clash，也不代表当前策略组选中的节点可以访问目标地址。排障时首先要把“程序状态”“流量入口”“规则决策”和“节点出口”拆开检查。

一次网页请求大致会经过以下链路：应用发起连接，操作系统根据代理设置或路由把流量交给 Clash，Clash 解析目标域名，规则引擎决定使用代理组、DIRECT 或 REJECT，代理组再选择具体节点，最后由节点建立远端连接。任意一环异常，都可能表现为页面持续加载、域名解析失败、连接被重置，或者只有部分应用不能联网。

TRAFFIC PATH
  1. 本地网络能够访问网关，设备已获得有效地址。
  2. 应用流量通过系统代理或 TUN 接口进入 Clash。
  3. DNS 返回可用结果，Fake-IP 映射关系正常。
  4. 规则命中预期策略组，而不是错误的 DIRECT 或 REJECT。
  5. 策略组所选节点可建立 TCP、UDP 或 QUIC 连接。
  6. 防火墙、安全软件和其他 VPN 没有中途拦截。

观察客户端的连接记录比反复切换开关更有效。打开网页后，如果连接列表完全没有新增条目，问题通常位于系统代理、TUN 路由或应用自身代理设置；如果有连接记录但显示 DNS 错误，应转向 DNS 配置；如果记录明确命中某个策略组并出现超时，则应检查节点和上游网络。

NETWORK BASELINE

关闭代理后验证基础网络

排查开始时先暂时关闭系统代理与 TUN 模式，但保留配置文件，不急于删除订阅或重装客户端。随后测试本地网关、普通网站和 DNS。这样可以区分“网络本身中断”与“流量经过 Clash 后中断”。如果关闭 Clash 后仍不能打开任何网站，应先处理 Wi-Fi、移动网络、路由器认证、校园网登录或运营商连接，而不是修改代理规则。

检查地址、网关与网络认证

  • 确认设备获得了正常的 IPv4 或 IPv6 地址，而不是自动分配的异常本地地址。
  • 在酒店、机场、校园网等环境中，先完成网页认证，再启动系统代理或 TUN。
  • 从 Wi-Fi 切换到移动热点测试。若热点可用而原网络失败，重点检查原网络的 DNS、UDP 限制与防火墙策略。
  • 检查系统日期和时区。时间偏差过大会导致 TLS 证书验证失败，表现为多个 HTTPS 网站同时打不开。

用分层测试区分 DNS 与连接故障

先测试 IP 连通性，再测试域名解析。Windows 可在终端使用 ping 1.1.1.1 与 nslookup example.com；macOS 和 Linux 可使用 ping -c 4 1.1.1.1、dig example.com 或 nslookup example.com。部分网络会限制 ICMP，因此 ping 失败不能单独作为断网结论，还应结合浏览器访问和 DNS 查询结果判断。

TRAFFIC INGRESS

核对系统代理、端口与 TUN 流量入口

Clash 常见的接管方式有系统代理与 TUN。系统代理主要影响遵循操作系统 HTTP、HTTPS 或 SOCKS 代理设置的应用；TUN 通过虚拟网络接口和路由接管更广泛的 TCP、UDP 流量。两种方式可以由客户端统一管理，但排障阶段应明确当前依赖哪一种，避免把系统代理错误归因于节点。

系统代理已开启但浏览器没有连接记录

先确认系统代理地址指向本机回环地址，端口与当前配置中的监听端口一致。常见配置会启用 mixed-port，同时接受 HTTP 和 SOCKS 连接；旧配置也可能分别使用 port 与 socks-port。如果客户端更新配置后端口发生变化，而操作系统仍保留旧端口，浏览器会立即显示代理服务器拒绝连接。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

还要检查浏览器或应用是否设置了独立代理。独立代理的优先级可能高于系统设置，地址可能仍指向已经退出的其他客户端。命令行工具也不一定自动读取桌面系统代理；如果只有终端程序失败，应检查其 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，而不是直接判断 Clash 整体失效。

TUN 已开启但所有请求超时

TUN 模式依赖虚拟接口、路由表与系统权限。首次启用时，Windows 可能要求管理员权限安装或启动网络组件；macOS、iOS 与 Android 会请求 VPN 权限。权限被撤销、虚拟接口初始化失败或默认路由未写入时，界面可能仍显示内核运行，但业务流量没有正确进入处理链路。

关闭其他 VPN、网络加速器和同类代理后重新测试。多个程序同时修改默认路由或 DNS，容易产生路由优先级冲突。若关闭 TUN、仅开启系统代理后浏览器恢复，说明节点与基本代理端口大概率正常，问题范围可以收缩到 TUN 权限、接口栈、路由和 DNS 劫持设置。

DNS PIPELINE

识别 DNS 解析、Fake-IP 与缓存问题

DNS 故障常见表现包括：输入域名打不开，但直接访问 IP 有响应；连接日志持续出现解析超时；部分域名正常而另一些域名失败；切换网络后旧结果仍被使用。Clash Meta，也称 mihomo，可通过内置 DNS 模块执行普通解析、Fake-IP 映射、分流查询和回退判断。配置字段有效并不代表上游 DNS 在当前网络中一定可达。

先判断查询是否到达 Clash

开启 DNS 日志或查看客户端日志，在访问测试域名时确认是否出现查询记录。若系统仍向旧 DNS 服务器查询，可能是 TUN 的 DNS 劫持没有生效，也可能是浏览器启用了独立的安全 DNS。排障时可暂时关闭浏览器独立 DNS，让查询路径保持单一；确认 Clash DNS 正常后，再按实际需要恢复。

检查上游协议与网络能力

传统 UDP DNS、TCP DNS、DoH 和 DoT 对网络条件的要求不同。某个上游地址在移动网络可用，不代表在公司或校园网也可用。尤其是在代理节点尚未连通时，如果域名型代理服务器地址又依赖必须经代理访问的 DNS，就可能形成启动依赖循环。用于解析代理服务器域名的基础 DNS 应能通过当前本地网络直接访问。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5

以上片段只展示字段关系，不应直接覆盖现有订阅。配置由订阅提供方或客户端覆写机制管理时，应在对应的覆写层修改，否则下一次订阅更新会覆盖本地编辑。启用 IPv6 但本地网络的 IPv6 路由不稳定时，应用可能优先尝试不可达地址；可以临时关闭 Clash DNS 中的 IPv6 返回进行对照测试，但最终应根据网络能力决定，而不是长期依赖试错设置。

Fake-IP 模式下的特殊现象

Fake-IP 会先向应用返回保留地址，再由内核根据域名映射处理后续连接。因此，看到 198.18.0.0/16 范围的地址通常属于工作机制，不等于域名被解析到公网错误地址。真正需要检查的是应用连接是否被 Clash 捕获，以及映射记录是否仍存在。如果 DNS 查询经过 Clash，但后续连接绕过 Clash，应用拿到 Fake-IP 后自然无法直接访问。

局域网设备发现、打印机、路由器管理域名和某些依赖真实地址的服务，可能需要加入 Fake-IP 过滤。过滤应针对明确域名设置，不宜把大范围域名全部排除，否则规则匹配与 DNS 分流结果会变得难以预测。修改后清理系统 DNS 缓存，并完全退出再启动受影响应用，避免旧连接池继续使用历史结果。

RULE DECISION

检查规则模式、策略组与节点出口

当连接记录已经出现，下一步查看每条请求命中了哪条规则、交给哪个策略组，以及策略组最终选择了哪个节点。Clash 的规则按照声明顺序匹配，通常命中第一条适用规则后停止继续查找。位于前面的宽泛规则可能遮蔽后面的精确规则，末尾的 MATCH 则承接此前未匹配的请求。

用模式切换做对照，不把全局模式当修复

把规则模式临时切换到全局模式，并选择一个已确认可用的节点。如果网站恢复，说明系统代理、DNS 基础链路和节点出口可能正常，问题更可能位于规则集、策略组选择或 DIRECT 路由。如果全局模式仍失败，则应继续检查节点、协议兼容性和防火墙。对照完成后应切回规则模式，并修正具体规则，而不是长期用全局模式掩盖错误命中。

直接连接模式也可用于判断本地网站是否被错误送入代理。如果 DIRECT 可访问而规则模式失败，查看该域名是否命中代理组，以及所选节点是否适合该目标。相反，如果代理模式可访问而 DIRECT 超时，说明目标在当前本地网络上的直连路径不可用，规则应交给适当的代理策略。

策略组名称存在不代表已经选中可用节点

select 类型策略组需要手动选择成员；url-test 会根据测试地址与间隔自动选择；fallback 通常按照可用性顺序切换。自动测试结果只反映测试地址在某一时刻的连接情况，不能完整代表所有网站、所有协议或长连接稳定性。延迟数字正常但网页失败时，应查看实际请求日志，而不是只看策略组的测速结果。

  • 确认策略组没有选中 REJECT、不可用节点或已经失效的子策略组。
  • 手动切换两个不同地区、不同线路的节点，使用同一网站重复测试。
  • 若 TCP 网页正常而游戏、语音或 QUIC 异常，检查节点是否支持 UDP，TUN 是否接管 UDP。
  • 若只有特定网站失败，检查域名规则、IP 规则、规则集更新状态和最终 MATCH 去向。
  • 若订阅刚更新后出现故障，确认策略组名称与规则引用仍一致，避免规则指向已不存在的组。
SYSTEM BOUNDARY

排查防火墙、端口占用与其他网络软件

如果配置在其他设备可用，而当前设备始终失败，应检查操作系统边界。防火墙可能允许客户端界面运行，却阻止核心进程建立外连；安全策略也可能禁止本地程序监听代理端口。升级客户端后核心文件路径变化，原有放行规则有时不会自动匹配新路径，需要重新确认网络权限。

确认监听端口属于当前 Clash 内核

Windows 可使用 netstat -ano | findstr 7890 查看端口与进程编号；macOS 和 Linux 可使用 lsof -i :7890。如果端口已被其他程序占用，Clash 日志通常会出现监听失败。此时应关闭冲突程序或在配置与系统代理中同步更换端口，不能只修改其中一处。

避免多个网络接管程序叠加

企业 VPN、虚拟机网络、容器网络、游戏加速工具和流量过滤程序都可能写入路由、安装虚拟网卡或修改 DNS。排查时逐个退出，并在每次变更后检查默认路由和连接记录。若重启系统后短暂恢复，随后在某个网络程序启动时再次中断，通常可以据此定位冲突来源。

局域网共享场景需要额外检查

当其他设备通过局域网连接本机 Clash 时，本机配置需要允许局域网访问，代理端口还要通过系统防火墙。客户端设备填写的服务器地址应是 Clash 所在设备的局域网地址，不能填写 127.0.0.1，因为回环地址始终指向客户端设备自身。出于访问控制考虑，应只在可信网络中开放监听，并结合客户端支持的认证字段限制使用范围。

RECOVERY CHECKLIST

按固定顺序恢复配置并复核

完成单项测试后，应把临时改动收束成稳定配置。不要同时保留多个临时 DNS、多个重复规则或长期全局模式。以下顺序适合大多数桌面与移动客户端，也便于把故障定位结果交给配置维护者。

  1. 确认基础网络：关闭系统代理与 TUN，验证当前网络可以完成认证并访问普通站点。
  2. 启动内核：加载配置后查看启动日志，确认 YAML 解析、端口监听和规则集载入成功。
  3. 只开系统代理：用浏览器访问测试网站，确认连接列表出现记录。
  4. 验证 DNS：检查域名查询结果与日志，清理缓存后重复测试同一域名。
  5. 验证节点：在全局模式短暂选择已知可用节点，再回到规则模式比较结果。
  6. 核对规则：查看实际命中项、策略组与最终节点，修正错误的 DIRECT、REJECT 或组名引用。
  7. 单独启用 TUN：确认 VPN 权限、虚拟接口和路由正常，再测试不遵循系统代理的应用。
  8. 恢复安全边界：重新开启必要的防火墙与网络软件，逐项确认是否引入冲突。

常见现象与优先检查项

连接列表为空
优先检查系统代理地址、端口、应用独立代理、TUN 权限与路由接管。
域名失败，IP 可达
优先检查 Clash DNS、系统 DNS、浏览器独立 DNS、上游可达性与缓存。
全局可用，规则失败
查看规则顺序、规则集状态、MATCH 去向、策略组引用和 DIRECT 路径。
浏览器可用，其他应用失败
检查应用是否绕过系统代理，必要时验证 TUN 接管与 UDP 支持。
所有节点同时超时
先检查本地网络、DNS、系统时间、防火墙和出口限制，再判断订阅节点状态。
更新订阅后失效
检查配置解析日志、策略组名称、规则引用、覆写内容和客户端字段兼容性。

若问题仍未解决，可以导出一份最小诊断记录：操作系统与客户端版本、内核类型、接管方式、故障发生时间、测试网络、规则模式、命中策略以及脱敏后的错误日志。不要公开完整配置文件或订阅链接。清晰的链路信息比“已经重装过”更容易定位问题，也能避免重复修改与故障无关的设置。