Clash 常见问题
与故障排查

Clash 是规则代理生态中常见的项目名称；Clash Meta 是相关内核分支的旧称，mihomo 是该分支后续使用的名称。客户端则提供订阅管理、策略选择和系统网络设置等图形界面。界面支持某个选项，不代表内核已经启用对应功能；配置能否加载，还要看内核版本和字段支持情况。遇到配置报错时，先在客户端的关于或内核页面确认实际内核，再按其文档排查，不要仅凭安装包名称判断兼容性。

客户端负责读取配置和转发连接，本身不等于可用的代理服务。要使用远程代理，通常需要导入服务提供方给出的订阅，或自行填写有效的服务器参数；直连规则则不需要远程节点。订阅可能包含节点、策略组、规则与 DNS 设置，也可能只返回节点列表。导入前应确认格式和使用期限。订阅地址常带访问凭据，不应贴进公开评论、截图或在线转换页面；需要他人协助时，只提供隐藏敏感信息后的错误提示。

日常使用通常选择规则模式，让连接按 rules 中的顺序匹配策略。全局模式把进入内核的普通连接交给全局策略，仍需选择可用节点；它不会自动让所有应用流量进入内核。直连模式主要用于临时对照网络状态，但已配置的 DNS、TUN 路由和应用自带代理仍可能影响测试。排查时记录原模式，只改变一个选项并重新建立连接。不要把切换全局模式当作修复订阅、权限或系统代理设置的通用办法。

系统代理把本机代理地址写入操作系统设置，通常供遵循该设置的浏览器和应用使用；部分程序会忽略它。TUN 通过虚拟网卡及路由接管匹配范围内的 IP 流量，适合需要覆盖更多应用的场景，但依赖权限、路由和 DNS 配置。首次设置建议先用系统代理验证订阅与节点，再按需要启用 TUN。两者是否同时开启取决于客户端的实现，开启更多开关并不必然扩大覆盖，反而可能让排查路径变复杂。

先查看错误发生在下载阶段还是解析阶段。下载失败时核对完整地址、访问权限和当前网络；解析失败时检查返回内容是否为 YAML 配置，而不是登录页、错误网页或 Base64 节点列表。若提示未知字段或不支持的协议，再核对 mihomo 内核与客户端的支持范围。不要反复覆盖已经可用的配置，先保留副本，再用新配置测试。格式不兼容时优先向订阅提供方索取适配版本，不要把含凭据的订阅直接交给公共转换服务。

先关闭 TUN，再查看客户端是否提供服务模式、辅助服务或权限安装入口。Windows 通常需要按客户端说明安装服务或提升权限；macOS 可能需要批准辅助组件；Linux 的权限要求取决于安装方式与发行版。完成授权后重启相关服务，再启用 TUN，并从日志确认虚拟网卡与路由是否创建成功。不要为了消除错误长期关闭系统安全功能。仍有故障时，先退出其他 VPN 或虚拟网卡工具，保留系统代理作为临时连接方式。

Android 客户端通常使用 VpnService 创建本地 VPN 接口，将选定应用的连接交给代理内核处理，因此首次启动需要系统授权。这个授权不表示订阅自动有效，仍需导入配置并选择可用策略。若另一款 VPN 已连接，应先断开，因为同一用户配置下通常不能同时运行两个此类 VPN。出现授权循环时检查工作资料、始终开启 VPN 和阻止未使用 VPN 的连接等设置，确认实际生效的是当前客户端，再重新发起连接。

开机自启、启动内核和恢复系统代理是不同设置。先在客户端开启登录后启动，再分别确认是否自动加载上次配置、恢复策略和启用所需网络模式。TUN 还可能依赖后台服务先启动，不能只添加一个启动快捷方式。设置完成后进行一次完整重启，检查配置名称、运行状态和代理开关。共享设备应按用户设置，避免其他账户登录后沿用不合适的代理。若退出后网络异常，先关闭系统代理，再检查是否仍有后台内核运行。

