Clash 界面显示“已连接”、节点旁出现延迟，或者日志持续滚动，都不等于浏览器流量已经成功经过代理。客户端可能只是完成了配置加载、延迟探测或核心启动；真正访问网页还要经过应用程序、系统代理或 TUN、Clash 入站端口、规则匹配、策略组、代理节点、DNS 与目标网站这一整条链路。任何一层中断，表面上都可能是“连接正常但打不开网页”。

先分清“无法上网”发生在哪一层

第一步不是切换更多节点，而是确认故障范围。打开一个常用网站之外，再测试局域网地址、普通域名与纯 IP 连接。如果只有一个网站失败，可能是目标站点限制、规则命中或节点出口问题；如果所有域名失败但 IP 可以访问，优先检查 DNS；如果浏览器可用而终端、游戏或商店不可用，通常是应用没有遵循系统代理，需要单独设置代理或使用 TUN。

  1. 检查本地网络：完全退出 Clash 或关闭系统代理后，确认直连网站能否正常打开。基础网络本身断开时，继续调整代理没有意义。
  2. 比较不同应用：分别测试浏览器、命令行和一个不读取系统代理的应用。结果差异可以判断问题位于应用代理还是全局转发层。
  3. 观察连接日志：访问网页时查看日志中是否出现对应域名、命中规则和最终策略。如果完全没有新记录，流量大概率没有进入 Clash。
  4. 区分超时与解析错误：“找不到服务器地址”更接近 DNS 故障；“连接被拒绝”常见于本地端口错误；长时间超时则要继续检查策略、节点与路由。

日志是整套排查中最直接的证据。正常请求通常能看到目标域名或 IP、规则类型、策略组与实际节点。若日志显示 DIRECT，说明请求按规则直连；若显示某个代理节点后超时，说明流量已经进入核心，检查重点应转向节点可用性、策略组和远端网络，而不是系统代理开关。

确认订阅、配置文件与策略选择

订阅更新成功只代表客户端下载到了内容，不代表当前启用的配置就是刚更新的那一份。部分客户端允许保存多份本地配置，更新动作与切换动作彼此独立。先进入配置页面，核对当前配置名称、更新时间和启用状态；更新后若客户端提示重新加载，应完成加载再测试。

检查配置能否被核心完整载入

配置文件包含端口、DNS、规则、策略组与节点定义。YAML 缩进错误、策略组引用不存在的节点、规则提供者下载失败，都会造成加载失败或部分功能异常。优先查看核心启动日志，不要只看订阅页面的“更新完成”。如果日志出现解析错误，应回到最后一份可正常启动的配置，再逐段恢复自定义内容。

使用远程规则集时，还要确认规则文件已经下载。首次加载配置、网络环境变化或规则提供者地址暂时不可达时，策略组可能存在，但必要的规则数据尚未准备完成。此时可重新加载配置并观察规则下载记录。不要在来源不明的配置上直接添加大量覆写项，以免把订阅问题与本地修改混在一起。

核对代理模式与策略组

常见模式包括规则模式、全局模式与直连模式。规则模式按照配置中的规则自上而下匹配；全局模式通常把请求交给指定的全局策略；直连模式则绕过代理。若客户端停留在直连模式，即使节点测试有延迟，网页也不会经过节点。

  • 规则模式：适合日常使用。检查目标请求最终命中了哪个规则，以及该规则指向哪个策略组。
  • 全局模式：适合短时判断规则是否有误。全局可访问而规则模式不可访问，重点检查规则顺序、策略组引用和兜底规则。
  • 直连模式：用于暂时绕过代理。排障后记得切回需要的模式。

策略组名称相同也不代表组内选择正确。手动选择组可能仍停留在已经失效的节点，自动测速组也可能使用了不适合当前网络的探测结果。进入策略组，明确选择一个近期可用的节点，再发起真实网页请求。延迟测试只说明探测地址在当时得到响应，不能替代实际 TCP、TLS 与目标网站访问测试。

检查系统代理、监听地址与端口冲突

不使用 TUN 时，浏览器和多数桌面软件依靠系统代理把请求送到 Clash。客户端中的“系统代理”开关必须与核心实际监听的 HTTP、SOCKS 或混合端口保持一致。核心重启失败、端口被占用或系统设置残留旧端口时，会出现代理开关已开但所有请求都被本机拒绝的情况。

先看请求是否进入核心

保持日志窗口打开，然后刷新网页。如果日志没有任何新增请求，依次检查系统代理是否开启、代理服务器是否为本机地址、端口是否与当前配置一致。常见本机地址是 127.0.0.1，具体端口应以客户端当前显示或配置文件中的 mixed-port、port、socks-port 为准，不要照抄其他设备的端口。

可以在命令行显式指定 HTTP 代理进行测试。下面的端口只是示例，执行前应替换为客户端实际监听端口：

curl.exe -I -x http://127.0.0.1:7890 https://example.com/

