故障排查 预计阅读 12 分钟

Clash 已连接但无法上网?按顺序过一遍这份八步排查清单

代理显示已连接却打不开网页,原因通常集中在节点失效、DNS 污染、规则模式与系统时间几处。按固定顺序逐项排查,定位比盲目重装快得多。

这类故障适合按网络链路从外到内排查：基础网络、远端节点、设备时间、规则选择、DNS、代理入口、TUN 接管，最后才处理配置文件和内核日志。每一步只改一个变量，修改后立即复测。若同时切节点、改 DNS、开 TUN，很难确认真正的故障点。

第一步：关闭 Clash，确认基础网络可用

先停止代理服务，而不是只把模式从「规则」改成「直连」。Android 客户端可进入主界面关闭运行开关，并确认状态栏中的 VPN 标记消失。Windows 或 macOS 客户端还要关闭「系统代理」，避免内核停止后系统仍把请求发往本地端口。

  1. 关闭 Clash 或 mihomo 内核。
  2. 关闭系统代理与 TUN 模式。
  3. 断开再连接当前 Wi-Fi，或切换一次飞行模式。
  4. 打开一个此前未访问过的普通网页，避免浏览器缓存造成误判。
  5. 分别测试 Wi-Fi 与移动数据，记录哪一种网络失败。

如果关闭 Clash 后仍无法访问任何网页，问题位于上游网络。常见情况包括 Wi-Fi 未完成门户认证、路由器 DNS 异常、移动数据被限制以及当前网络只有局域网连接。公共 Wi-Fi 可先访问一个普通 HTTP 页面触发认证页。只有直连网络恢复后，后面的代理排查才有意义。

第二步：切换节点，区分订阅正常与节点可用

订阅能够更新，不代表订阅中的每个节点都能建立连接。订阅下载通常只是一次 HTTPS 请求，而代理访问还涉及域名解析、TCP 或 UDP 握手、TLS 时间校验、协议参数与远端服务状态。

先做延迟测试，再做真实访问

在「代理」或「Proxies」页面找到当前策略组，对至少三个不同线路执行延迟测试。测试地址通常由配置中的 url 决定，例如 https://www.gstatic.com/generate_204。结果可按以下方式理解：

  • 80–300 ms：节点至少完成了当前测试请求，但不等于所有网站都可访问。
  • 800 ms 以上：线路拥塞、绕路或丢包明显，真实访问可能频繁超时。
  • timeout：测试时间内未完成请求，优先切换节点。
  • 0 ms、空白或立即失败：可能是测试地址、DNS、权限或内核状态异常。

不要只在同一个自动选择组内反复点击。应手动选择两个不同地区、不同服务器名称的节点，再分别访问网页。若一个节点可用、其他节点失败，故障已经收敛到线路侧，不需要重装客户端。若所有节点同时超时，再继续检查设备时间和 DNS。

确认策略组不是停在 DIRECT 或 REJECT

配置可能把主选择组命名为「节点选择」「Proxy」或其他名称。打开该组，确认当前选择项不是 DIRECT、REJECT 或已失效的下级策略组。自动策略组可能保留上一次测试结果，手动切换后等待约 5–10 秒 再复测。

第三步：校准系统时间与时区

TLS 证书验证依赖准确的系统时间。设备日期偏差数小时或数天时，节点握手、订阅更新和 HTTPS 网页都可能失败。日志中常见表现包括 certificate has expired、not yet valid、TLS handshake failed。

Android 可进入「设置」→「系统」→「日期和时间」，开启「自动设置时间」与「自动设置时区」。部分厂商系统的入口位于「设置」→「更多设置」→「日期和时间」。开启后等待运营商或网络时间同步，再完全停止并重新启动 Clash。

桌面系统同样需要检查时间同步。Windows 可在「设置」→「时间和语言」→「日期和时间」中执行立即同步。时区应与当前位置一致，例如中国标准时间通常显示为 UTC+08:00。手动把时钟调到大致正确并不等同于完成同步，几分钟的偏差也可能影响部分短期证书或鉴权请求。

第四步：切换代理模式，定位规则匹配问题

