一、连接前先确认：配置已启用，内核正在运行

导入订阅只是把节点和规则交给客户端，并不代表浏览器已经开始使用代理。一次完整连接包含四个环节：启用配置、选择策略、让应用流量进入内核、确认请求从预期节点发出。少了任意一步，都可能出现“节点有延迟，但网页打不开”的情况。

本文以 Clash Verge Rev 桌面端常见界面为例。不同版本的按钮名称和设置分组可能略有调整，应以当前安装版本的实际界面为准。Clash Verge Rev 负责配置与界面管理，mihomo 是执行代理连接、DNS 处理和规则匹配的内核。

  1. 进入侧边栏「配置」，确认刚导入的订阅存在，并已被选为当前配置。只有卡片出现在列表中，不等于已经启用。
  2. 进入「代理」，确认能看到策略组及组内节点，而不只是一个空页面。组名由订阅提供，可能叫“节点选择”“代理”或其他名称。
  3. 打开「日志」，检查最近一次配置加载是否成功。如果出现 YAML 解析错误、端口监听失败或内核反复退出，应先解决这些问题。
  4. 记录当前代理监听地址和端口。下文命令以 127.0.0.1:7897 为示例；实际端口以客户端设置中的混合端口为准，不能直接照抄。

二、在策略组中选节点，而不是只点节点名称

打开「代理」，先确认当前工作模式。首次使用建议保持 Rule（规则）模式：请求按配置中的规则分别进入 DIRECT、代理策略组或 REJECT。Global（全局）模式会将进入内核的请求交给全局策略，但不会自动接管所有应用；Direct（直连）模式也不适合用来验证代理出口。

找到实际被规则引用的策略组

策略组是规则与节点之间的一层选择。假设规则把某个域名交给“节点选择”，而该组当前选中 DIRECT，即使另一个组里已经选了海外节点，这次请求仍然可能直连。应展开承担目标网站流量的组，再选择其中一个具体节点。

  • select：手动选择。首次验证适合使用这种组，选定一个节点后，测试对象比较稳定。
  • url-test：按健康检查结果自动选择节点。看到的当前节点可能随测试结果变化，不能把上一次显示的选择当作永久状态。
  • fallback：通常按配置顺序选择可用节点，不一定优先使用延迟最低的节点。

如果组中还包含其他策略组，需要继续展开，直到确认最终使用的节点。节点名称里的国家、倍率和用途只是提供方填写的说明，不是实际出口位置的验证结果。首次测试可先选一个位置合适、状态正常的普通节点，再做延迟比较。

三、测延迟：先看是否可达，再看是否稳定

在策略组或节点旁点击延迟测试按钮。客户端通常会通过被测节点访问测试 URL，再显示请求耗时；具体测量范围取决于内核和测试实现。它不是简单的 ICMP ping，也不等于下载速度，更不能证明所有网站都能访问。

控制变量，连续测试三次

  1. 先暂停大文件下载和测速任务，避免本地带宽占满影响结果。
  2. 对同一个组测试三次，每次间隔约 5～10 秒，观察候选节点是否反复超时。
  3. 优先选择多次都能完成测试的节点，再比较延迟。不要仅凭一次最低值决定。

例如，节点 A 三次显示 86、92、89 毫秒，节点 B 显示 45 毫秒、超时、410 毫秒，首次连接更适合先选 A。这些数字只是结果判读示例，不是本文实测数据。稳定性比单次低延迟更能反映短时间内的可用情况。

遇到 timeout 时先分清测试失败范围

timeout 表示本次测试在规定时间内没有完成，并不直接等于订阅失效。测试地址解析失败、节点线路不可达、测试站点拒绝访问，都可能产生类似结果。如果所有节点同时超时，应先检查本机网络、订阅有效期和日志，而不是连续切换几十个节点。

若配置使用 https://www.gstatic.com/generate_204 作为测试地址，预期响应是 HTTP 204，即请求成功但没有响应正文。这个地址的可达性只是一个观察点。即使延迟正常，也仍需用目标网站完成下一步验证。

四、开启系统代理，让浏览器请求进入内核

选择好节点后，进入「设置」，找到并开启「系统代理」。如果设置页按分组展示，系统代理通常位于网络相关区域；不要把「允许局域网连接」当成系统代理开关，后者用于让其他设备访问本机代理端口，不是首次本机上网的必要条件。

系统代理的作用是把操作系统的代理设置指向本地监听端口。Windows 上可到系统「设置」→「网络和 Internet」→「代理」检查；macOS 上可到「系统设置」→「网络」→当前网络连接→「详细信息」→「代理」查看。应核对地址和端口是否与客户端实际监听值一致。

  • Chrome、Edge 等浏览器通常会使用系统代理，但浏览器扩展、启动参数或企业策略可能覆盖这一行为。
  • Firefox 可以单独设置代理。若没有跟随系统，应检查「设置」→「常规」→「网络设置」，选择使用系统代理设置。
  • 命令行工具和部分游戏不一定读取系统代理。浏览器能访问，不代表所有程序都已接管。

