ofoNET 发布页

ofoNET 测速：用 Clash Verge Rev 测试节点延迟与稳定性

更新于 2026-10-18 · ofonet.online

简答：ofoNET 测速建议使用 Clash Verge Rev 的节点延迟测试功能：先固定设备和网络，确认测试 URL，再逐个测试节点并记录延迟、超时和实际访问表现。客户端显示的延迟是通过代理访问 HTTP 测试地址的耗时，不等同于 ICMP ping；选择节点时应同时观察稳定性、丢包和业务连接是否中断。

定义：ofoNET 测速是对当前客户端中节点连接质量进行对比测试，通常包括 HTTP 延迟、超时、实际访问稳定性以及必要时的本地网络丢包排查。

先确认：测速入口和节点信息以官方为准

搜索“ofoNET 测速”的用户，通常是想知道当前哪个节点更快、更稳定，或者连接变慢时如何判断问题位置。本文不核实任何特定品牌的官网、订阅入口、节点状态、价格或可用性；相关入口和节点信息请以对应官方页面及客户端实际显示为准。

本文选用 Clash Verge Rev 作为示例，重点解决一个具体问题：如何在桌面客户端中测试节点延迟，并把结果用于初步筛选。Clash Verge Rev 项目公开说明显示，测试代理或代理组时，会通过代理向测试地址发送 HTTP 请求；测试地址也可以由用户配置。因此，客户端中的“延迟”不能直接当成 ICMP ping 值使用。可参考 Clash Verge Rev 的延迟测试说明。

Clash Verge Rev 测速前的准备

  1. 固定网络环境：尽量使用同一台设备、同一个 Wi-Fi 或有线网络，不要在测试过程中切换到手机热点。
  2. 暂停后台流量：暂时停止云盘同步、系统更新、视频播放和其他下载任务，避免带宽被占用。
  3. 更新订阅后再测试：如果节点列表刚发生变化，先在客户端完成订阅更新，确认节点名称和分组已经正常显示。
  4. 避免多个代理软件叠加：关闭其他代理客户端、网络加速软件或重复启用的系统代理，防止测试请求走错路径。
  5. 记录测试条件：记下操作系统、客户端版本、网络类型和测试时间。测速结果只代表当时条件下的表现，不应直接当作长期排名。

如果你刚修改过 DNS、TUN、规则或代理模式，建议先保留原设置，完成一轮基准测试后再一次只修改一个项目。这样出现变化时更容易复现。

具体步骤：在 Clash Verge Rev 中测试节点延迟

  1. 打开代理页面：启动 Clash Verge Rev，进入显示节点或代理组的页面，找到需要比较的节点。
  2. 检查测试地址：在设置或杂项配置中找到延迟测试地址。优先使用能够稳定返回结果的 HTTP 或 HTTPS 地址；如果某个测试地址在当前网络下无法访问，所有节点都可能显示超时，此时不要马上判断节点失效。
  3. 发起单节点测试：点击节点旁的延迟测试或测试按钮，等待结果返回。先测试少量候选节点，确认测试流程正常后再批量测试。
  4. 记录结果：记录节点名称、延迟数值、是否超时以及测试时间。不要只记录“最快节点”，还要保留出现超时或延迟大幅波动的节点。
  5. 重复测试：对候选节点连续测试两到三轮。每轮之间尽量保持设备、网络、测试地址和后台流量不变。
  6. 做实际访问复测：选择延迟较低且结果稳定的节点，打开你实际需要使用的网页、办公系统或文件服务，观察首次连接、连续加载和长时间连接是否正常。

如果你使用的是基于 Mihomo 的配置，也可以在策略组中使用 url-test。官方文档说明，url 是健康检查地址，interval 是定时检查间隔，timeout 是超时时间，tolerance 用于设置节点切换容差。可参考 Mihomo 的 url-test 文档 和 代理组通用字段说明。

示例配置如下，字段名称以当前 Mihomo 文档为准：

proxy-groups:
  - name: 自动选择
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50

这类配置适合让客户端定期检查代理组中的节点，但自动选择结果仍然只反映测试地址的 HTTP 健康检查，不代表所有网站或办公系统都会获得相同体验。

客户端延迟和 ping 有什么区别

测试项目实际测量内容适合判断什么不能直接说明什么
客户端延迟通过代理访问指定 HTTP 测试地址所需的时间节点能否通过当前测试地址建立并完成请求不能代表所有网站的延迟或下载速度
ICMP ping向目标主机发送 ICMP 回显请求并等待返回本机到该目标的基础网络响应通常不能直接代表代理隧道内的真实业务路径
实际访问打开目标网页、办公系统或传输文件当前用途下的连接体验和持续稳定性不能单独证明线路长期可用
tracert 或 pathping查看 ICMP 探测经过的路径，并可辅助观察路径上的延迟和丢包本地网络或直连路径排查不能简单等同于代理节点经过的完整隧道路径

Windows 的 tracert 使用 ICMP 探测包和 TTL 查看目标路径；微软文档还指出，pathping 可用于观察路径中各路由器和链路的延迟及丢包。可参考 Microsoft Learn 的 tracert 说明。

因此，在 TUN 模式、代理规则生效或 DNS 使用 fake-IP 时，直接对节点名称、代理服务器域名或目标域名执行 ping，往往不能还原代理请求在隧道内的完整路径。ping 和 tracert 更适合检查本地网络、默认网关或某个直连目标，不应单独用来给代理节点排名。

