network test 怎么测网络和节点速度？
简答：客户端显示 50ms、网页却很慢时，先不要继续按延迟排序。正确做法是：关闭代理测本机基线，开启代理用客户端的 URL/HTTP 测试或浏览器页面测速，最后固定同一个测试点比较节点；Ping 和 Traceroute 主要反映直连 ICMP 路径，通常不能代表代理节点速度。
定义：network test 是把设备到测试服务器、经代理节点到测试服务器、以及设备到实际业务网站的连接分段测量，而不是用一个延迟数字代表全部网络体验。
先记住这条规则：Ping 低，不等于节点快
如果客户端显示延迟很低，但网页打开慢、文件传输断续或办公系统频繁超时，最常见的误区是把 ICMP 的 Ping 结果当成了代理节点速度。系统代理模式下，ping 和 tracert 通常直接从本机发出，不会自动套用 HTTP 或 SOCKS 代理；它们测到的多半是设备到目标地址的直连路径。
如果客户端启用了 TUN、DNS 劫持或 fake-ip，域名还可能被解析成客户端内部使用的合成地址。假如命令结果出现 198.18.x.x 等保留或虚拟地址，或者延迟稳定在约 1ms，不要把这个数字当成节点延迟；应改用客户端的 URL/HTTP 延迟测试、经代理的浏览器测速或真实业务页面。具体地址池和实现方式以当前客户端文档与配置为准。
| 测试阶段 | 推荐方法 | 主要回答的问题 | 不能直接推出的结论 |
|---|---|---|---|
| 本机基线 | 关闭代理后运行浏览器测速、Ping 或实际网页测试 | Wi-Fi、移动网络、路由器和宽带本身是否正常 | 不能代表开启代理后的节点吞吐 |
| 代理链路 | 开启代理后使用客户端 URL/HTTP 延迟、浏览器测速或下载测试 | 当前节点经代理访问测试点时是否能稳定建连和传输 | 不能证明所有网站和所有时段都可用 |
| 实际业务 | 开启代理后访问真正需要的办公系统、文件服务或网页 | DNS、TCP/TLS、页面加载和持续传输是否正常 | 一次打开成功不能证明长期稳定 |
Google 的说明指出，测速结果会受设备位置、测速服务器位置和网络拥塞影响；Cloudflare 的网络质量指标也把延迟、丢包、下载、上传、负载下延迟和抖动分开评估，而不是只看一个速度数字。Google 网络测速说明、Cloudflare 网络质量指标说明
从零开始的最小闭环：先测本机，再测经代理 HTTP
- 固定条件。记录设备、系统、Wi-Fi 或移动网络、测试时间、客户端模式、测试点和节点名称。暂停云盘同步、系统更新、视频播放和其他下载；移动网络先确认流量限制。
- 关闭代理建立基线。暂停系统代理、断开客户端连接，使用同一个浏览器测速页面或同一个测试文件记录下载、上传、页面加载和基础延迟。
- 开启代理测试当前节点。恢复原来的客户端配置，确认系统代理或 TUN 状态符合预期，再访问同一个测速点。优先看客户端内置的 URL/HTTP 延迟或实际页面加载，不要用系统 Ping 代替节点测速。常见入口通常位于“代理组”“节点列表”“延迟测试”“URL Test”或类似位置，界面可能不同，以当前应用页面为准。
- 固定测试点比较节点。逐个切换节点，每个节点至少重复三次；不要一会儿测近距离服务器、一会儿测远距离服务器，否则结果无法比较。
- 恢复或回滚。测试完成后恢复原来的代理模式和配置。如果期间修改过 DNS、规则、TUN 或 MTU，优先导入备份配置，不要在没有备份的情况下连续删除和重建配置。
客户端下载的“延迟测试”通常是经当前节点向某个 URL 发起请求，并测量请求往返或响应时间；它与 ICMP Ping 不同，可能包含代理建连、TCP/TLS 握手、HTTP 响应以及测试 URL 本身的处理时间。它更接近“这个节点访问该 URL 的响应速度”，但仍不等于下载速度或所有网站的打开速度。
在 Apple 平台的网络请求中，URLSession 还可以记录每次请求和响应交易的指标，并区分是否使用代理连接；这也说明 HTTP 请求耗时与单独的 ICMP 回显不是同一种测量。普通用户不需要编程，只要优先使用客户端的 URL/HTTP 测试或浏览器实际访问即可。Apple URLSessionTaskMetrics 文档
Windows、macOS、Android、iPhone 分别怎么测
| 平台 | 本机基线 | 代理节点测试 | 异常时下一步 |
|---|---|---|---|
| Windows | 关闭代理后打开测速页面；命令提示符运行 ping -n 20 你的目标域名 | 开启代理后使用客户端 URL/HTTP 延迟，或浏览器访问同一个测速点 | 若域名解析失败，先检查 DNS；若仅 Ping 失败但网页正常，不要直接判定节点不可用 |
| macOS | 关闭代理后在“终端”运行 ping -c 20 你的目标域名 | 开启代理后使用客户端延迟测试或浏览器测速，不要把终端 Ping 当成经代理结果 | 运行 traceroute 你的目标域名 只用于观察直连路径，不能替代 HTTP 测试 |
| Android | 关闭客户端连接，在浏览器测速；必要时切换 Wi-Fi 与移动数据各测一次 | 开启客户端后用内置 URL/HTTP 延迟或浏览器访问同一测试点 | 确认系统代理、TUN、DNS 和网络类型没有中途切换；设置名称会因厂商而不同 |
| iPhone/iPad | 关闭代理配置后使用 Safari 测速或打开实际业务页面 | 开启客户端后使用客户端内置延迟测试或 Safari 访问同一测试点 | 检查 VPN/代理状态、Wi-Fi 与蜂窝数据是否切换；没有命令行时不要强行用 Ping 判断节点 |
Windows 的 tracert 使用 ICMP 和递增 TTL 查看路径；微软也说明，部分路由器不会返回超时信息，因此中间出现星号不一定代表链路中断。若要观察路径上的延迟和丢包，可在 Windows 使用 pathping 你的目标域名，但它仍然是直连路径诊断，不是经系统代理的 HTTP 节点测速。Microsoft tracert 文档
Android 官方建议在 Wi-Fi 与移动数据之间切换，用来判断问题是否只出现在某一种接入方式；设置路径可能因设备厂商和 Android 版本不同而变化。Android 网络连接排查说明
节点速查卡：先看丢包和超时，再看抖动与 HTTP 延迟
下面的等级不是运营商或客户端的统一标准，而是普通用户进行同批次比较时的实用分流方法。不要把它当成绝对可用率或服务质量承诺；同一个节点在不同设备、线路、测试点和时段可能得到不同结果。
| 优先级 | 观察项 | 较好表现 | 需要谨慎 | 下一步 |
|---|---|---|---|---|
| 1 | HTTP 超时与页面加载 | 连续请求都能返回，目标页面能完成加载 | 频繁超时、只返回部分资源或反复失败 | 先排查规则、DNS 和目标网站，再换节点 |
| 2 | 丢包 | 重复测试中没有持续超时 | 丢包或超时反复出现 | 增加复测次数，并检查本机网络是否也丢包 |
| 3 | 抖动 | 延迟范围较集中，页面响应较稳定 | 延迟忽高忽低，语音、会议或办公连接卡顿 | 看负载下延迟和晚高峰表现 |
| 4 | HTTP 延迟 | 同一测试点下响应更快 | 只有 ICMP 延迟低，HTTP 响应却慢 | 以 HTTP/真实业务结果为准，不按 Ping 排序 |
| 5 | 稳定下载与上传 | 速度保持在相对稳定区间 | 峰值很高但很快降速或中断 | 重复下载测试，记录中位数或稳定区间 |
一个简单的排序原则是：先淘汰持续超时或实际业务打不开的节点，再比较丢包和抖动，之后比较经代理的 HTTP 响应时间，最后才看稳定下载和上传。延迟低但 HTTP 慢的节点，不应排在 HTTP 稳定且下载持续的节点之前。
可复制记录表：用同一测试点留下示例行
建议把下面的表格复制到表格软件中，每次只改变一个变量。示例数据仅用于说明记录格式，不代表任何真实节点、线路或服务结果。
| 时间 | 设备/系统 | 网络 | 代理状态 | 节点 | 测试点 | HTTP 延迟 | 丢包/超时 | 抖动 | 稳定下载 | 页面结果 |
|---|---|---|---|---|---|---|---|---|---|---|
| 示例：晚间 20:30 | Windows 笔记本 | 同一 Wi-Fi | 开启代理 | 节点 A | 同一测速 URL | 记录三次结果 | 无/有超时 | 低/中/高 | 记录稳定区间 | 办公页面完成/失败 |
| 填写日期时间 | 设备与系统版本 | Wi-Fi/移动数据 | 关闭或开启 | 节点名称 | 固定 URL 或文件 | 第1-3次 | 次数或比例 | 范围或中位数 | 平均或区间 | 完成加载时间与备注 |
测试次数不必无限增加，但至少应覆盖本机关闭代理、当前节点开启代理和两个以上候选节点。若白天正常、晚高峰异常，应分别记录，而不是把两段结果混成一个平均值。
下载测试会产生实际流量，移动网络用户应优先使用小样本或浏览器页面测试，并留意测速页面是否自动开启多线程下载。Ping 和 Traceroute 通常流量较小，但高频长时间运行也没有必要。
结果不一致时的分流与回滚
关闭代理也慢：先靠近路由器、重连 Wi-Fi、暂停后台流量，再复测；如果 Wi-Fi 和移动数据只有一种异常，优先排查对应接入方式。Google 也提示，拥塞、测试时段和测速服务器位置都会造成结果差异。Google 测速结果差异说明
关闭代理正常，开启代理后所有节点都慢：检查客户端是否启用了预期的系统代理或 TUN，确认 DNS、规则和配置没有被中途修改。每次只改变一个变量，并先备份配置。
Ping 很低，但客户端 HTTP 延迟高：不要继续按 Ping 排序。此时更应该检查代理建连、TLS、DNS、测试 URL 响应和节点负载。
只有一个网站打不开：分别测试其他网站、目标域名解析、经代理的页面加载和实际业务请求。Traceroute 只能辅助观察路径，不能替代 HTTP 或真实页面测试。
Traceroute 中间出现星号：先看后续跳数和最终目标是否可达。微软文档明确说明，部分路由器不会返回 TTL 超时信息，所以单个中间跳的星号不能单独证明故障。Microsoft 路由跟踪说明
测试完成后，恢复原来的客户端模式和配置，确认普通网页、DNS 解析和实际业务都能恢复。若修改后无法恢复，优先导入测试前备份，而不是继续叠加 DNS、MTU、规则或 TUN 改动。
常见问题
为什么客户端显示 50ms，打开网页还是很慢？
客户端的 50ms通常是经节点请求某个 URL 的响应时间，或某种探测请求的耗时；它不等于完整网页加载、持续下载或所有目标网站的表现。应检查 DNS、TCP/TLS 建连、HTTP 返回、丢包、抖动和实际页面加载。
系统代理模式下，Ping 测到的是节点吗？
通常不是。系统代理一般只影响支持 HTTP、HTTPS 或 SOCKS 的应用流量，操作系统的 ICMP Ping 和 Traceroute 通常仍然从本机直连目标。因此比较节点时，应使用客户端 URL/HTTP 测试、经代理的浏览器测速或真实业务页面。
TUN 或 fake-ip 模式下为什么会出现 198.18.x.x 和 1ms？
这可能是客户端为域名分配的虚拟地址，而不是目标服务器真实地址。看到这类地址或异常低延迟时，不要把 Ping 结果当成节点速度；改用经代理的 HTTP 测试，并以当前客户端文档和配置为准。
Windows 和 macOS 的命令怎么写？
Windows 可用 <code>ping -n 20 你的目标域名</code> 和 <code>tracert /d 你的目标域名</code>；macOS 可用 <code>ping -c 20 你的目标域名</code> 和 <code>traceroute 你的目标域名</code>。请替换“你的目标域名”，并记住这些命令主要用于直连基线和路径排查，不是代理节点测速。
iPhone 和 Android 没有命令行，怎么测节点？
先关闭客户端，用 Safari 或浏览器测一次固定页面；再开启客户端，用客户端内置的延迟测试、URL Test 或浏览器访问同一页面。Android 还可以切换 Wi-Fi 与移动数据分别复测，iPhone/iPad 则应检查当前 VPN 或代理状态是否真的启用。
节点应该先看延迟还是下载速度？
先看 HTTP 是否能稳定返回、是否超时，再看丢包和抖动，然后比较经代理的 HTTP 延迟，最后看稳定下载和上传。只有 Ping 低但 HTTP 慢、或下载峰值高却频繁中断的节点，不应直接判为更好。
测速会消耗多少流量？
无法在没有指定工具、文件大小和测试方式的情况下给出固定流量数字。下载和上传测速会产生实际流量，多线程测试通常消耗更多；移动网络用户应优先使用小样本、页面加载或客户端 HTTP 测试，并查看工具自身提示。