1. 首次连接的验证顺序

先选策略组中的节点，再测试可达性，最后检查应用请求的实际出口。客户端显示“已连接”，通常只说明内核或 VPN 接口已经启动；节点旁出现延迟，也只说明测试请求得到了响应。这两个状态都不能单独证明浏览器正在使用代理。

本文以采用 Clash 或 mihomo 内核的图形客户端为对象。不同客户端的菜单名称会有差异，操作时寻找“配置”“代理”“连接”“日志”等功能页。首次验证尽量使用一个浏览器、一个目标网站和一个手动选择的节点，避免同时切换多个选项。

  1. 在“配置”页确认订阅已经启用，而不只是下载到列表中。
  2. 在“代理”页使用规则模式，找到目标网站会使用的策略组。
  3. 测试节点并手动选择一个可用项。
  4. 开启系统代理，或按应用需要启用 TUN。
  5. 发起新的网页请求，对照出口 IP、规则和代理链。

2. 在策略组里选择实际节点

订阅导入后，列表里既可能有节点，也可能有策略组。节点包含服务器与协议参数；策略组负责选择节点，或者继续引用另一个策略组。点击顶层组不一定已经完成选择，还需要沿引用关系检查最终出口。

先区分手动选择与自动选择

类型或选项含义首次连接时的检查
select手动选择组内成员确认选中的是节点或正确的下级组
url-test根据测试结果自动选择查看当前实际使用的成员，不只看组名
fallback按成员顺序选择可用出口检查首个可用成员及其测试状态
DIRECT直连目标需要代理的请求不应最终落到此项
REJECT拒绝连接检查是否误选，或被阻断规则命中

例如，顶层“代理选择”指向“自动选择”，后者再指向某个节点，实际路径就是两层策略组加一个节点。首次排查时，如果配置提供手动节点选项，可以直接选定一个节点，减少自动切换带来的变量。组名由订阅作者定义，名称包含“代理”并不等于其中一定选中了代理节点。

规则模式与全局模式怎么选

  • 日常先用规则模式：内核按 rules 的先后顺序匹配，请求可能分别走代理、直连或拒绝。
  • 全局模式仅作对照：临时切换后，还要检查 GLOBAL 实际选择的成员。全局模式不能替代系统代理或 TUN 的流量接入。
  • 测试完恢复规则模式：不要把所有本地与国内服务长期送往同一个出口，只为让查询页显示不同地址。

如果某个网站在规则模式下直连、全局模式下能代理，优先检查规则匹配和策略组选择，不要立即重装客户端。

3. 批量测延迟，筛选可用节点

在“代理”页寻找延迟测试或刷新按钮，先测试当前策略组，再从有响应的节点中挑选。测试通常会通过节点访问指定 URL；耗时受测试地址、DNS、连接建立、TLS 以及测试实现影响，不等同于对节点服务器做一次 ICMP Ping。

  1. 确认本地网络可用，并等待订阅中的节点加载完成。
  2. 触发当前组的批量测试，等待本轮结束，避免连续点击造成额外并发。
  3. 选择一个有响应的节点，间隔约 10 秒再测两次，观察是否反复超时。
  4. 使用同一个目标网页验证加载，最后再比较相邻地区的备选节点。

以一组示意数据说明判断方式：节点 A 三次结果为 82、89、86 毫秒，节点 B 为 45 毫秒、超时、310 毫秒。首次连接更适合先选 A。B 的最低值更小，但波动和超时说明它在这几轮测试中不够稳定。这不是本站对某个服务的实测排名。

延迟也不代表下载速度。低延迟节点仍可能受带宽、拥塞、目标站点限制或出口共享情况影响。验证首次连接时，只需先确认小型 HTTPS 页面能够稳定打开，不必立刻运行大流量测速。

4. 开启流量入口：系统代理或 TUN

节点可用之后，还需要让应用把请求交给内核。系统代理适合遵循系统代理设置的浏览器和应用；TUN 通过虚拟网络接口接管流量，适用于更多不读取系统代理的应用，但仍受路由、排除项和客户端配置影响。

先用系统代理验证浏览器

在客户端开启“系统代理”。Windows 可通过“设置”→“网络和 Internet”→“代理”检查写入结果；macOS 可通过“系统设置”→“网络”→当前网络服务→“详细信息”→“代理”检查。系统版本会影响界面名称，以客户端显示的监听地址和端口为准。

下面只是一段用于理解字段的 YAML 片段，不是完整订阅。7890 是示例端口；如果客户端显示 7897，后续命令也必须使用 7897。客户端的覆写功能可能覆盖订阅值，最终以内核运行配置和实际监听结果为准。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
  • mixed-port：同一个端口接受 HTTP 与 SOCKS 代理请求。
  • allow-lan: false：不向局域网开放代理，首次本机验证通常无需开启。
  • mode: rule：由规则决定出口，不表示每个请求都会使用节点。
  • log-level: info：便于观察常规连接信息；具体展示内容由客户端与内核决定。

需要 TUN 时再开启