如果显式代理请求成功，而浏览器仍失败，核心、节点和基本出站链路大致正常，问题更可能位于系统代理未生效、浏览器单独设置了代理、扩展修改网络设置，或应用没有读取系统代理。若命令直接提示无法连接到 127.0.0.1，检查核心是否运行及端口是否监听。若请求进入日志后远端超时，再回到策略与节点层处理。

排除端口占用和重复运行

同一台设备同时运行两个代理客户端，或者旧的 Clash 进程没有退出，可能抢占相同端口。新客户端界面虽然打开，核心却未必成功监听。查看启动日志中的 address already in use、bind 或监听失败信息，关闭重复进程后再启动核心。修改端口也能绕开冲突，但系统代理必须同步更新到新端口。

局域网共享选项与本机使用不是同一件事。仅在本机访问时，监听 127.0.0.1 通常足够；只有其他设备需要连接时才考虑允许局域网访问，并配合系统防火墙设置。不要为了修复本机浏览器问题盲目开放局域网监听。

处理系统代理残留

客户端异常退出后，操作系统可能保留指向旧端口的代理设置，表现为 Clash 已关闭但浏览器仍无法访问。重新启动客户端并先关闭“系统代理”，确认操作系统代理页面中的手动代理已清除，再按需要重新开启。企业网络、自动配置脚本和浏览器策略也可能覆盖手动设置，应在系统网络设置中确认最终生效值。

DNS 失败：域名打不开但网络未必断开

DNS 负责把域名转换为地址。Clash 或 mihomo 可以接管 DNS，并根据规则、Fake IP 或真实地址结果决定后续连接。DNS 配置失效时，节点可能有延迟、代理端口也正常，但浏览器会持续显示域名解析失败。因此，DNS 应在确认请求已进入核心后单独检查。

用现象判断解析问题

  • 访问域名失败，而已有连接或某些直接使用 IP 的服务仍可工作。
  • 日志出现 DNS 超时、上游服务器不可达、解析循环或查询被拒绝。
  • 切换网络后突然失效，尤其是在公司网络、校园网、公共 Wi-Fi 与家庭网络之间切换时。
  • 关闭 TUN 或关闭 Clash DNS 后恢复，说明故障与 DNS 接管链路相关。

系统命令可以帮助判断操作系统当前能否解析域名：

nslookup example.com

nslookup 的结果不能单独证明 Clash DNS 完全正常，因为部分应用可能使用浏览器内置的安全 DNS，TUN 也可能劫持普通 DNS 请求。需要同时查看客户端 DNS 日志与浏览器设置。如果浏览器启用了独立的加密 DNS，它可能绕过系统解析路径，或者与规则预期不一致。排障时可暂时改回使用系统 DNS，确认问题边界后再决定最终方案。

理解 Fake IP 与 redir-host

在支持的 Clash Meta（mihomo）配置中，fake-ip 模式会为域名返回一个保留地址，并在连接发生时还原域名，从而提高规则匹配与透明代理的一致性。看到保留地址不一定是异常。真正的问题通常是 DNS 流量没有被正确接管、Fake IP 映射丢失，或某些局域网与特殊应用不兼容。

redir-host 返回真实解析地址，兼容路径不同，但不意味着它在所有场景下都更可靠。不要仅因为看到 Fake IP 就切换模式。若只有打印机、局域网设备、游戏平台或特定应用失败，可先检查 fake-ip-filter 是否需要排除对应域名，并确认局域网域名由合适的名称服务器解析。

检查 DNS 上游与回环依赖

DNS 上游必须在当前网络条件下可达。若上游本身需要代理，而代理连接又必须先解析节点域名，就可能形成依赖循环。配置中的默认名称服务器通常用于解析代理节点域名，应该选择在启动阶段可直接到达的解析服务。订阅节点使用域名时，这一步尤其重要。

修改 DNS 后应重新加载配置，并清理操作系统或浏览器缓存再复测。不要一次加入多个来源不明的上游地址；数量增加无法修复路由错误，反而会让超时来源更难定位。更完整的字段含义与配置关系可以参考使用手册。

TUN 模式已开启，仍然无法访问

TUN 通过虚拟网络接口接管更多流量，适合不遵循系统代理的应用。它涉及虚拟网卡、路由表、DNS 劫持、系统权限和防火墙，比普通系统代理多出数个故障点。开启开关不代表虚拟接口已经成功创建，应以核心日志与系统网络接口状态为准。

确认权限与驱动状态

Windows 上创建和调整虚拟接口通常需要足够的系统权限；macOS 可能要求批准网络扩展或输入管理员凭据；Linux 则需要 TUN 设备与相应网络管理权限。日志若出现创建接口失败、设置路由失败或权限不足，应先解决权限问题，而不是继续切换节点。

系统休眠、升级、网络适配器变化后，旧虚拟接口或路由可能没有正确释放。先关闭 TUN，等待路由恢复，再重新开启。若仍失败，完整退出客户端并重启系统通常比连续点击开关更容易清理遗留状态。重启后先只开启系统代理验证核心与节点，再开启 TUN，这样可以判断故障是否确实由透明接管引入。

检查路由、排除项与回环

