Clash 常见问题与连接排查

Clash 常用来指代一类支持规则分流的代理工具；mihomo 是相关生态中持续发展的内核，负责解析配置、匹配规则与建立连接。客户端提供界面、订阅管理和系统集成，同名字段是否可用取决于实际内核及其版本。排查前先在关于或内核信息中记录客户端名称与内核版本，不要直接把其他客户端的界面步骤照搬过来。

客户端负责运行配置，并不自动提供可用的远程代理服务。订阅通常用于获取节点、策略组和规则；本地 YAML 也可以完成这些配置。导入后还要选中对应配置，并在策略组中选择可用出站。只有规则和空策略组的配置不能凭空建立远程代理连接。订阅来源、到期时间和服务额度需要向提供方确认，不要把安装成功等同于服务已经可用。

日常使用通常选择 mode: rule，让连接按 rules 从上向下匹配；全局模式把已进入内核的连接交给全局策略；直连模式让已进入内核的连接直接出站。这些模式不等于流量接管方式：应用没有使用系统代理、显式代理或 TUN 时，切换模式也可能影响不到它。排查时先确认日志中出现该应用连接，再比较规则模式和全局模式的结果。

系统代理向遵循系统设置的应用提供代理地址，部分应用会忽略它；TUN 通过虚拟网络接口和路由接管流量，还涉及 DNS、权限与路由排除。首次配置建议先用系统代理验证订阅和节点，再按应用需求开启 TUN，不必一开始同时启用所有接管方式。TUN 是否能覆盖某类流量还取决于平台限制和具体配置，不能仅凭开关亮起判断已经接管。

Profile 通常表示客户端中的一份配置记录，它可以来自远程订阅，也可以来自本地 YAML。订阅刷新会重新获取提供方内容；覆写用于在加载时加入本地字段、规则或策略组调整。不同客户端的合并顺序并不一致，直接编辑订阅生成文件可能在更新后丢失。长期修改前先备份配置，再查看客户端的覆写说明，并检查最终生效配置，而不是只看编辑器里的原始文本。

先在配置或订阅页面确认导入已完成，并把这份配置设为当前使用项。接着查看更新结果：返回网页、登录提示或错误信息，都不能当作可用配置。再检查订阅是否仍有效，以及内容是否适配当前内核。若解析成功却看不到节点，检查 proxy-groups 是否引用了 proxies 或 proxy-providers。不要公开订阅完整地址，分享截图时也要遮住查询参数中的访问凭据。

从日志给出的行号附近检查缩进、冒号和列表短横线，尤其关注刚修改的位置。YAML 缩进使用空格，不要混入制表符；同一层字段保持对齐，字符串含特殊符号时按需加引号。行号有时指向错误之后的位置，应同时检查上一段。先恢复上次可用配置，再一次只改一项。配置能够解析不代表所有引用都有效，还需检查策略组名称和规则目标是否存在。

先关闭 TUN，确认普通代理连接正常，再按客户端提示安装或修复服务组件。Windows 检查服务状态及管理员授权，macOS 按提示批准所需网络权限，Linux 检查客户端支持的提权方式与 /dev/net/tun 是否可用。具体要求因客户端而异，不要直接放宽全部系统权限。若仍失败，关闭其他 VPN 或虚拟网卡工具后重试，并记录创建接口失败的原始日志。

把开机启动、内核启动和代理接管分开检查。部分客户端只在用户登录后启动界面，服务组件、系统代理或 TUN 未必随之启用。重启后确认客户端进程存在、当前配置已加载、所选策略仍可用，再检查系统启动项授权。还要考虑开机时网络未就绪导致的订阅拉取失败。不要通过反复添加多个启动项解决问题，重复实例反而可能争用监听端口。

先在系统关于页面查看处理器架构，再选择下载项。Windows 常见 x64 与 ARM64，macOS 区分 Apple Silicon 与 Intel，Android 常见 arm64-v8a 与 armeabi-v7a，Linux 还需确认发行版使用的包格式。架构不匹配可能表现为无法安装、无法启动或依赖兼容层运行。不要仅凭设备品牌判断架构；更新前保留配置备份，客户端安装包与单独的 mihomo 内核文件也不要混用。

