Clash 常见问题与故障排查

Clash 通常指规则代理项目及其生态；Mihomo 是兼容 Clash 配置格式并持续扩展功能的内核；Clash Verge Rev、Clash Plus、FlClash 等属于图形客户端。图形客户端负责配置导入、策略切换和系统代理控制，实际连接与规则匹配通常由内置内核完成。选择客户端时应同时确认维护状态、操作系统支持和所用内核。

规则模式按照配置文件中的规则顺序决定连接走直连、代理或拦截，适合日常使用。全局模式把大多数流量交给当前选定的代理策略，适合临时测试节点是否可用。直连模式绕过代理，常用于确认故障是否由代理链路引起。排障时可先用全局模式验证节点，再回到规则模式检查规则命中情况。

系统代理只影响遵循操作系统代理设置的应用，例如多数浏览器和部分桌面软件；命令行工具、游戏或自行建立网络栈的程序可能不会读取该设置。TUN 模式通过虚拟网络接口接管更广泛的流量，覆盖范围更大，但需要管理员权限，并可能与安全软件、虚拟机或其他网络过滤程序发生冲突。

代理节点保存服务器连接参数，策略组把多个节点或其他策略组合在一起，规则则把域名、IP 或网络类型交给指定策略组。一次连接通常先从上到下匹配规则，命中后进入对应策略组，再由手动选择、自动测速或故障转移逻辑确定最终节点。修改名称时要同步检查策略组引用和规则目标。

订阅配置适合由服务提供方统一维护节点和基础规则，更新方便，但重新更新时可能覆盖直接写入订阅文件的修改。本地配置适合长期保留自定义 DNS、规则和策略组。需要同时使用时，可优先采用客户端支持的覆写、扩展脚本或配置合并功能，不要直接修改会被订阅刷新替换的原始文件。

导入后先确认配置状态为已启用，并检查代理节点与策略组是否正常显示。随后选择一个可用节点，开启系统代理，使用浏览器访问常用网站验证连接。需要接管命令行工具、游戏或更多应用时，再根据平台权限开启 TUN。不要在尚未验证基础代理时同时改动 DNS、规则和端口，否则难以定位问题来源。

先在浏览器中确认订阅地址仍能返回内容，而不是登录页、错误页或空文件。随后检查系统时间、网络连接和客户端日志中的 HTTP 状态。若旧配置仍可连接，可切换到可用节点后再次更新；若地址已被服务方重置，需要获取新的订阅地址。订阅地址包含访问凭据，不应发布到截图、日志或公开文本中。

优先检查缩进是否统一使用空格、冒号后是否保留空格，以及列表项前的短横线层级是否正确。还要确认 proxies、proxy-groups 和 rules 等字段位于正确层级，被引用的策略组名称完全一致。可先恢复到最后一次可加载的配置，再逐段加入修改内容，每次保存后重新载入，以定位具体出错段落。

Windows 可先退出客户端，再使用管理员权限启动并重新安装或启用服务模式；macOS 需要在系统提示中允许网络扩展，并完成管理员授权。若权限已经授予但仍失败，应检查旧版服务是否残留、虚拟网卡是否被禁用，以及安全软件是否阻止驱动加载。处理后重启客户端，必要时重启系统以释放旧网络组件。

部分 UWP 应用默认不能访问本机代理监听端口，因此浏览器正常时，商店应用仍可能断网。可在客户端提供的 UWP 回环工具中勾选目标应用并保存；没有内置入口时，可使用 Windows 的回环豁免管理方式处理。完成后重新启动目标应用，并确认 Clash 的本地监听地址和端口没有被改动。

日常使用通常选择规则模式，让不同连接按域名和 IP 分类处理，可减少不必要的代理流量。全局模式更适合短时间验证某个节点、排除规则误判，或处理尚未加入规则的临时场景。若全局模式可用而规则模式失败，应查看连接日志中的命中规则和策略组，而不是持续保留全局模式。

先切换同一订阅中的其他节点，判断是单节点故障还是全部节点不可用。随后更新订阅并核对系统时间，因为证书连接依赖准确时间。若所有节点都超时，可暂时关闭 TUN、恢复默认 DNS，并检查本地防火墙是否拦截客户端。测速地址失败不一定代表所有网站都不可访问，应结合实际连接日志判断。

先确认更新的是当前配置实际引用的代理提供者，而不是另一个未启用配置中的同名项目。检查提供者更新时间和日志中的下载结果，然后重新载入配置。若缓存内容没有刷新，可删除该提供者的本地缓存后重新获取。通过订阅转换生成的配置还要确认转换端已经返回新内容，而不是继续提供旧缓存。

先在客户端设置中启用开机启动，再确认系统的启动项管理没有禁用该客户端。需要自动接管网络时，还应分别保存系统代理或 TUN 的启用状态。Windows 服务模式和 macOS 网络扩展可能需要单独授权。设置完成后重启系统测试一次，并确认客户端启动后成功加载了预期配置，而不是停留在空配置页面。

浏览器通常会读取系统代理，而终端程序可能忽略该设置。可为当前终端会话配置 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 环境变量，端口应对应 Clash 的 HTTP、混合或 SOCKS 监听端口；也可以使用 TUN 接管流量。设置后新开终端再测试，并检查工具自身是否配置了独立代理，避免多个代理设置互相覆盖。

先检查客户端是否正在运行、配置是否已启用，以及本地监听端口是否与系统代理中的地址一致。然后关闭其他代理软件和浏览器扩展，避免系统设置被反复改写。可访问客户端连接日志，确认请求是否进入 Clash；完全没有记录通常表示应用未使用系统代理，有记录但失败则继续检查规则、策略组和节点。

先恢复客户端默认 DNS 设置并清理操作系统 DNS 缓存，排除旧记录影响。若使用 fake-ip，检查目标程序是否兼容，并把局域网设备、打印机或特殊域名加入过滤范围。还要确认 nameserver 与 fallback 可以从当前网络访问。只有特定域名异常时，应查看 DNS 日志和规则命中结果，不要同时更换多个解析服务器。

先关闭 TUN 并退出客户端，确认直连网络是否恢复。随后检查 TUN 堆栈、自动路由和 DNS 劫持设置，并暂时停用其他虚拟网卡、VPN、流量过滤软件或虚拟机网络。若客户端异常退出后路由未恢复，可重启系统清理残留路由。重新启用时先使用默认配置测试，再逐项恢复自定义选项。

端口占用通常来自另一个正在运行的代理客户端、旧进程或重复启动的 Clash 实例。先完全退出相关程序，再通过系统网络工具查找占用 mixed-port、port 或 socks-port 的进程。可以结束冲突进程，也可以把 Clash 改到未使用端口。修改后要同步更新系统代理、浏览器和终端环境变量中的端口。

先检查当前策略组是否采用自动测速或故障转移，以及检测间隔是否过短。网络波动可能让多个节点反复改变排序，造成连接重建。可临时改为手动选择一个稳定节点，观察问题是否消失；同时检查健康检查地址、超时阈值和客户端日志。若固定节点也断开，再排查本地网络、系统休眠和服务器状态。