Clash 首次连接教程

先确认订阅配置已经启用

订阅导入成功、节点出现、代理生效是三个不同的状态。订阅负责提供节点、策略组和规则；客户端还需要加载这份配置，并让应用的连接进入内核。首次连接时应按这个顺序检查，避免一看到网页打不开就反复更换订阅。

1. 进入客户端的「配置」或「Profiles」页面，找到刚导入的订阅，确认它处于已选中、使用中或激活状态。
2. 查看最近一次更新结果。如果提示解析失败、下载失败或配置加载失败，先处理这条错误；列表里残留的节点可能来自旧配置。
3. 进入「代理」或「Proxies」页面，确认能看到策略组以及组内节点，而不只是 DIRECT 和 REJECT。
4. 在「日志」页面确认内核没有持续重启，且没有端口占用或不支持协议字段的错误。

本文以桌面客户端常见界面为例。「配置 → 选中订阅」「代理 → 规则」「连接」「日志」是功能定位，不同客户端的名称和位置可能略有差别。使用 Clash Meta（mihomo）内核的客户端可以支持更多协议与配置字段，但前提仍是当前内核能成功解析订阅内容。

切换规则模式并选择实际出口

首次连接先用规则模式

在「代理」页面找到模式切换，选择「规则 / Rule」。规则模式按配置中的顺序匹配连接，首条命中的规则决定使用哪个出口或策略组。「全局 / Global」通常让进入内核的连接使用全局策略组；「直连 / Direct」则直接访问目标。全局模式不是接管所有应用的开关，应用仍然需要先把流量送进内核。

首次使用不建议同时改模式、规则和 DNS。先沿用订阅提供的规则，完成一次能够重复的访问测试，再根据具体站点调整分流。如果当前配置只提供节点而没有所需规则，应先确认客户端使用的配置模板，而不是假定所有订阅都有相同的分流行为。

展开策略组，确认最终选中的节点

1. 找到用于代理访问的主策略组，名称可能是「代理选择」「节点选择」或订阅自定义名称。
2. 展开策略组，选择一个具体节点。不要把 DIRECT 当作代理节点；选择它会直连。
3. 如果选中的是「自动选择」之类的子组，继续查看该子组当前实际使用的节点。
4. 如果规则为某个服务指定了独立策略组，还要检查该服务组的选择。修改主策略组不一定影响它。

例如，主策略组选择了节点 A，但视频服务规则指向另一个策略组，而后者选择了节点 B，那么访问视频服务仍然会走 B。节点名称中包含的地区只是标识，实际公网出口还需通过连接记录与 IP 查询验证。

测试延迟：先判断可用性

点击节点或策略组旁的「测试延迟」「测速」按钮，等待本轮测试完成。这类测试通常是通过候选代理向指定测试 URL 发起请求，记录请求耗时，并不是持续下载文件测量带宽。测试 URL、超时时间以及是否复用连接都会影响结果。

表内数字仅用于解释结果，不是本站实测数据。可以间隔数秒测试 2～3 次：偶尔一次超时与连续全部超时应分开处理。若只有一个节点失败，优先换节点；若所有节点同时失败，先检查本地网络、系统时间、订阅有效期和内核日志。

开启系统代理，让浏览器流量进入内核

Windows、macOS 桌面环境中，首次测试可先使用系统代理，不急于开启 TUN。在客户端「设置 → 系统代理」或首页的「系统代理」开关中启用接管，再查看「设置 → 端口」中的实际监听值。混合端口常见示例是 7890，但订阅、客户端默认值或个人修改都可能改变它，应以当前界面为准。

• Windows：打开系统「设置 → 网络和 Internet → 代理」，确认代理设置与客户端一致。手动代理常见形式是地址 127.0.0.1、端口 7890；若客户端使用自动配置脚本，则查看对应脚本设置，不能仅凭手动代理开关判断。
• macOS：打开「系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理」，核对客户端管理的 HTTP、HTTPS 或 SOCKS 代理项目与端口。
• 浏览器：先用遵循系统代理的浏览器测试。Firefox 可在「设置 → 常规 → 网络设置 → 设置」选择「使用系统代理设置」。代理扩展或独立代理配置可能覆盖系统设置。