直接编辑订阅生成的配置文件，通常会在下一次更新时被远程内容替换。需要长期保留的规则，应放进客户端支持的覆写、合并或脚本入口；不同客户端对追加和替换的处理并不相同，设置前应查看说明。修改后检查最终生效配置，确认自定义规则位于 MATCH 之前，且引用的策略组确实存在。先用单条域名规则验证，再逐步扩展。若更新后整个配置无法加载，先停用覆写恢复连接，再根据日志定位冲突字段。

规则从上到下匹配，先命中的规则决定策略，排在后面的规则不会继续参与同一次选择。先打开连接记录，核对目标域名、命中规则与最终策略组，再检查策略组当前选中的节点。若连接只显示 IP，域名规则可能缺少匹配所需的信息，应结合 DNS 与嗅探设置判断。修改规则后关闭对应应用的旧连接并重试，已有连接可能继续使用原路径。不要只看规则文件中是否出现某个域名，也要确认该文件确实已被加载。

让设备连接同一个可信局域网，在电脑客户端开启允许局域网连接，并确认监听地址不是仅本机可访问的回环地址。随后在手机或电视的网络代理设置中填写电脑的局域网 IP 和混合端口，端口以当前配置为准。电脑防火墙应只对需要的局域网范围放行。手动 HTTP 代理通常只覆盖遵循该设置的应用，不等于整台设备的全部流量。使用结束后关闭共享；不要把混合端口或外部控制端口直接映射到公网。

Fake-IP 模式由内核为 DNS 查询返回合成地址，再通过内部映射把后续连接关联回域名。它不是远程节点地址，也不是网站真实服务器地址。部分局域网发现、设备控制或强依赖真实 IP 的应用可能需要单独处理，此时应按实际域名配置 fake-ip-filter，并确认当前内核的过滤模式。不要把所有域名一并加入过滤列表，否则会改变整个 DNS 工作方式。调整后重新建立应用连接，并检查 DNS 日志与本地设备访问是否恢复。

401 或 403 通常提示访问凭据、权限或服务端访问策略有问题，应登录服务提供方的管理页面确认订阅状态，并核对是否重置过地址；这些状态码不能单独证明账户已到期。超时则需要检查本地网络、域名解析以及更新请求是否依赖已经失效的代理。优先保留旧配置，不要先删除全部节点。若客户端支持选择订阅更新方式，可分别测试直连与已有可用代理，并记录错误时间交给提供方排查，提交时隐藏订阅地址。

先暂停代理并访问平时可直连的网站，确认基础网络可用，再检查系统时间是否准确以及订阅是否仍有效。客户端的连通性测试依赖测试地址与测试方式，全部超时不一定表示所有节点都离线。选择一个节点实际访问目标网站，同时查看日志：域名解析失败优先检查 DNS，连接被拒绝或握手失败则检查服务器、端口、协议与凭据。若只有个别网站异常，应继续检查命中规则和目标站点，不要立刻重装客户端或清空全部配置。

先确认内核已成功监听混合端口，再核对操作系统中的代理地址和端口是否与客户端一致。7890 只是常用值，不是必须固定的端口；日志出现 address already in use 时，应定位占用进程，确认是否为另一个代理实例，再关闭重复实例或改用空闲端口。修改后同步更新手动代理、浏览器扩展和环境变量。若内核运行正常，检查浏览器是否使用独立代理或被组织策略管理。不要随意结束未知系统进程，也不要把外部控制端口填成代理端口。

当应用属于受网络隔离限制的 AppContainer，且需要连接本机回环代理时，可能需要单独配置回环豁免；并非所有商店应用都属于这种情况。先确认应用确实使用系统代理，而不是订阅节点或应用服务本身故障。可在管理员终端使用 CheckNetIsolation LoopbackExempt -s 查看已有豁免，再通过客户端提供的工具只为需要的应用授权。TUN 是另一种接管路径，但仍需正确路由与 DNS。不要批量豁免全部应用，排查完成后撤销不再需要的授权。