Clash 新手十问:订阅导入、代理模式、系统代理开关一次讲清

一、Clash、客户端与 mihomo 分别是什么？

先区分三个对象：客户端提供操作界面，内核处理网络连接，订阅提供节点或配置。安装客户端不等于已经获得可用代理节点；导入订阅后，也还需要激活配置、选择策略并接入应用流量。

Clash 原版内核与 mihomo 不是同一个持续更新的项目。mihomo 由 Clash Meta 演进而来，保留了许多 Clash 配置习惯，但增加了协议和配置能力。旧内核不一定能读取为 mihomo 编写的配置，文件扩展名同为 .yaml 也不代表兼容。

• 选择客户端：根据操作系统与处理器架构选择安装包，参照客户端对比确认内核类型。
• 确认配置：向服务提供方确认应使用 Clash 还是 Clash Meta／mihomo 格式。
• 查看报错：出现“不支持的代理类型”时，先检查内核能力，不要只反复下载同一份订阅。

不同客户端的设置菜单并不统一。下文把通用功能称为“订阅”“系统代理”“连接记录”；涉及操作系统时给出明确路径。示例端口采用 7890，实际使用前应以客户端当前显示的监听端口为准。

二、订阅链接放在哪里，怎样才算导入成功？

订阅链接应放在客户端的远程订阅导入入口，不是浏览器的代理服务器地址栏，也不是节点的服务器地址字段。远程订阅通常返回 YAML 配置；有些服务提供多种输出格式，应复制对应客户端格式的链接。

1. 在服务提供方的订阅页面复制完整链接，保留查询参数，避免复制时混入空格或换行。
2. 打开客户端的订阅管理页面，使用远程导入功能，填写链接并执行下载。
3. 下载完成后选中或激活这份配置。列表中出现配置卡片，不一定表示内核正在使用它。
4. 进入代理或策略组页面，确认能够看到节点及分组，再查看日志是否存在配置加载错误。

只有本地 YAML 文件时，应使用本地配置导入入口。若导入后没有节点，先检查下载内容是否实际为登录网页、错误提示或空文件。不要把任何能在浏览器打开的 URL 都当成订阅。

三、Rule、Global、Direct 应该怎么选？

日常使用通常选 Rule。它按规则决定每条连接走直连、代理组或其他动作。Global 用于临时验证代理链路；Direct 让进入内核的连接走直连。模式只决定已进入内核的流量如何处理，不会自动接管所有应用。

切到 Global 后仍应检查 GLOBAL 当前选择了什么。它可能选中另一个策略组，也可能选中 DIRECT，并非一切换就必然使用某个远程节点。排查结束后恢复 Rule，避免把本应直连的连接长期送往远端。

下面是规则片段，不是独立配置。Proxy 是示例策略组名，必须换成当前配置中真实存在的组名，或先定义该组：

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

MATCH 是兜底规则，通常放在最后。若提前放置，它后面的规则就没有机会匹配。GEOIP 规则还依赖相应地理数据文件可用，不能只看 YAML 语法是否正确。

四、系统代理开了，为什么应用还是不走代理？

系统代理是给愿意读取系统代理设置的应用提供入口，不是强制转发。某些浏览器使用自己的代理设置，一些命令行程序只读取环境变量，游戏或其他应用也可能直接建立连接。

先检查监听，再检查系统设置

1. 确认内核运行，找到 HTTP 或 mixed-port。mixed-port 可以在同一端口接收 HTTP 与 SOCKS 代理连接。
2. 本机应用应连接 127.0.0.1 与实际端口。不要把订阅域名填写成系统代理服务器。
3. Windows 11 可在「设置」→「网络和 Internet」→「代理」→「手动设置代理」检查地址与端口。
4. macOS 可在「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」检查 HTTP 与 HTTPS 代理设置。

用下面的命令显式指定代理，能绕开“程序是否读取系统设置”这一变量。Windows PowerShell 使用 curl.exe 可避免旧环境中的同名别名干扰；其他系统通常使用 curl。

curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

如果日志提示无法连接 127.0.0.1:7890，优先检查端口和内核进程。若已经建立代理连接，但目标请求失败，再查节点、规则与 DNS。成功返回网页响应只能说明这条请求经过了本地代理入口，不能单独证明最终使用了远程节点。

五、系统代理与 TUN 模式需要一起开吗？

不需要为了“更完整”而一开始同时开启。系统代理适合浏览器等遵循代理设置的程序；TUN 通过虚拟网络接口和路由接入流量，适合不遵循系统代理的应用，但需要处理权限、路由和 DNS 等额外问题。

• 浏览器先验证：先用系统代理确认配置、节点与规则正常，再决定是否需要 TUN。
• 应用不读代理：确认客户端支持 TUN，并按其要求安装服务或授予相应权限。
• 存在其他 VPN：先暂停另一套接管路由的软件，分开测试，避免默认路由与 DNS 接管相互影响。

mihomo 的 tun.enable 控制 TUN 开关，auto-route 涉及自动路由，dns-hijack 用于接管匹配的 DNS 流量。这些字段不是“只要打开就必定覆盖全部流量”的承诺；平台、权限、排除路由和应用自己的加密 DNS 都会影响结果。

六、节点有延迟数值，为什么网页仍打不开？