Clash 常见模式包括 rule、global 和 direct。其中规则模式会按照配置文件中的 rules 从上到下匹配，命中后交给指定策略组。规则顺序错误、策略组名称变化或末尾规则缺失，都可能造成特定网站无法访问。

用全局模式做短时对照

  1. 记录当前模式和已选节点。
  2. 将模式从「规则」切到「全局」。
  3. 在全局策略组中手动选择一个延迟正常的节点。
  4. 重新打开目标网页，不要只刷新旧标签页。
  5. 测试完成后切回「规则」，避免长期扩大代理范围。

全局模式可以访问、规则模式不能访问，说明节点和基础连接大概率正常，问题位于规则或策略组。此时打开「连接」记录，查看目标域名对应的 Rule、Rule Payload 与 Chains。如果目标流量落到 DIRECT，检查域名规则是否被更靠前的直连规则覆盖。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

规则从上到下执行，首个命中项生效。末尾通常需要一个兜底规则，例如 MATCH,PROXY。实际策略组名称必须与 proxy-groups 中的名称完全一致，包括大小写和空格。订阅生成的配置不建议直接大范围改写，可优先使用客户端提供的覆写功能，并保留原始订阅作为回退。

第五步：排查 DNS 解析与 Fake-IP 映射

网页提示找不到服务器、节点测速全部失败、IP 地址可以访问而域名不能访问时，应重点检查 DNS。Clash Meta，也就是 mihomo 内核，常见增强模式为 fake-ip 或 redir-host。Fake-IP 会先向应用返回映射地址，再由内核依据映射关系处理真实域名，因此必须保证 DNS 请求确实进入 Clash。

先清缓存，再重启 DNS 链路

  • 停止 Clash，等待约 5 秒。
  • Android 切换一次飞行模式，或断开并重新连接 Wi-Fi。
  • 清除浏览器的 DNS 缓存，最直接的方式是完全结束浏览器进程后重开。
  • 重新启动 Clash，再访问一个此前未测试的域名。

Android 的「私人 DNS」也可能改变解析路径。可进入「设置」→「网络和互联网」→「私人 DNS」，临时改为「自动」进行对照。不同厂商菜单名称可能是「连接与共享」→「私人 DNS」。如果指定的加密 DNS 主机在当前网络不可达，应用会长时间等待解析结果。

检查配置中的 DNS 关键项

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

listen 端口必须未被其他程序占用。上面的 1053 只是常见示例，实际配置可能不同。若日志出现 address already in use，说明端口冲突。加密 DNS 地址还依赖网络是否允许对应端口，DoT 通常使用 853，DoH 通常使用 443。

第六步：核对系统代理地址、端口与监听状态

桌面端最常见的现象是 Clash 内核运行正常，但系统代理仍指向旧端口。典型混合端口为 7890，SOCKS 端口可能为 7891，不过订阅与客户端均可修改这些值，不能只凭默认值判断。

进入客户端的「设置」→「参数设置」或「General」页面，记录 mixed-port、port 和 socks-port。再检查操作系统代理是否指向 127.0.0.1 以及相同端口。若客户端仅开启 SOCKS 监听，系统 HTTP 代理却填写该端口，部分程序会直接连接失败。

终端可用显式代理请求绕过系统代理设置，验证本地入口是否工作。以下命令假设混合端口为 7890：

curl -I --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://example.com

如果显式代理请求成功，而浏览器失败，问题多半位于系统代理或浏览器自身设置。如果命令立即返回「connection refused」，说明对应端口没有监听，应检查内核是否启动、端口是否被修改。若请求停住并最终超时，则本地端口可能正常，但节点、DNS 或出站连接仍有问题。

浏览器可用而终端命令不可用，也不一定是 Clash 故障。许多命令行程序不会自动读取操作系统代理，需要设置 HTTP_PROXY、HTTPS_PROXY 或在命令参数中明确指定代理。

第七步：检查 TUN 模式、VPN 权限与应用冲突