确认当前模式为 mode: rule，且修改的是正在使用的配置。rules 按顺序匹配，较宽泛的规则或 MATCH 放在前面会使后面的规则没有机会命中。检查规则目标是否与策略组名称完全一致，再从连接日志确认实际域名、目标地址和命中规则。订阅更新后失效的改动应迁移到客户端支持的覆写位置；不要只把规则写入未被加载的本地备份文件。

select 用于手动选择出站，适合固定地区或需要保持出口一致的场景。url-test 按指定测试地址的结果自动选择，测试可达不代表所有业务都正常。fallback 通常按候选顺序选择可用出站，更适合有明确优先级的备援需求。先确认候选列表里的节点可用，再调整 url、interval 和 tolerance 等适用字段；不要把三种组类型理解为能提升节点本身的带宽。

先区分整份 Profile 的更新与 proxy-providers 的更新。前者通常在客户端订阅设置中管理，单位以界面标注为准；后者由配置中的 interval 控制，mihomo 的该字段使用秒。health-check.interval 用于健康检查，不等于重新下载订阅。根据提供方限制设置更新频率，失败后先手动刷新并查看错误，不要通过极短间隔重复请求，否则可能触发服务端限流。

只有原始内容格式不被当前客户端支持，且提供方没有合适的订阅格式时，才考虑转换。优先选择提供方给出的兼容入口，或在本地使用可信工具。把链接提交到在线转换服务，等于让该服务获得订阅访问能力；转换也不能修复到期、额度用尽或服务端故障。转换后检查节点类型、策略组和规则是否保留。链接意外公开后，应到提供方重置订阅地址。

打开客户端连接列表或日志，清空筛选后从目标应用发起一次新请求，查看对应域名、进程、命中规则与最终出站。旧的长连接可能继续沿用此前策略，必要时关闭目标应用后重试。网页能打开只说明这次请求成功，不能证明全部应用都被接管；单个出口查询页面也只能反映访问它的那条连接。确认路径后再关闭详细日志，避免长期保留不必要的访问记录。

先查看订阅更新日志，而不是只看节点测试结果。HTTP 401 或 403 通常与访问授权有关，404 可能是地址变更，429 表示请求过于频繁；具体含义仍需结合提供方说明。超时先检查订阅域名能否解析、当前网络及更新请求所走路径。解析失败则检查返回内容是否为网页或不兼容格式。证书错误先核对系统时间，不要直接关闭证书验证来掩盖问题。

订阅服务器和代理节点是不同的连接目标，订阅更新成功不代表节点可用。先换一个节点与测试地址交叉比较，再核对服务额度、节点参数和系统时间。如果只有某个节点失败，向提供方反馈对应时间和错误；全部节点失败时，再检查本地防火墙、其他 VPN 与当前网络限制。测试地址本身不可达也会产生超时，应结合实际业务连接判断，不要仅凭一个测试结果删除整份配置。

先检查内核是否运行，以及系统代理地址和端口是否与 mixed-port 或实际 HTTP 监听端口一致。再检查浏览器是否使用独立代理设置、扩展或企业策略，代理绕过列表是否包含目标地址。完全退出浏览器后重新打开并观察连接日志。若日志中没有请求，问题多在接管路径；若已有请求，则继续检查命中规则和出站。不要为了本机连接方便而直接开放 allow-lan。

部分使用 AppContainer 隔离的 Windows 应用默认不能访问本机回环地址，因此可能无法连接监听在 127.0.0.1 的代理。先确认该应用确实使用本地代理，再使用客户端提供的回环豁免工具，为需要的应用单独授权；工具可能需要管理员权限。不是所有 Windows 应用都受此限制，不要批量豁免全部程序。若已授权仍失败，继续检查应用自身代理行为、DNS 和防火墙，而非反复添加相同豁免。

先关闭 TUN 验证基础网络能否恢复，再检查日志中的 DNS 超时、路由冲突和接口错误。若配置启用 auto-route，确认它与其他 VPN、容器网络及局域网路由没有冲突；启用 dns-hijack 时，检查 DNS 服务是否运行、上游是否可达。局域网设备异常要同时核对路由排除和规则，单加 DIRECT 不一定能解决接管层冲突。每次只调整一项，并保留可恢复的原配置。