Clash 常见问题
配置与连接排查

Clash 通常指代理内核及其配置生态，mihomo 是这一生态中持续演进的内核项目。Clash Verge Rev、FlClash 等客户端提供配置导入、策略选择和系统集成界面，实际流量处理由内核承担。同一份配置能否导入，取决于客户端内置的内核版本及字段支持，不能只看应用名称。反馈兼容问题时，应同时记录客户端名称、客户端版本和内核版本。

客户端提供流量接管与规则执行能力，安装包本身不等于可用的代理服务。实际连接通常需要服务提供方交付的订阅链接，或自行维护的代理服务器参数。导入后先确认配置已被激活，再检查策略组是否有可选出站。不要把普通网站地址当作订阅地址，也不要将订阅链接提交到来源不明的在线转换页面；链接可能包含可访问账户资源的凭据。

规则模式按配置中的规则顺序决定出站，适合需要区分不同网站和应用的日常使用。全局模式将交给内核处理的连接统一交给全局策略选择，不能保证未被接管的应用也走代理。直连模式则让交给内核的连接直接访问目标。排查时可以短暂切到全局模式做对照，但测试后应恢复原模式；全局可用而规则不可用，通常需要检查规则命中和对应策略组。

系统代理向遵循系统设置的应用声明代理地址，TUN 则通过虚拟网络接口和路由接管更多连接。两者不是必须同时开启，也不是功能完全相同。初次配置建议先只开系统代理，确认浏览器能正常连接，再按游戏、命令行或其他应用的需要尝试 TUN。某些客户端允许两者并用，但出现异常时应一次只保留一种接管方式，避免与其他 VPN 或代理工具叠加后难以定位。

公开分享的代理出站可能随时失效，其运营方、流量策略和维护周期往往难以确认，不宜作为长期可用性的依据。代理也不能替代网站自身的加密保护，登录敏感账户时应确认 HTTPS 正常，拒绝来历不明的证书安装要求。遇到连接失败，应先判断是单个出站失效还是本地接管异常，不要为了更换出站而反复安装陌生客户端。使用网络服务时还需遵守所在地法律和服务条款。

先到服务提供方的账户页面确认订阅是否到期、链接是否重置，再检查复制时是否带入空格或缺少查询参数。403 通常表示请求被拒绝，但也可能与访问策略或客户端标识有关，应结合提供方说明判断。若只有通过代理更新才失败，可在客户端支持时尝试直连更新；若直连无法访问，再使用已确认可用的出站。仍失败时保留状态码与时间，联系提供方，不要公开完整订阅链接。

先区分文件格式错误与内核兼容问题。YAML 依赖缩进层级，使用空格而非制表符，并检查冒号、列表短横线和引号是否成对。若日志指出某字段无法识别，核对配置所需的内核类型与当前内核版本；从网页下载到的登录页或错误页也不能作为配置导入。修改前保留原文件，每次只调整一处后重新验证。订阅生成的配置应优先通过客户端覆写功能修改，以免更新时丢失改动。

先确认当前客户端和系统支持所选 TUN 实现。Windows 客户端通常需要安装并启动其提供的服务模式，macOS 可能需要按系统提示授权辅助服务，Linux 则应按客户端文档配置虚拟接口和路由所需权限。不要直接给所有程序授予高权限。完成授权后重启内核，再查看是否成功创建接口；若仍失败，关闭其他 VPN 后重试，并记录接口创建或路由添加的原始报错。

检查系统代理地址是否指向本机，以及端口是否与当前配置的监听端口一致，再确认内核正在运行。浏览器扩展、独立代理设置和组织策略可能覆盖系统设置，应先停用冲突项再测试。打开客户端连接记录，若访问网站时没有新增连接，重点检查流量入口；若已有记录却选择直连，重点检查模式和规则。不要只凭出口查询页面判断故障，缓存、网站分流和浏览器行为都会影响结果。

端口占用时先退出重复启动的客户端，或查明占用进程后为 mixed-port 选择未被使用的端口，同时更新应用中的代理地址。HTTP 代理与 SOCKS 代理不能任意混用，应按应用支持的协议填写。终端工具不一定读取系统代理，可能需要单独设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。排查时优先临时设置，确认生效后再决定是否持久化，并在关闭客户端前清理不再需要的环境变量。