延迟测试通常是客户端通过节点请求某个测试 URL 的耗时，不等于 ICMP ping，也不代表所有目标网站都可用。测试地址能访问，不能推导出视频、登录或特定地区服务也一定可用。

按连接链路逐项确认

1. 检查策略选择：当前命中的是哪个组？手动选择组、自动测速组和故障转移组的选路方式不同。
2. 检查新请求：切换节点后重新连接。旧的 TCP 连接可能继续使用原先路径，页面缓存也可能干扰判断。
3. 检查目标差异：测试一个普通 HTTPS 页面，再测试实际故障页面，区分节点整体不可用与目标服务限制。
4. 检查日志阶段：域名解析失败、连接节点超时和目标 TLS 失败属于不同问题，不宜都归因于“节点慢”。

如果只有特定网站失败，查看该请求实际命中的规则。Rule 模式下它可能被分到 DIRECT，或者进入另一个策略组。不要只盯着节点列表中的当前选中项；连接记录才对应这一次请求。

七、订阅更新失败，要先改 DNS 吗？

先读错误，再决定改哪里。更新失败可能发生在域名解析、TCP 连接、TLS 握手、HTTP 响应或 YAML 解析阶段。只有解析相关错误才直接指向 DNS，状态码和配置语法错误不会因为换 DNS 自动修复。

有的客户端允许选择订阅更新是否通过代理，有的使用独立的下载实现。网页能打开不代表更新器走同一路径。应在客户端说明中确认下载行为，不要假定开启系统代理后所有后台更新都会使用它。

保留最后一份可用配置，再尝试更新。不要在订阅不可访问时先删除唯一可用的配置，也不要为了消除 TLS 报错直接关闭证书验证。遇到证书时间错误时，先检查系统日期、时区和网络环境。

八、DNS、Fake-IP 与“DNS 泄漏”怎么理解？

DNS 负责把域名解析为地址。mihomo 的 Fake-IP 模式会为域名分配映射地址，再结合内部映射处理后续连接；常见配置使用 198.18.0.0/16。看到这类地址，不应立即判断为节点故障或域名被错误解析。

DNS 泄漏关注的是查询是否通过了非预期的解析路径。检测页显示的解析器所在地，不一定等于浏览器代理节点所在地；远程解析服务、缓存和服务商的网络出口都会影响显示。只凭一个地区标签，无法完整证明泄漏或安全。

• 先确定系统 DNS 请求是否进入内核，再看内核使用的 nameserver 与域名级 nameserver-policy。
• 浏览器自己的安全 DNS／DoH 可能使用独立连接，需结合实际路由检查，而不是只改系统 DNS。
• 部分局域网服务或应用不适合 Fake-IP，可按需要配置 fake-ip-filter，不要直接把所有域名排除。

新手宜先使用来源明确、与当前内核匹配的 DNS 配置，再针对具体故障修改。DNS 字段互相关联，盲目拼接多份教程容易出现上游解析循环。字段说明可查阅配置进阶与 mihomo DNS 文档。

九、怎样确认某个网站实际走了哪条规则？

在客户端的连接页面找到目标请求，查看目标域名、命中规则和策略链。界面名称会有差异，但核心是把“一次请求”与“一条路由结果”对应起来，而不是用外网 IP 检测页推断所有应用。

1. 暂停不相关下载，减少背景连接干扰。
2. 打开连接记录，再在浏览器中重新访问目标页面。
3. 按域名或进程筛选，确认目标连接的规则与最终策略。
4. 修改规则后重新加载配置，并建立新连接复测。

若需要临时增加域名规则，应放在可能提前命中的宽泛规则之前。以下片段让 example.com 及其子域名直连，只用于说明语法；它不是整份配置，也不会影响无关域名：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy

Proxy 仍须对应真实策略组。远程订阅更新可能覆盖直接编辑的内容，长期自定义应使用客户端提供的覆写、合并或脚本机制，并检查生成后的生效配置。不同客户端的合并顺序不一样，不要仅凭编辑器里显示的片段判断最终规则。

十、退出客户端后断网，怎样恢复？

常见原因是本地代理进程已停止，但系统仍指向它的监听地址。此时应用继续连接 127.0.0.1:7890，当然无法得到响应。先恢复网络入口，再排查配置，不必立刻重装客户端。

按从小到大的范围恢复

1. 若客户端还能打开，先关闭系统代理和 TUN，再正常退出。
2. Windows 11 进入「设置」→「网络和 Internet」→「代理」，关闭不再使用的手动代理；单位管理的代理配置应先向管理员确认。
3. macOS 进入当前网络服务的「详细信息」→「代理」，取消已经失效的代理项目。
4. 若只有终端失败，检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量及工具自己的代理配置。
5. 若 TUN 异常退出后仍无法联网，重新启动客户端并正常关闭 TUN；必要时重启系统，使网络接口和路由重新建立。

Linux 或 macOS 的当前 shell 可先查看代理环境变量。下面的命令只读取并筛选，不会修改系统设置；变量内容可能包含账户信息，分享输出前应脱敏：

env | grep -iE '^(http|https|all|no)_proxy='

不要一开始就执行网络重置或清空全部防火墙规则。它们可能影响其他 VPN、虚拟机或企业网络。恢复联网后，按“配置已激活 → 内核已监听 → 应用已接入 → 规则选路正确”的顺序重新验证，通常能把故障限定在一个环节。