五、用连接页确认：请求命中了什么规则、走了哪个节点

保持客户端「连接」页打开，再在浏览器中发起一个新的网页请求。不要只观察已经加载完的静态页面；可以关闭原标签后重新访问，或使用新的隐私窗口减少缓存和旧连接的干扰。隐私窗口本身不会改变代理设置。

在连接列表中按域名筛选目标请求，展开连接详情。页面可能把相关字段显示为“规则”“匹配规则”“链路”或“代理链”，重点是确认以下三项信息。

检查项 需要确认的内容 结果含义
目标地址 域名或目标 IP 与刚发起的请求对应 避免把后台更新请求当作本次测试
命中规则 例如 DOMAIN-SUFFIX、GEOSITE 或 MATCH 说明当前配置为何选择这条策略
代理链路 策略组以及最终节点，或 DIRECT、REJECT 判断这次请求实际走代理、直连还是被拒绝

国内网站命中 DIRECT，并不一定是故障；规则分流本来就可以让部分流量直连。但如果正在验证的目标本应走代理，却显示 DIRECT，应检查命中规则和策略组选择，而不是只重新开启系统代理。

连接页完全没有新记录时，先检查浏览器是否真的使用本地代理，以及当前列表是否设置了过滤条件。短请求可能很快消失，可先打开连接页再刷新目标页面，并结合日志观察。不要因为列表一时为空，就直接认定节点不可用。

六、对比出口 IP：把“走了代理”落实到结果

连接链路显示节点后，再访问 IP 查询服务，记录公网出口地址。可先关闭系统代理并确认 TUN 关闭，重新查询一次作为直连基线；随后恢复系统代理，新建页面再次查询。比较时尽量使用同一个查询服务，避免不同数据库对地区的标注不一致。

IP 查询页本身也受规则控制。如果它命中 DIRECT，查到本地出口是预期结果，不能据此判断其他网站没有走代理。应同时检查这次 IP 查询请求的连接记录。IP 所属地区只是辅助信息，地址是否变化、链路是否为目标节点更重要。

用显式代理命令隔离浏览器设置问题

如果浏览器结果不清楚，可以使用下面两条命令对比 IPv4 出口。Windows 的 PowerShell 建议使用 curl.exe 调用可执行程序；macOS 和 Linux 使用 curl。把示例端口 7897 替换为客户端实际混合端口。

# Windows：不使用 curl 的代理配置，查询直连基线
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：显式连接本地 HTTP 代理
curl.exe -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org
# macOS / Linux
curl -4 --noproxy "*" --max-time 15 https://api.ipify.org
curl -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

--max-time 15 把单次请求总时限设为 15 秒；-4 让两次比较都使用 IPv4，避免把 IPv4 与 IPv6 地址差异误认成代理效果。代理命令里的空 --noproxy 用于取消环境中的绕过列表。但显式代理仍然遵守内核的路由模式和规则，不会强制每个目标都从所选节点发出。

直连基线还要求 TUN 和其他 VPN 处于关闭状态；--noproxy 只能绕过 curl 的代理配置，不能绕过系统级流量接管。如果命令提示无法连接 127.0.0.1，优先检查监听端口和内核运行状态。如果显式代理成功而浏览器失败，排查重点应转向浏览器设置或扩展。

七、首次连接验收与后续 TUN 测试

一次可靠的验证，应当有三类相互对应的证据：节点测试能够完成，目标请求的连接链路指向预期节点，出口查询与这条链路一致。只有“网页能打开”或“延迟显示绿色”，证据都不够完整。

  • 延迟正常，网页打不开：检查系统代理、实际监听端口，以及目标域名在连接页命中的规则。
  • 网页正常，出口没有变化：先看 IP 查询请求是否被分流到 DIRECT，再检查浏览器是否绕过代理。
  • 出口已变化，某个网站仍失败：查看该站点连接与日志，考虑节点出口限制、DNS 结果或站点自身访问策略。
  • 浏览器成功，其他应用失败：确认该应用是否支持系统代理；有需要时，再评估 TUN 接管。

TUN 模式通过虚拟网络接口接管更多 IP 流量，适合不读取系统代理的应用，但它与系统代理不是同一个功能。启用时可能需要服务模式或管理员权限，也可能与其他 VPN 的路由发生冲突。建议保留已成功的配置和节点，只改变接管方式，再针对目标应用重新检查连接链路。

最后记录当前配置名称、策略组选择和混合端口，便于下次对照。若需要帮助，可以提供客户端版本、系统版本、脱敏后的错误日志与连接结果；不要公开订阅 URL、节点密码或访问令牌。完成这些检查后，才算确认了“请求进入内核，并按预期从代理节点发出”。