TUN 必须避免把 Clash 自身连接再次送回 TUN，否则会出现流量循环。成熟客户端通常会自动处理核心进程与必要路由，但自定义路由、第三方防火墙、VPN、虚拟机软件及其他网络过滤工具可能改变结果。排查时暂时停用另一个 VPN 或代理工具，只保留一个接管网络的程序。

如果开启 TUN 后互联网恢复，但局域网设备不可访问，应检查私有网段是否按需要直连，以及自动路由和严格路由设置是否符合当前系统。反过来，如果局域网正常而互联网全部超时，查看默认路由是否被正确写入、出站接口是否随 Wi-Fi 与有线网络切换。不要把所有私有地址一律代理，这可能影响路由器管理页、文件共享和本地 DNS。

系统代理与 TUN 不要混乱叠加

部分客户端支持同时开启系统代理与 TUN，这在正常配置下可以工作，但排障时不利于确定请求走哪条路径。建议先关闭 TUN，仅用系统代理测试浏览器；确认正常后，关闭系统代理或按客户端建议保留设置，再单独测试 TUN 对终端和其他应用的接管。每一步都观察日志，避免根据网页偶然打开一次就下结论。

按应用和操作系统补查差异

当同一台设备上只有部分程序失败时，不必继续改动全局订阅。浏览器可能使用独立代理或安全 DNS；终端工具可能读取 HTTP_PROXY、HTTPS_PROXY 与 ALL_PROXY 环境变量；游戏和商店应用则可能完全绕过系统代理。先明确应用采用哪种网络路径，再决定使用应用内代理、系统代理还是 TUN。

Windows

检查“设置”中的手动代理是否与客户端一致，并留意旧的自动配置脚本。部分应用的网络隔离或回环限制会造成桌面浏览器正常、商店应用异常。防火墙也可能阻止核心程序监听或出站。若更换了客户端程序路径，重新确认系统防火墙授权，并通过客户端日志验证相关应用是否产生请求。

macOS

系统代理按网络服务分别保存。Wi-Fi 与有线网络切换后，代理可能只配置在原来的服务上。进入当前正在使用的网络服务检查 Web 代理与安全 Web 代理。TUN 或增强模式还需要网络扩展正常启用；系统更新后若扩展授权被重置，应按客户端提示重新批准。

Linux

桌面环境的系统代理不一定影响终端程序，终端环境变量也不一定影响图形应用。明确设置范围后分别测试。使用 TUN 时检查 /dev/net/tun、路由表、策略路由和 DNS 管理服务，避免 NetworkManager、systemd-resolved 与手动写入的解析配置相互覆盖。

Android 与 iOS

移动端通常通过系统 VPN 接口实现接管。若状态栏显示 VPN 但请求失败，检查系统是否限制了客户端后台运行、是否同时启用另一项 VPN，以及当前 Wi-Fi 是否需要先完成门户认证。切换蜂窝网络与 Wi-Fi 可以快速判断问题是否只存在于某个接入网络。按应用分流或绕过局域网设置也会改变实际结果。

从最少改动到恢复访问的顺序

下面的顺序把故障点从外到内分层，适合“昨天还能用，今天突然全部打不开”的情况。完成一步后立即测试，并记录日志变化；一旦恢复，就回看最后一次改动，而不是继续执行后续步骤。

  1. 关闭系统代理和 TUN，确认设备的基础网络与本地直连访问正常。
  2. 启动 Clash 核心，确认配置加载成功，没有 YAML、规则提供者、监听端口或权限错误。
  3. 核对当前启用的订阅配置，更新后重新加载，并明确选择一个可验证的节点。
  4. 确认不是直连模式；短时使用全局模式判断规则是否为故障来源。
  5. 只开启系统代理，刷新网页并观察日志。无日志就查系统代理，有日志就查规则、节点与 DNS。
  6. 使用显式代理命令测试本地监听端口，排除浏览器扩展和应用设置干扰。
  7. 检查端口占用、重复核心进程，以及系统中残留的旧代理地址。
  8. 根据解析错误和 DNS 日志检查上游、浏览器安全 DNS、Fake IP 与节点域名解析。
  9. 系统代理稳定后再开启 TUN，核对权限、虚拟接口、路由和其他 VPN 冲突。
  10. 恢复规则模式与日常设置，用浏览器、终端和目标应用分别验证。

如果全局模式下所有节点都超时，但基础网络正常，可以在另一网络上复测同一配置，区分本地网络限制与订阅节点故障。如果只有单个节点失败，直接更换节点并保留日志；如果整份配置无法载入，则联系配置提供方确认订阅状态和格式。提交问题时附上操作系统、客户端版本、核心类型、代理模式、DNS 模式及经过处理的错误日志，比只描述“连不上”更容易得到准确判断。

多数“Clash 已连接但无法上网”并不是单一开关造成的。可靠的处理方式是先验证基础网络，再确认配置与节点，然后检查流量有没有进入本地端口，最后处理 DNS 和 TUN。需要重新走一遍安装与权限设置时，可按完整教程逐项核对，避免在旧设置上继续叠加修改。