如果同时运行其他代理、VPN 或网络调试工具，先停用它们的流量接管功能，再进行本轮验证。不要为了排查而关闭整个系统防火墙。客户端退出后网页突然全部打不开，通常应先检查系统代理是否仍指向已经停止监听的本地端口。

Android 与 TUN 的区别

Android 客户端一般通过系统 VPN 授权接管流量，首次启动连接时需要确认系统权限弹窗；这不同于桌面端设置一个 HTTP 代理。分应用代理、绕过应用列表也会影响测试浏览器是否被接管。桌面端 TUN 则涉及虚拟网卡、路由和权限，适合在基础连接验证后，再测试不遵循系统代理的应用。

用连接记录验证规则与节点

打开客户端「连接 / Connections」，然后在浏览器中访问一个新的 HTTPS 页面。尽量使用新打开的标签页；缓存页面、已有长连接和后台请求都会干扰判断。记录访问时间，在连接列表中找到对应域名或目标地址。

1. 核对目标：确认记录对应刚访问的站点，而不是客户端自己的延迟测试请求。
2. 核对规则：查看命中的规则类型及内容，例如 DOMAIN-SUFFIX 或最终兜底的 MATCH。界面展示程度取决于客户端。
3. 核对策略链：确认连接使用的是预期策略组，并最终落到具体代理节点，而非 DIRECT 或 REJECT。
4. 核对状态：观察连接是否有数据传输，是否立刻报错或关闭，再结合页面能否正常打开判断。

如果连接列表没有任何对应记录，优先排查浏览器代理设置、绕过列表和端口，而不是调整节点。若记录命中 DIRECT，说明这条连接进入了内核但被规则安排直连；若命中 REJECT，则应定位拦截它的规则。

需要更多信息时，临时把日志级别切到 info；仍不足再短时使用 debug，复现一次后恢复。日志可能包含访问域名，分享前应删去个人信息。通过 IP 规则、域名规则和 DNS 映射得到的日志形式不一定相同，不能只凭记录显示 IP 而非域名，就断定发生了 DNS 异常。

查询公网 IP，交叉确认出口

在同一个测试浏览器中访问公网 IP 查询服务，例如在地址栏输入 https://api.ipify.org。先查看客户端中这次查询请求的规则和策略链，再读取网页返回的地址。只有这次查询确实走了目标代理，它才适合用于判断代理出口。

• 出口符合预期：查询请求走了所选节点，返回该节点的公网出口，且目标页面正常访问，可认为这条浏览器测试链路已生效。
• 仍显示本地出口：先看查询请求是否命中直连。规则模式允许部分站点直连，不能因为一次 IP 查询不变就认定全部代理失效。
• 地区与节点名称不同：IP 地理库可能滞后，服务也可能使用不同的入口和出口。地区标签不是准确到城市的路由证明。

如果需要直连基线，可先记下现有开关状态，临时关闭本客户端的系统代理与 TUN，且确认没有其他 VPN 接管，再查询一次；完成后恢复原设置。不要在关闭接管的状态下继续访问需要代理的业务，也不要只比较两个不同浏览器的结果，因为它们可能使用不同代理配置。

可选：用命令行隔离本地代理端口

下面是 Windows 命令提示符或 PowerShell 可用的示例，假设实际 HTTP 或混合监听端口为 7890。端口不同必须替换；纯 SOCKS 端口不能直接套用这个 HTTP 代理参数。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

macOS、Linux 通常将 curl.exe 改为 curl。该命令明确指定本地代理，并清空本次请求的代理绕过列表，不依赖浏览器的系统代理设置。它成功而浏览器失败时，应优先检查浏览器；提示无法连接 127.0.0.1:7890 时，应检查端口、内核运行状态和监听地址。不要添加跳过证书验证的参数来掩盖 TLS 错误。

首次连接结果与后续检查

完成首次验证后，保存一份简短记录：当前配置名称、规则模式、主策略组选择、实际端口和成功访问的时间。后续修改规则或启用 TUN 时，一次只改变一项，并使用同一个站点复测，便于确认是哪项修改带来变化。

最终检查应同时满足三个条件：应用请求进入内核、规则把它交给预期节点、目标请求实际完成。单独的绿色开关、延迟数字或 IP 查询都不足以覆盖整条链路。需要重新整理配置时，可按使用指南核对订阅与系统代理；遇到订阅更新问题，可查看帮助中心的订阅更新说明。