Clash 常见问题与故障排查

Clash 是一套以规则分流和策略组为核心的代理配置体系。内核负责读取配置、建立连接、执行 DNS 与路由规则；图形客户端负责订阅导入、模式切换、日志查看和系统代理控制。选择客户端时应同时确认所用内核、操作系统支持范围以及配置字段兼容性。

原版 Clash 奠定了配置结构与规则模型，Clash Meta 在此基础上扩展了协议、DNS、规则与透明代理能力，后续项目名称调整为 mihomo。许多新客户端使用 mihomo 内核，但界面名称仍保留 Clash。常用基础字段通常可以延续使用，扩展字段则需要对应内核支持。

日常使用优先选择规则模式，由域名、IP 和规则集决定直连或代理。全局模式会把大多数连接交给当前选定策略，适合临时验证某个节点是否可用，但不宜长期作为排障结论。直连模式会绕过代理，适合确认问题是否由代理链路或配置规则引起。

客户端本身主要提供配置解析、规则分流和连接管理功能，不等同于订阅服务。订阅地址、节点可用性、流量额度和到期时间由相应服务提供方管理。导入来源不明的公开配置前，应了解其维护状态、数据处理方式与使用条件，并避免在不可信链路中传输敏感信息。

订阅通常是一个可更新的远程地址，返回完整配置或节点集合；配置文件是客户端实际加载的 YAML 内容，其中还可能包含 DNS、规则和策略组；节点只是配置中的连接条目。订阅更新会重新生成或覆盖相关内容，因此长期自定义规则时应使用覆写功能或保留独立副本。

先确认导入结果是否提示成功，再查看配置列表中是否真的生成了新配置。若配置存在但策略组为空，常见原因包括订阅返回空内容、链接已失效、返回的是网页而非配置、客户端不支持该订阅格式，或配置解析在某个字段处中断。应结合更新记录和内核日志定位具体报错行。

先在浏览器或服务方控制台确认订阅地址仍有效且未过期，再检查系统时间、网络连接和地址复制是否完整。随后查看客户端更新日志，区分连接超时、证书错误、权限拒绝与 YAML 解析失败。若旧配置仍能使用，可先保留旧副本，不要在问题未定位时连续删除全部配置。

TUN 模式需要创建虚拟网络接口并修改系统路由，因此通常要求管理员权限或已安装对应服务。Windows 可检查服务模式是否正确安装，macOS 需要确认系统扩展或网络权限，Linux 则要检查运行用户权限、TUN 设备和相关能力设置。权限修复后应完全退出客户端再重新启动。

先确认浏览器是否使用独立代理设置、扩展程序或安全软件接管了网络。然后检查系统代理地址和端口是否与客户端监听端口一致，并确认内核处于运行状态。部分应用不读取系统代理，需要使用应用内代理、TUN 模式或其他系统级接管方式；仅打开界面开关并不代表所有程序都会经过代理。

部分 UWP 应用受本机回环隔离限制，无法直接连接运行在本机地址上的代理端口。可在支持该功能的客户端中打开 UWP 回环工具，勾选需要联网的应用并保存。设置后重新启动目标应用；如果应用更新后身份发生变化，可能需要再次检查勾选状态。不要一次选择无关的全部系统组件。

全局模式通常使用名为 GLOBAL 的策略组，实际名称可能因配置而异。进入代理或策略页面，确认该组当前指向具体节点，而不是仍指向无法使用的自动选择组。选择时不要只看一次延迟结果，还应测试目标网站、连接稳定性和持续传输表现；完成验证后可切回规则模式。

延迟测试往往只验证到指定测试地址的短连接，不能代表 DNS、TLS 和目标网站链路都正常。应依次检查策略组是否选中该节点、DNS 是否返回可用地址、规则是否把目标域名分到预期策略，以及节点是否限制特定协议。日志中的规则命中、连接错误和 DNS 记录比单次延迟数值更有参考价值。

打开客户端的连接记录或实时日志，再访问目标网站，查看域名、目标地址、命中规则和最终策略。现代网页通常会同时请求主域名、静态资源域名和第三方接口，因此需要检查多条连接。若结果不符合预期，应调整规则顺序或覆写内容，而不是仅修改策略组名称。

远程订阅更新通常会重新写入订阅配置，直接编辑其中的规则、DNS 或策略组可能被覆盖。优先使用客户端提供的覆写、扩展脚本、合并配置或本地规则集功能；若客户端没有这些能力，应复制出独立的本地配置并记录来源。修改前保留可正常运行的版本，便于解析失败时回退。

移动端持续运行 VPN 或 TUN 接口会产生一定电量消耗。可减少过短的健康检查间隔，避免同时启用大量频繁更新的规则与日志，并按实际需求选择协议和模式。Android 还需检查电池优化、后台运行与常驻通知权限；iOS 的后台行为由系统统一管理，网络切换后可重新确认连接状态。

先切换到直连模式确认基础网络正常，再回到规则模式检查当前配置是否成功加载。随后确认策略组没有选中失效节点、系统代理或 TUN 状态与预期一致，并观察访问时是否产生连接日志。如果日志完全没有新记录，问题多半在流量未进入客户端；如果有错误记录，则按 DNS、规则和节点链路继续定位。

先使用同一配置中的多个节点测试，若全部超时，应优先检查本地网络、DNS、系统时间、防火墙和客户端监听状态；若只有个别节点超时，更可能是节点地址、端口或线路异常。还可以切换网络环境复测。连续快速点击延迟测试会造成额外并发，建议等待一轮结束后再比较结果。

先找到客户端日志目录，确认是界面进程崩溃还是内核启动失败。常见原因包括最后导入的配置语法错误、配置目录权限异常、内核文件缺失、旧版本残留进程占用端口，以及系统组件不满足要求。可暂时移走最近配置并重新启动，但不要直接清空全部数据，日志和旧配置有助于恢复。

记录日志给出的行号和字段名，先排查缩进、冒号、引号、重复键及列表格式。若语法本身正确，但日志提示未知字段，通常是当前内核版本不支持该扩展配置。可更新到兼容内核、让订阅提供方调整格式，或移除不兼容字段。不要盲目删除整个 DNS 或规则区块来绕过单一错误。

先确认本地网段是否被规则设为直连，并检查 TUN 路由是否覆盖了局域网地址。常见私有网段和 localhost 通常应保持直连，但实际网络也可能使用自定义地址范围。若需要让其他设备访问本机代理或开发服务，还要检查允许局域网连接、监听地址和系统防火墙；开放端口前应明确访问范围。