Clash 已连接无网络

先建立可复现的测试条件

先暂停自动切换节点，固定一个节点、一个测试网址和一种接管方式。客户端的“已连接”通常只说明内核已经运行，或者系统代理、虚拟网卡已启用；它不代表浏览器流量已经进入内核，也不代表远端节点能完成目标网站的 TLS 握手。

1. 记录当前配置名、代理模式、策略组选择，以及系统代理和 TUN 的开关状态。不要公开完整订阅链接。
2. 保存当前配置。后续每次只修改一个选项，测试完成后再决定保留还是撤销。
3. 退出其他代理客户端和 VPN。企业设备上的安全软件或网络策略应交由管理员核查，不要直接停用防护。
4. 打开客户端的连接列表和日志页，先使用 info 级别。临时提高到 debug 时，注意日志可能包含访问域名和本地网络信息。
5. 完全退出浏览器后重新启动，避免复用旧连接。所有对照测试都访问同一个地址。

一、确认系统代理指向正确端口

优先使用“系统代理开启、TUN 关闭”建立浏览器测试基线。系统代理主要影响遵循系统代理设置的应用，不等于接管所有进程。游戏、命令行程序、浏览器扩展和自行配置代理的软件可能走另一条路径。

检查系统设置与浏览器扩展

• Windows 11：进入「设置」→「网络和 Internet」→「代理」→「手动设置代理」，核对代理地址和端口。自动配置脚本与手动代理可能同时存在，需要确认实际生效的配置。
• macOS：进入「系统设置」→「网络」→当前网络连接→「详细信息」→「代理」，检查网页代理与安全网页代理是否指向客户端实际监听地址。
• 浏览器：暂时停用控制代理的扩展，检查是否存在独立代理配置或绕过列表。无痕窗口并不一定禁用所有扩展。

本机常用地址是 127.0.0.1。端口必须以当前生效配置为准，不能把 7890 当成所有客户端的固定值。下面只是说明字段用途的 YAML 片段，不是完整配置，也不需要直接覆盖现有订阅：

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

mixed-port 同时接受 HTTP 与 SOCKS 代理连接；只有 socks-port 的端口不能直接当作 HTTP 代理填写。external-controller 常见的 9090 是管理接口端口，不是网页流量入口。本机浏览器排障也不需要开启“允许局域网连接”。

绕过系统设置，直接测试本地代理

以下 Windows 命令显式指定 HTTP 代理，可用于区分“系统设置错误”和“代理链路错误”。如果实际端口不是 7890，先修改命令中的端口。macOS 与 Linux 使用 curl，并将 NUL 换成 /dev/null。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -o NUL -sS -w "HTTP=%{http_code}\n" https://example.com/

• 显式代理成功，浏览器失败：优先检查系统代理、浏览器扩展与代理绕过项，而不是继续调整节点。
• 立即提示无法连接本地端口：先检查内核是否运行、端口是否填错，以及监听进程是否属于当前客户端。
• 连接建立后超时：进入日志检查节点拨号、DNS 或目标网站访问阶段，不能仅凭超时认定端口有问题。

返回一个 HTTP 状态码说明此次请求至少收到了 HTTP 响应；403 或 451 仍可能是站点策略限制。若要确认走了预期代理，还需要同时查看连接记录中的出口链。

二、检查端口占用与内核启动

系统代理已经写入，但内核因配置错误未启动时，浏览器仍会把请求交给一个没有监听的端口。先查看日志中的启动错误，例如监听失败、配置解析失败或策略组引用不存在，再考虑修改端口。

在 Windows 查看监听进程

在 PowerShell 中执行以下命令。第一条检查监听状态和进程编号，第二条根据结果中的 OwningProcess 查询进程；示例编号 1234 需要替换为实际值。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

macOS 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。如果监听者是另一个客户端，先正常退出它，再启动要使用的客户端。不要仅凭端口冲突就结束不明系统进程。

• 没有监听结果：检查内核运行状态、有效配置和端口类型，确认客户端界面的开关确实已生效。
• 端口被旧进程占用：退出重复实例，必要时通过任务管理器确认旧进程是否仍在运行。
• 修改为其他端口后：同步更新系统代理与应用内代理设置，避免客户端监听 7891、浏览器仍连接 7890。

订阅文件与实际运行配置可能不同。客户端覆写、合并配置和图形设置都可能改变监听端口，应以运行时配置与监听结果为准。有关字段含义可查看端口配置说明。

三、隔离 TUN 权限与路由问题

如果系统代理测试能够访问，而开启 TUN 后失败，排查重点应转向虚拟网卡、路由和 DNS 接管。TUN 将 IP 流量交给内核处理，能覆盖部分不遵循系统代理的软件，但需要对应内核支持，以及创建网卡、修改路由等权限。

1. 关闭系统代理，仅开启 TUN，重新启动测试应用。这样可以减少两种入口叠加带来的判断混乱。
2. 按当前客户端要求安装或启动服务模式，批准系统权限请求。Windows 常由后台服务完成特权操作；macOS 可能需要授权辅助程序；Linux 通常需要适当的网络管理权限。
3. 查看日志是否出现虚拟网卡创建失败、权限不足或路由添加失败。开关亮起但初始化报错，不能视为接管成功。
4. 断开其他 VPN 后复测。多个虚拟网卡同时争用默认路由时，节点连接也可能被错误送回隧道，形成回环。
5. 若休眠唤醒或切换 Wi-Fi 后才出现故障，重启客户端内核并重新建立 TUN，再检查路由是否恢复。