Android 上的 Clash 通常通过系统 VpnService 建立本地 VPN 接口。连接请求得到授权，只代表接口可以创建。若系统撤销权限、省电策略结束后台服务，或者另一款 VPN 应用占用接口，界面可能短时间保留运行状态，但流量已经不能正常转发。

  1. 停止其他 VPN、网络过滤和防火墙应用。
  2. 在 Android 系统的 VPN 设置中断开旧连接。
  3. 返回 Clash，重新启动服务并确认系统连接请求。
  4. 先关闭 TUN，仅使用客户端默认 VPN 接管方式测试。
  5. 桌面端则反向测试：系统代理可用后，再开启 TUN 接管不读取代理设置的程序。

桌面 TUN 模式需要创建虚拟网卡并调整路由。mihomo 常见参数包括 stack: mixed、auto-route: true 与 auto-detect-interface: true。如果设备同时连接有线网络、Wi-Fi、虚拟机网卡和企业 VPN，自动出口判断可能选错接口。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

排查时先关闭 TUN，使用系统代理验证 HTTP 与 HTTPS 是否恢复。如果系统代理正常、开启 TUN 后失败，重点查看路由创建、虚拟网卡权限、当前默认网关和其他 VPN 冲突。不要把「开启 TUN」当作所有连接问题的通用修复，它解决的是流量接管范围，不会修复失效节点或错误 DNS。

第八步：读取日志，回退配置并重新导入订阅

前七步都未定位时，再检查配置完整性和运行日志。先把日志级别设为 info，复现一次故障并立即查看最新记录。只有在信息不足时短时使用 debug，因为详细日志增长较快，也更难筛选关键错误。

日志片段 优先检查
i/o timeout 节点不可达、丢包、出站被阻断
connection refused 目标端口未监听或远端服务拒绝连接
no such host DNS 解析失败、上游 DNS 不可达
address already in use 本地代理端口或 DNS 端口冲突
authentication failed 节点凭据、UUID、密码或订阅内容失效
certificate 相关错误 系统时间、证书链或 TLS 参数

如果问题出现在一次订阅更新之后，先切换到更新前仍可用的本地配置。多配置共存时，确认当前激活的 Profile 正是刚才检查的那一份。随后重新拉取订阅，检查更新时间和配置解析结果。解析失败时不要继续使用半加载状态，应恢复旧配置或联系订阅提供方确认配置格式。

手动覆写也是高频故障源。重点检查 dns、rules、proxy-groups、tun 与端口字段。YAML 对缩进敏感，应使用空格保持层级一致。策略组引用不存在的节点名称、规则指向不存在的策略组、同一端口被重复定义，都会导致启动失败或部分功能失效。

最后的最小化恢复顺序

  1. 导出或记录当前配置名称、端口和关键覆写项。
  2. 关闭 TUN、私人 DNS和浏览器独立 DNS。
  3. 导入一份确认可解析的订阅配置。
  4. 选择一个延迟正常的节点。
  5. 先用全局模式测试，再切回规则模式。
  6. 基础代理恢复后，逐项重新启用 DNS 覆写与 TUN。

复测标准：不要只看一次网页刷新

修复后至少执行三类测试。第一类是打开两个不同域名的 HTTPS 页面；第二类是切换一次 Wi-Fi 与移动数据，确认网络变化后服务能够重建；第三类是在「连接」记录中检查目标域名是否命中预期规则与节点。单次测速为绿色，只能说明测试地址在当时可访问。

Android 还应锁屏等待约 3–5 分钟，再解锁访问网页。如果只在锁屏后断网，排查方向应转向后台运行权限、电池优化和厂商省电策略，而不是继续修改节点协议。桌面端可重启浏览器或终端，确认旧代理连接和 DNS 缓存已释放。

完整排查的目标不是让状态按钮重新变成已连接，而是确认一条可重复的链路：设备获得基础网络，DNS 能解析，流量进入正确代理入口，规则选中预期策略组，节点完成出站连接，返回数据再经过同一路径交给应用。按这条链路逐层验证，通常能在八步内把问题缩小到明确范围。

客户端与配置入口

获取对应平台客户端，或继续查看首次连接、订阅导入与运行模式设置。

去下载页 看教程
下载Clash