多数策略切换首先影响新建连接，已经建立的连接可能继续沿用原出站。可以暂停播放、关闭对应网页后重新打开，或在客户端连接面板中只关闭相关连接，再观察新记录的策略链。还要确认访问目标确实命中刚修改的策略组；某些配置会为视频、下载和其他流量设置不同分组。不要一次关闭全部连接作为日常操作，否则可能中断文件传输、会议或其他仍在进行的任务。

在连接记录中按目标域名或应用查找刚发起的请求，查看命中的规则、策略组以及最终出站。规则通常从上到下匹配，较宽泛的规则如果放在前面，可能抢先覆盖后面的精确规则。调整前先记录目标域名和当前命中结果，再把必要的精确规则放到合适位置。MATCH 通常作为末尾兜底。涉及 GEOSITE 或规则集时，还应检查对应数据文件和 rule-providers 是否成功加载。

直接编辑订阅生成的文件，下一次更新时可能被远程内容覆盖。需要长期保留的规则，应使用客户端提供的覆写、合并或脚本扩展功能，并核对其执行顺序；不同客户端的入口和合并机制并不相同。保存前导出备份，更新后检查最终生效配置，而不只是查看编辑器里的文本。新增规则引用的策略组必须真实存在，否则可能出现加载失败或出站引用错误。

延迟测试通常只反映一次请求的往返情况，不能代表持续带宽、拥塞程度或特定网站的访问质量。先固定同一个下载目标，对比直连与不同出站，再检查本地无线网络、后台下载和服务器限速。如果只有某个网站慢，观察该网站实际命中的出站与解析地址，不要只比较测试按钮的结果。排查时保持测试条件一致，避免同时更换 DNS、模式和节点，导致无法判断是哪一项产生影响。

通常不需要。酒店、校园或交通场所的网络可能要求先完成网页登录认证，而代理或 TUN 会影响认证页面的打开。先暂时关闭接管，完成网络认证并确认普通网页可访问，再恢复原有设置。如果换网络后部分连接仍异常，可重建相关连接并检查 DNS 状态。不要因为一次网络切换就删除原配置；只有账户链接确实失效或提供方明确要求更换时，才重新导入订阅。

先关闭代理确认基础网络可用，再确认订阅更新正常、账户状态有效，以及设备日期与时间准确。随后选择另一个出站访问同一目标：只有单个出站失败，优先联系服务提供方；所有出站都失败，再检查防火墙、代理端口和其他 VPN 冲突。最后结合日志区分服务器连接超时、域名解析失败与目标站点拒绝。不要连续重复测速代替定位，也不要把所有超时都归因于客户端。

先检查配置中的 DNS 上游是否可达，以及连接代理服务器本身所需的域名能否解析，避免解析请求依赖尚未建立的代理而形成循环。若仅个别应用异常，可对照应用是否自带加密 DNS、是否缓存旧地址，以及是否兼容 fake-ip。完成调整后再按客户端提供的方法清理 DNS 缓存并重建连接。不要随意叠加多个 DNS 劫持工具；切换 DNS 模式前应保存原配置，并核对 TUN 路由是否同时变化。

部分使用 AppContainer 隔离的应用默认不能访问本机回环地址，即使浏览器可用，也可能无法连接本地代理。先确认该应用是否属于这种情况，再使用客户端提供的 UWP 回环豁免入口，只为需要的应用添加许可。管理员可用系统命令 CheckNetIsolation LoopbackExempt -s 查看现有豁免。此问题不适用于所有商店应用；若已许可仍失败，应继续检查应用是否读取系统代理，以及连接是否进入内核。

先检查系统是否仍保留指向本机的手动代理，若内核已经退出，该地址就无法提供服务，应关闭残留代理或重新启动客户端后正常关闭接管。若之前使用 TUN，再检查虚拟接口、路由和 DNS 是否恢复，必要时用客户端的修复入口处理，然后重新连接网络。企业网络可能本来就需要指定代理，修改前应记录原设置。重置全部网络设置应放在后面，避免丢失已有 VPN、静态地址或工作网络配置。

先记录系统、客户端与内核版本、所用模式和问题发生时间，再复现一次并截取前后相关日志。临时提高日志级别后应及时恢复，避免长期记录过多访问细节。提交前删除订阅地址、认证参数、服务器凭据和不希望公开的域名或 IP，必要时只保留错误类型与规则链。配置示例只提供最小复现片段，并注明已删减内容；如果订阅链接曾经公开，应在服务提供方处重置链接，而不只是删除帖子。