COCODUCK测速：如何在客户端测试节点延迟与连接质量
简答：COCODUCK测速不要只打开公共测速网站看下载速度。更可靠的做法是：在客户端内对节点执行 HTTP 真连接测试，确认测试地址确实经过目标节点，再结合延迟、抖动、丢包和实际办公连接表现选择节点；规则模式下还要检查分流是否把测速地址直连。
定义：本文所说的 COCODUCK 测速，指使用兼容客户端对相关节点进行延迟或 HTTP 真连接测试，并在相同设备、网络、测试地址和时间条件下比较连接质量的方法。
先区分三种“延迟”：不要把数字直接当成节点质量
搜索“cocoduck测速”的用户，通常想知道某个节点是否可用、哪个节点更适合网页访问或跨境办公。客户端里的延迟数字，可能来自不同测试方法，不能直接横向比较。
| 测试类型 | 实际测量对象 | 能否代表真实使用 |
|---|---|---|
| TCP 延迟或握手延迟 | 客户端到节点入口的 TCP 建连或握手耗时 | 可反映节点入口响应速度，但不一定包含访问目标网站的完整路径。 |
| HTTP URL Test | 通过节点请求指定 URL，并等待 HTTP 响应 | 比单纯 TCP 延迟更接近网页连接，但结果会受到测试地址、响应状态和目标路径影响。 |
| 真连接延迟 | 通过客户端当前代理入口访问测试地址 | 通常更接近实际使用；但规则、系统代理、TUN 和客户端自身排除规则都可能改变测试流量的路径。 |
| 公共测速网站 | 设备到测速网站服务器之间的下载、上传和延迟 | 只能作为网络质量参考，不能单独证明某个节点或某个业务目标的质量。 |
因此，节点选择建议优先看同一客户端内的真连接或 URL Test，再用实际业务复核。Mihomo 的接口支持对指定代理使用 URL 和超时值进行测试，并返回毫秒延迟；sing-box 的 urltest 也以指定 URL、测试间隔和容差作为配置项。可分别参考 Mihomo 官方 API 文档和 sing-box 官方 URLTest 文档。
通用准备：先固定测试条件，再确认流量确实经过节点
- 固定设备和网络。尽量使用同一台电脑或手机、同一个 Wi-Fi 或移动网络，暂停下载、云同步、视频播放和系统更新。
- 选择一个测试地址。可以先使用客户端默认地址；如果要自定义，应使用能够稳定返回 HTTP 响应的完整 URL，并尽量保持所有节点使用同一个地址。Mihomo 文档列出的健康检查地址包括
https://cp.cloudflare.com和https://www.gstatic.com/generate_204。 - 设置合理超时。首次排查可使用约 5000 毫秒作为起点；如果跨区域链路本身延迟较高，不要把过短超时直接当成节点故障。Mihomo 的延迟测试接口示例使用
timeout=5000，但具体客户端可能有自己的默认值。 - 检查分流模式。规则模式下，测速地址可能被规则判定为直连。需要把测试地址加入代理规则，或者暂时切换到全局模式，再重新测试。
- 确认出口发生变化。查看客户端连接日志、连接列表或出口地址检测结果，确认测试 URL 的请求确实命中了预期节点。只看到客户端“已连接”并不能证明测速网站走了节点。
- 每个节点至少测试三轮。记录节点名称、时间、测试地址、延迟、超时次数和实际访问表现，优先比较中位表现和稳定性，不要只挑一次最低值。
Clash Verge Rev 的公开说明指出，测试代理或代理组时会通过该代理请求默认测试地址，或者使用用户配置的测试 URL；这也说明测试地址和代理路径是结果的一部分，而不是可忽略的细节。可参考 Clash Verge Rev 官方项目说明。
Clash Verge Rev 与 Mihomo：如何测节点和设置 URL Test
Clash Verge Rev 使用 Mihomo 内核，常见测试入口是代理组或节点旁边的延迟测试按钮。不同版本的界面名称可能略有差异，下面按功能说明操作。
- 导入配置后，打开代理或代理组页面。
- 找到需要比较的节点或策略组，执行延迟测试；如果界面提供测试地址设置，填入同一个完整的 HTTP 或 HTTPS URL。
- 如果使用规则模式，先确认测试域名被分配到代理；无法确认时，切换全局模式测试一次作为对照。
- 等待全部节点完成测试，记录延迟和超时结果。对
url-test代理组，不要在测试期间锁定固定节点，否则自动选择可能优先保留被固定的节点。 - 需要在配置中建立自动选择组时，可以使用类似以下结构，字段名称和具体支持情况应以当前 Mihomo 文档及客户端版本为准：
proxy-groups:
- name: 自动选择
type: url-test
proxies:
- 节点A
- 节点B
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
Mihomo 文档说明，url-test 可使用测试 URL、测试间隔和毫秒级切换容差；容差不是“允许延迟超过多少就一定切换”的绝对保证，而是自动选择策略中的比较参数。配置示例可查看 Mihomo 官方 Url-test 文档。
sing-box：URLTest 与手动节点比较
sing-box 的自动测试组类型是 urltest。官方配置中，url 用于指定测试地址，interval 用于指定测试间隔，tolerance 表示毫秒级测试容差；如果 URL 留空，官方文档给出的默认地址是 https://www.gstatic.com/generate_204，默认间隔为 3 分钟，默认容差为 50 毫秒。
- 打开使用 sing-box 内核的客户端配置。
- 找到包含多个出站节点的
urltest组，确认每个节点都在outbounds列表中。 - 设置统一的测试 URL，并确认该域名不会被路由规则判为直连。
- 先执行一次手动测试，再观察自动选择结果；如果两个节点延迟差小于容差，客户端可能继续使用当前节点，这不代表测试失败。
- 用实际网页、远程桌面或办公系统验证。URLTest 测到的是测试 URL 的响应路径，不是所有业务目标的综合排名。
可以使用下面的简化配置理解字段含义：
{
"type": "urltest",
"tag": "自动选择",
"outbounds": ["节点A", "节点B"],
"url": "https://www.gstatic.com/generate_204",
"interval": "3m",
"tolerance": 50
}
字段和默认值以 sing-box 官方文档为准；图形客户端是否暴露全部设置，则取决于客户端实现。
Shadowrocket、v2rayN 与手机端：怎么做真连接测试
手机端界面会随客户端版本和系统变化，不能把某个版本的按钮位置当成所有设备的固定路径。操作原则是：使用客户端内部的节点测试或真连接测试，确认测试流量经过当前节点，再用实际业务复核。
iOS 上的 Shadowrocket
- 导入配置并选择一个节点。
- 在节点或连接相关页面查找“连通性测试”“延迟测试”或同类入口；如果当前版本没有该按钮，不要用系统 Wi-Fi 延迟代替节点延迟。
- 在设置或测试选项中检查测试地址；如果可以自定义，使用同一个完整 URL 对比所有节点。
- 开启连接后，用客户端日志或连接状态确认请求经过代理；规则模式下应检查测试域名的分流结果。
- 对延迟较低的候选节点打开实际办公网页、文件同步或视频会议做复核。
Shadowrocket 的具体菜单和测试能力可能随版本变化，本文未核实某一版本的固定按钮名称；以当前应用界面和公开说明为准。
Android 客户端
- 在使用的客户端中选择一个节点，查找“延迟测试”“URL Test”“真连接”或“测试全部节点”等功能。
- 如果客户端支持测试地址和超时设置，所有节点使用相同参数；如果不支持，则只比较同一页面生成的结果。
- 确认 VPN 或 TUN 接口已建立，并检查连接日志中是否出现测试域名；仅显示系统已连接不代表测试请求一定经过目标节点。
- 对测试结果正常但实际打不开的节点，优先检查 DNS、规则分流、MTU 和目标网站路径。
Windows 上的 v2rayN
- 选中节点后，使用客户端提供的“测试真连接延迟”或同类功能，而不是直接使用系统命令替代。
- 在设置中检查链接测试地址；v2rayN 的公开讨论中提到可编辑链接测试地址，但不同版本的名称和入口可能变化。
- 如果开启 TUN 并清除了系统代理，客户端自身测试可能无法找到代理入口，出现
-1或超时；这种情况应先恢复客户端要求的系统代理设置，或按当前版本说明排查。 - 测试完成后，再用浏览器或实际办公应用访问目标地址，确认真连接结果与业务表现一致。
v2rayN 的公开问题记录显示，系统代理模式、TUN 模式和“清除系统代理”会影响真连接测试是否能取得结果，因此不能把 -1 简单解释为节点一定失效。可参考 v2rayN 官方项目问题记录。
Windows、macOS、iOS 和 Android 的排查边界
重要：ping、traceroute、tracert 和 pathping 默认使用 ICMP 或类似的系统路径探测机制，通常不经过普通系统代理，也不等于客户端节点的 HTTP 真连接测试。
- Windows：可以运行
ping -n 30 目标域名、tracert 目标域名或pathping /n 目标域名，但它们主要用于检查本地直连路径。只有在 TUN 确实接管相关流量时，ICMP 才可能被客户端处理；fake-ip 模式下还可能看到198.18.x.x等虚拟地址，或由客户端本地应答，不能据此判断节点延迟。 - macOS：终端可使用
ping -c 30 目标域名和traceroute 目标域名检查系统直连路径。若怀疑 Wi-Fi 本身不稳定，可按 Apple 指引打开 Wireless Diagnostics；它用于分析 Wi-Fi 到互联网的连接，不是节点真连接测速。入口是按住 Option 键并点击菜单栏 Wi-Fi 图标，再选择打开 Wireless Diagnostics，详见 Apple 官方 Wireless Diagnostics 指南。 - iOS：优先使用客户端内部节点测试或真连接测试；系统设置里的 Wi-Fi 信息不能代替某个节点的 HTTP 测试。
- Android：优先使用客户端内部延迟或 URL Test；系统网络诊断只能说明设备网络状态，不能自动证明目标流量经过指定节点。
如果需要测试“节点到目标网站”的质量，应使用客户端的 HTTP 真连接、指定代理端口的请求，或客户端公开的延迟测试接口，而不是把直连 ICMP 结果当成节点结果。
如何判断测速结果：给出可执行的参考区间
没有一个适用于所有节点、所有业务和所有地区的统一“合格线”。下面的数字适合作为跨境办公和实时通信的排查参考，不是服务保证，也不能替代实际业务测试。
| 指标 | 可先采用的参考 | 如何解释 |
|---|---|---|
| RTT 或真连接延迟 | 办公交互通常优先选择更低且更稳定的结果；Microsoft 的网络测试工具将 UDP 延迟低于 100 毫秒作为通过参考，Teams 的较差流标记阈值为 RTT 高于 500 毫秒。 | 高延迟会让远程桌面、语音和交互操作出现明显等待；但网页下载仍可能很快。 |
| 抖动 | 低于 30 毫秒可作为实时音视频排查参考。 | 平均延迟不高但抖动大，仍可能出现语音断续、画面停顿或操作忽快忽慢。 |
| 丢包 | Microsoft 的网络测试工具以低于 1% 作为通过参考；具体业务对丢包的容忍度不同。 | 丢包反复出现时，优先排查 Wi-Fi、出口链路、拥塞、MTU 和目标路径。 |
| 下载与上传速度 | 按实际办公应用需求判断，不作为节点排序的唯一依据。 | 视频会议、文件上传和云同步更关注上传；速度高但丢包或抖动明显，体验仍可能较差。 |
Microsoft 文档将 UDP 延迟、UDP 抖动和 UDP 丢包分别作为 Teams 网络质量指标，并给出低于 100 毫秒延迟、低于 30 毫秒抖动和低于 1% 丢包的测试参考；这些数值是特定实时通信场景的参考，不是所有网络服务的通用标准。可查看 Microsoft 365 网络连接测试说明和 Microsoft Teams 实时质量指标说明。
测速快但实际不好用：按顺序检查这六项
- 测试地址是否直连。规则模式下最常见的问题是测速 URL 没有经过节点。先看日志或切换全局模式复测。
- 测试方法是否一致。TCP 延迟、HTTP URL Test、真连接和公共测速不能混在一起排名。
- DNS 是否改变了路径。域名解析慢、解析到不同地址或 DNS 请求未按预期处理，都可能让首次连接变慢。
- MTU 是否合适。如果只有部分网页、文件上传或特定应用反复超时，可在记录原配置后单独检查 MTU，不要同时修改 DNS、规则和 TUN 设置。
- TUN 是否接管了目标流量。TUN 开启不等于所有客户端自身测试都经过 TUN；有些客户端为了避免循环，会排除自身进程。
- 目标业务是否另有限制。公共测试地址正常，只能说明该测试路径能响应，不能保证某个办公系统、远程桌面或文件服务也能正常连接。
最终选择节点时，建议按实际用途建立记录：测试时间、网络类型、客户端、模式、节点、测试 URL、延迟、超时、抖动、丢包和业务结果。连续多轮都稳定的节点，通常比单次峰值更值得保留。
结论：COCODUCK测速的推荐操作顺序
- 关闭客户端测试本地网络基线，但不要把该结果当成节点延迟。
- 开启一个节点，切换到全局模式或明确设置测试域名走代理。
- 在客户端内执行 URL Test 或真连接测试，统一 URL、超时和测试次数。
- 通过日志、连接列表或出口检测确认请求确实经过节点。
- 对候选节点重复三轮以上，再用实际网页、远程桌面、文件同步或会议连接复核。
- Windows 和 macOS 的
ping、tracert、traceroute、pathping只作为本地直连路径的补充诊断，不能替代客户端真连接测试。
关于 COCODUCK 的固定测速数据、节点状态、价格和具体官方测试入口，本文未核实；如需确认相关信息，应以其公开官方资料为准。
补充说明：第三方使用指南与商业入口边界
本文是第三方技术整理，不代表 COCODUCK 官方，也不提供未经核实的节点排名、速度承诺或可用性保证。文中客户端字段、按钮名称和测试入口可能因版本、系统和配置不同而变化，遇到界面不一致时，应以当前客户端文档和实际日志为准。
常见问题
COCODUCK测速应该用什么方法？
优先使用客户端内置的 URL Test、延迟测试或真连接测试，并统一测试 URL、超时、设备和网络环境。公共测速网站只能反映设备到测速服务的路径，不能单独代表某个节点。
为什么客户端显示低延迟，但打开网页仍然慢？
可能是测试 URL 被规则直连、测试方法只测了节点入口、DNS 解析慢、MTU 不合适、目标网站路径不同，或客户端自身测试没有经过 TUN。先切换全局模式或明确设置测试域名走代理，再查看连接日志。
ping 能不能测试 COCODUCK 节点延迟？
普通 ping 通常使用 ICMP 直连本地路径，不经过系统代理或普通规则模式下的节点，因此不能作为节点延迟。只有 TUN 确实接管 ICMP 时才可能经过客户端；fake-ip 模式、客户端本地应答和进程排除仍会使结果失真。
Clash Verge Rev 的 URL Test 测试地址怎么设置？
在客户端提供的测试地址或配置中设置统一的完整 URL，并确认该域名在规则模式下走代理。Mihomo 的 URL Test 支持测试 URL、间隔和毫秒级容差；具体界面入口以当前版本为准。
sing-box 的 urltest 中 timeout 怎么设置？
sing-box 官方 URLTest 配置重点提供 URL、interval、tolerance、idle_timeout 等字段；具体连接超时还可能由出站或客户端实现控制。不要把过短超时直接当成节点故障，建议使用统一参数并重复测试。
v2rayN 真连接延迟显示 -1 是什么原因？
可能是测试地址不可达、系统代理被清除、TUN 模式下客户端自身测试没有找到代理入口，或测试请求被规则直连。先检查系统代理、TUN、测试地址和日志，再用实际应用复核。
测速时延迟多少才适合跨境办公？
没有适用于所有办公系统的统一阈值。作为实时通信排查参考，Microsoft 文档给出低于 100 毫秒 UDP 延迟、低于 30 毫秒抖动和低于 1% 丢包的测试参考；实际还要看目标系统、协议和路径。
为什么两个客户端测同一个节点，结果不一样？
两者可能使用了不同测试 URL、超时、DNS、路由模式、协议栈或延迟定义。应让测试地址、模式和网络环境尽量一致，并优先比较同一客户端内的节点，而不是直接比较不同客户端的毫秒数。