如果浏览器可用，但游戏或其他应用仍然直连，可以检查该应用是否支持代理，再考虑 TUN。桌面客户端通常需要服务模式或管理员权限；移动端一般需要系统 VPN 授权。不要同时运行多个接管路由的 VPN 客户端，避免默认路由和 DNS 设置互相影响。

开启 TUN 后应重新建立测试连接。已有的 TCP 连接可能继续使用原路径；仅刷新一个复用连接的页面，不一定能反映新的设置。

5. 用出口 IP 与连接日志交叉确认

可靠的确认需要两类证据：查询服务看到的来源地址，以及内核记录的实际代理链。查询页能说明该次请求从哪里出去，连接记录能说明内核为什么选择这条路径。

先记录直连基线，再比较代理结果

  1. 暂时关闭系统代理与 TUN，使用普通网络查询一次公网 IP，记录时间、地址和运营商信息。
  2. 恢复代理设置，选中刚才测试通过的节点。
  3. 重新发起查询，同时打开客户端“连接”页，搜索查询服务的域名。
  4. 检查命中的规则、目标地址与代理链；确认最终成员不是 DIRECT。

IP 查询站点本身也可能被规则分流到直连。若地址没有变化，先看日志；若地址变化但日志里没有对应请求，也要排查浏览器扩展或其他 VPN 是否在代理。IP 归属地数据库可能滞后，国家或城市文字只能作为辅助信息。

用命令排除浏览器设置干扰

以下命令以本机 HTTP 混合端口 7890 为例，通过 api.ipify.org 查询出口 IPv4。Windows 在 PowerShell 中使用 curl.exe；macOS 和 Linux 使用 curl 执行相同参数。

# Windows：不使用应用层代理
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：明确经过本机 HTTP 代理
curl.exe -4 --proxy http://127.0.0.1:7890 --noproxy "" --max-time 15 https://api.ipify.org

--noproxy "*" 只能绕过 curl 的应用层代理，不能绕过 TUN 或上游 VPN；测直连基线前仍需关闭这些接管入口。第二条命令明确使用本机端口，但内核依然会执行规则，因此它不是“强制通过远端节点”的命令。需要同时查看该请求的规则与最终出口。

怎样读取一条有效连接

在“连接”页发起筛选后，再运行一次命令。短请求可能很快结束，如果连接列表只保留活动连接，可以改看“日志”页。重点检查以下字段，而不是要求日志必须长成某种固定格式：

  • 目标：域名应与刚才访问的服务对应，端口通常为 443。
  • 规则：可能是域名规则、规则集或最终的 MATCH；记录实际命中项。
  • 代理链：确认经过预期策略组，并落到选中的节点。
  • 结果：请求返回地址，且没有持续出现认证、握手或连接超时错误。

6. 首次连接异常的排查顺序

节点有延迟，浏览器却打不开

先用显式代理的 curl 命令测试。若命令成功而浏览器失败，检查浏览器是否使用独立代理扩展、是否忽略系统代理，以及已有连接是否需要重建。若命令提示无法连接 127.0.0.1:7890，先核对监听端口和内核状态，这时请求尚未到达远端节点。

出口 IP 没变，但网页能访问

先查看查询域名是否命中 DIRECT，再核对策略组最终选择。必要时临时用全局模式做一次对照，并检查 GLOBAL 的成员；验证后恢复原模式。企业网络、上游 VPN 或同一出口服务也可能让地址比较变得不直观，代理链记录比单独的地理位置更有判断价值。

所有节点都超时

  • 确认订阅有效期、账户流量与节点列表更新状态。
  • 检查设备时间，明显错误的时间可能影响 TLS 证书验证。
  • 使用另一个网络做对照，例如从家庭 Wi-Fi 切换到手机热点。
  • 查看日志中的解析、认证或握手错误，再决定是否调整 DNS。

只有部分应用走代理

这通常需要检查流量入口，而不是重新测全部节点。确认应用是否读取系统代理、是否使用 UDP 或 QUIC，以及 TUN 是否包含该应用的路由。HTTP 代理命令成功，只证明这条 HTTP 代理路径可用，不能证明所有 UDP 流量也已接管。

提交问题时，保留客户端名称、内核版本、系统版本、监听端口、操作时间和错误类型。分享截图前遮住订阅 URL、认证参数和个人网络地址，避免把完整配置直接贴到公开讨论区。

7. 首次连接完成检查

完成以下检查后，就可以回到日常使用。后续如果只更换节点，一般不需要重新修改系统代理、DNS 或 TUN 参数。

  • 当前配置已启用，内核运行正常，监听端口与客户端显示一致。
  • 目标策略组最终指向可用节点，重复测试没有持续超时。
  • 浏览器或目标应用的流量已经进入内核。
  • 出口查询与连接记录能够相互印证，目标请求确实经过预期节点。
  • 临时测试使用的全局模式已恢复，其他 VPN 和代理入口没有冲突。

判断代理是否生效，应落实到“哪个应用、哪个目标、哪一次请求”。保留这个范围，才能区分节点可达、规则正确和流量接管三个独立问题。