不要同时尝试更换 TUN 协议栈、开启 IPv6、修改 MTU 和切换 DNS。若只在大文件传输或部分 HTTPS 网站上停住，可以在基础连通后再针对 MTU 排查；它不应成为所有“打不开网页”问题的第一步。

四、区分系统 DNS 与内核 DNS

看到 no such host、lookup failed 或域名解析超时，先确认是哪一层在解析。浏览器可能使用安全 DNS，系统有自己的解析器，Clash 内核也可能单独解析目标域名和代理节点域名。修改系统 DNS，并不一定会改变内核 DNS 的行为。

先观察查询，再清理缓存

在 Windows 中运行以下命令可以观察系统路径的解析结果，但它不能证明浏览器和内核走了同一套 DNS：

nslookup example.com
ipconfig /flushdns

第二条命令仅清理 Windows DNS 客户端缓存。浏览器、内核及上游解析器可能还有各自的缓存。修改配置后，应按客户端支持的方式重启内核，并重新建立浏览器连接。

• 节点服务器使用域名：节点本身也需要先被解析。若解析上游必须经过尚未建立的代理，可能形成启动依赖，应检查节点域名的解析路径。
• 使用 DoH：https:// 形式的 DNS 地址仍依赖网络连通与证书验证。检查系统时间，以及解析器域名如何完成初始解析。
• 浏览器使用安全 DNS：临时改为系统解析路径做对照。修改后如果故障消失，再检查浏览器解析流量的规则，而不是长期保留不明配置。
• 仅 IPv6 目标失败：检查本地 IPv6 连通性和代理链路支持。可临时关闭相关 IPv6 选项作对照，但要记录修改范围并在测试后复核。

Fake-IP 地址不是 DNS 错误的直接证据

Fake-IP 模式下，解析结果可能落在配置的合成地址池中，常见配置使用 198.18.0.1/16。内核保存域名与合成地址的映射，再处理后续连接。看到 198.18.x.x 不代表域名遭到错误解析，也不能用单纯的 ping 结果判断网页代理是否正常。

真正需要核查的是：拿到合成地址的流量是否继续经过同一个内核，以及映射是否仍然有效。如果应用拿到 Fake-IP 后绕过 TUN 直接连接，访问就可能失败。局域网设备发现、打印机或依赖真实地址的应用，可按实际需求设置 fake-ip-filter，不要把所有域名都加入过滤。基础概念见地址与 GeoIP 说明及术语手册。

五、用连接记录核对规则出口

如果请求已经进入内核，接着看连接列表中的目标域名、命中规则、策略组和最终节点。Rule 模式按规则顺序匹配，通常由第一条匹配规则决定出口；代理组名称叫“自动选择”，也不意味着该组当前一定选中了可用节点。

短时对照 Rule 与 Global

1. 保持当前节点不变，在 Rule 模式打开目标网站，记录命中规则和出口。
2. 短时切到 Global，并在 GLOBAL 策略组明确选择同一个节点，然后重新建立连接。
3. 若 Global 可访问、Rule 不可访问，检查 Rule 是否把目标交给 DIRECT、REJECT 或另一个失效策略组。
4. 测试后恢复 Rule。Global 是定位工具，不是对所有流量的永久修复。

规则修改要关注优先级。把新的域名规则放在兜底 MATCH 后面通常不会生效，因为请求已被前面的规则接走。持久化修改应放到客户端支持的覆写或规则合并位置，直接改远程订阅生成的文件可能在下次更新时被覆盖。具体匹配方式可参考规则分流教程。

六、验证节点与目标网站状态

延迟测试通过，只能证明某次探测在指定超时内完成，不等于目标网站可用。例如列表显示 180 ms，但实际页面在 20 秒 后超时，这两个结果并不矛盾：探测地址、连接协议、出口限制和目标服务可能不同。这里的数值是判读示例，不是节点实测数据。

• 所有节点都失败：检查订阅是否到期、账户流量是否耗尽、当前配置是否已启用，以及服务端是否有维护通知。
• 只有一个节点失败：切换同一订阅中的另一节点，再访问相同目标。不要在切节点的同时改 DNS，否则无法判断是哪项修复了问题。
• 只有一个网站失败：检查目标网站状态和区域限制。节点能访问其他 HTTPS 网站时，不应直接归因于本地端口。
• 提示认证或握手错误：检查订阅是否已更新、节点凭据是否有效，以及内核是否支持该协议和参数。
• 提示证书错误：先校准系统日期、时区与证书环境。不要关闭证书验证来掩盖故障。

切换 Wi-Fi 与手机热点是有价值的对照：同一个客户端、同一个节点、同一个网址，只有当前网络失败时，应进一步检查该网络的访问限制、UDP 支持或 DNS 路径。热点会消耗移动数据，测试前注意流量成本。

按现象决定下一步操作

仍未恢复时，提交最小诊断记录

向维护者反馈时，提供操作系统、客户端版本、内核版本、故障时间、代理模式、入口方式和可复现步骤。附上发生故障前后约 30 秒 的必要日志，并说明“显式代理是否成功”“关闭 TUN 是否恢复”“Global 是否可访问”。这些结果比一张“已连接”的截图更有定位价值。

发送前删除订阅令牌、节点密码、控制接口密钥和不必要的个人访问记录。排查结束后恢复临时改动，关闭调试日志，并确认系统代理指向当前仍在运行的客户端。更多常见错误可查看疑难解答，订阅入口与配置启用步骤见订阅导入教程。