测速结果怎么比较：用表格避免误判

现象优先判断下一步操作
单个节点超时，其他节点正常该节点、该节点协议或路径异常换另一个节点复测，并保留测试时间和错误信息
所有节点同时超时测试地址、客户端代理状态或本地网络可能有问题先确认测试地址可访问，再检查系统代理、TUN 和本地网关
延迟低但网页频繁断开丢包、抖动、规则或长连接兼容性问题进行连续访问和文件传输复测，不要只看一次延迟
延迟高但结果稳定可能适合非实时使用，不一定完全不可用结合远程办公、会议或文件传输的实际需求判断
测速快但特定业务打不开规则分流、DNS、目标服务或协议兼容性问题检查该域名命中的策略组，并用同一节点测试其他目标

建议用“低延迟、少超时、实际访问稳定”作为综合标准，而不是设置一个对所有场景都适用的固定毫秒数。远程桌面、视频会议和跨境办公通常更关注持续连接、上传、抖动和丢包；普通网页访问则可能更能容忍较高但稳定的延迟。

Windows 上如何排查是本地网络还是节点问题

  1. 断开 Clash Verge Rev 或暂时关闭代理，先访问普通网页，确认本地网络是否正常。
  2. 在命令提示符执行 ipconfig，找到当前连接的默认网关。
  3. 执行 ping 默认网关地址，例如 ping 192.168.1.1，观察本地 Wi-Fi 或路由器是否存在明显波动。
  4. 如果默认网关稳定，再执行 tracert /d 目标域名，查看直连路径是否出现持续异常。
  5. 重新启用客户端并测试同一目标。若直连正常、代理后异常，再检查客户端测试地址、规则、DNS、TUN 状态和节点本身。

某一跳出现超时并不一定表示整条线路故障，因为中间路由器可能不响应 ICMP 探测。更应关注的是：从某一跳开始，后续路径持续异常，并且实际访问同时出现超时或断线。

如何记录一份可复现的测速结果

如果需要反馈连接问题，可以按下面格式记录：

  • 设备与系统：Windows、macOS 或 Linux，以及系统版本。
  • 客户端信息：Clash Verge Rev 版本和是否开启 TUN。
  • 网络环境：有线、Wi-Fi、公司网络或手机热点。
  • 测试时间：使用具体日期和时间，例如 2026-10-18 20:30。
  • 节点信息：记录客户端显示的节点名称或地区，不要只写“某地区节点”。
  • 测试结果：延迟、超时次数、连续访问是否中断以及实际业务表现。
  • 复现步骤：导入订阅、选择节点、点击测试、打开目标页面以及出现问题的时间点。

提交日志或截图前，请遮挡订阅链接、账号、密码、访问令牌和不必要的公网 IP 信息。不同客户端版本的按钮名称和页面布局可能略有差异，遇到界面不一致时，应以当前版本实际显示为准。

使用测速结果时的安全与流量提醒

延迟测试会向配置的测试地址发起请求，测试地址运营方可能看到请求来源和时间等网络信息。Clash Verge Rev 的公开隐私说明也提示，代理或代理组测试会通过对应代理向测试地址发起 HTTP 请求。因此，不要把包含敏感参数的私人地址作为公共测试 URL，也不要在不清楚来源的配置中启用陌生测试地址。

批量测速和重复测速还可能产生额外流量。移动网络或流量受限环境下，建议先测试少量候选节点，确认测试地址和客户端配置没有问题后再扩大范围。

常见问题

ofoNET 测速应该先测什么？

如果使用 Clash Verge Rev，先确认客户端已加载节点，再检查延迟测试地址，随后逐个测试候选节点并记录延迟、超时和测试时间。最后用实际网页、办公系统或文件传输复测，不要只根据一次延迟结果选节点。

Clash Verge Rev 显示的延迟是不是 ping？

不是完全等同。客户端延迟测试是通过代理访问指定 HTTP 测试地址的耗时，而 ping 使用 ICMP 回显请求。两者协议、目标和路径可能不同，因此数值不能直接横向比较。

为什么所有节点都显示超时？

先检查测试地址本身是否能访问，再检查系统代理、TUN、客户端日志和本地网络。如果只有测试地址不可达，可能是测试地址问题；如果普通网页和多个测试地址也失败，再继续排查本地网络或节点连接。

延迟最低的节点是不是最好？

不一定。最低延迟只说明它在当前测试地址和测试时刻的响应较快。还应结合超时次数、连续访问是否中断、上传表现、丢包和实际业务需求判断。

开启 TUN 后还能用 ping 判断节点质量吗？

不能单独依赖 ping。TUN 会改变部分流量的接管和转发方式，而 ping 是否进入代理还取决于客户端配置和规则。更稳妥的做法是用客户端 HTTP 延迟测试，再对实际业务做连续访问复测；ping 和 tracert 主要用于检查本地网络或直连路径。

测速时应该使用哪个测试地址？

应选择你能访问、响应稳定且不会携带敏感信息的 HTTP 或 HTTPS 地址。Mihomo 文档中的健康检查配置使用测试 URL，并支持设置超时时间和期望状态码；具体地址不要照搬未经验证的配置，先确认当前网络可以访问。

相关阅读

参考资料

  1. Clash Verge Rev：延迟测试与测试地址说明
  2. Mihomo Docs：url-test 自动选择配置
  3. Mihomo Docs：代理组通用字段与健康检查
  4. Microsoft Learn：tracert 命令与路径排查