代理节点怎么测速和选择？三轮测速筛出主用节点
简答：代理节点不要只看最低延迟。最快做法是：先确认测速请求经过代理，再进行延迟初筛、吞吐复测和真实业务验证，最后按网页、视频、下载、游戏或会议的需求选择主用与备用节点。本文是独立使用指南，不代表任何客户端、订阅服务或节点提供方的官方结论。
定义：代理节点测速，是在固定设备、网络、客户端和测试条件下，比较节点的连通性、延迟、下载、上传、丢包、抖动与实际业务表现。
先按这张速查卡操作：不要把直连结果当成节点结果
| 步骤 | 要做什么 | 通过标准 |
|---|---|---|
| 1. 核验路径 | 选定节点，确认客户端连接、代理模式和出口信息发生变化 | 请求不是直连，客户端没有显示断开或超时 |
| 2. 延迟初筛 | 用客户端内置延迟测试或连通性测试 | 先排除反复失败、超时和延迟大幅波动的节点 |
| 3. 吞吐复测 | 只对少量候选测下载、上传和负载表现 | 记录多次结果，不只看一次峰值 |
| 4. 场景验证 | 打开常用网页、播放视频、下载合法文件或进行会议测试 | 能稳定完成你的真实任务 |
| 5. 建立备选 | 保留一个经过独立复测的备用节点 | 主用节点异常时有明确切换对象 |
如果测速工具没有经过代理，后面的数字都不能用于比较节点。先记录设备、网络类型、客户端、节点名称、代理模式、测试工具和测试时间；每次只改变一个变量，否则很难判断变化来自节点还是本地网络。
客户端的普通代理、系统代理、TUN 和规则模式，核验方式并不相同。普通代理通常只影响明确使用代理端口的应用；系统代理依赖操作系统和应用是否读取系统代理；TUN 会改变更大范围的流量路径，但还会受到权限、路由、DNS 和防火墙影响；规则模式则可能让不同域名分别走代理或直连。因此，初筛时优先使用普通代理或全局代理，确认基础连通后再验证规则和 TUN。每次改动前备份配置，异常时先恢复上一个可用设置。
以 Clash Verge Rev 为例，项目公开说明写明，测试代理或代理组时会经由该代理向测试地址发起 HTTP 请求；这说明客户端延迟按钮测试的是特定请求路径，不等于所有网站的下载速度。具体测试地址和入口以当前客户端页面显示为准，可查看Clash Verge Rev 的延迟测试说明。
测速工具怎么选：不同工具测的是不同问题
| 工具类型 | 适合测什么 | 不适合单独证明什么 | 使用建议 |
|---|---|---|---|
| 客户端内置延迟测试 | 批量比较节点是否能响应、响应时间差异 | 不能单独证明下载速度、会议质量或长连接稳定性 | 作为第一轮筛选，统一测试地址和超时条件 |
| 浏览器测速页面 | 下载、上传、空闲延迟、负载延迟和部分稳定性表现 | 不能保证所有目标网站都走同一条路径 | 固定测速服务器和浏览器，先确认浏览器请求经过代理 |
| 真实业务测试 | 网页打开、视频加载、文件下载、办公系统和会议体验 | 不能替代长期、跨时段的统计 | 放在最后验证，选择合法且可重复的目标 |
| Windows pathping | 观察直连路径上的中间节点延迟和丢包线索 | 不能直接代表代理节点的端到端质量 | 用于排查本地或直连网络，不要与代理测速结果混为一谈 |
浏览器测速适合观察综合网络质量，因为单看下载和上传并不完整。Cloudflare 的网络质量说明将延迟、丢包、下载、上传、负载延迟和抖动分开观察，并按不同场景解释结果，详见Aggregated Internet Measurement 指标说明。Cloudflare 还说明，空闲延迟与有下载或上传负载时的延迟可以分别统计，可用于发现“空闲时很快、开始下载后明显变慢”的情况，参见网络质量指标词汇表。
Windows 用户可以把 pathping 目标域名 作为本地或直连路径排查工具。微软文档说明，pathping 会向路径上的路由器发送多次请求并计算中间链路的延迟和丢包；它适合定位某一段直连网络的线索，但不能替代客户端内的代理节点测试，详见Microsoft pathping 文档。
三轮测速怎么做：先小流量，再对少量候选测吞吐
第一轮：连通性和延迟初筛
- 选定一个节点或代理组，确认客户端状态为已连接。
- 暂时使用普通代理或全局代理，避免规则把测试地址直连。
- 测试所有候选节点，记录成功、超时、失败和延迟变化。
- 把反复超时、无法连接或延迟极不稳定的节点放入淘汰区。
延迟是请求往返所需时间，适合判断响应快慢，但不等于下载速度。IETF 的网络性能指标资料将延迟、丢包、延迟变化和吞吐作为可分别观察的指标，不能用一个 Ping 或单次延迟数字代替完整质量判断，可参考RFC 8912 网络性能指标注册表。
第二轮：吞吐和负载复测
不要一开始就给全部节点做大文件测速。建议先用小流量或较短测试完成初筛，只对少量候选节点测下载和上传；如果客户端或测速页面支持限制测试时长、测试服务器或数据量，应先采用较小设置。测试过程中记录测速前后的延迟变化，尤其关注加载延迟明显上升的节点。
具体流量取决于工具、测试时长、并发连接数和测试服务器，不能在没有工具参数的情况下给出统一流量数字。可执行的控制方法是：先测延迟，再测少量候选；先使用短时、低数据量测试，确认值得继续后再做较长复测；对有流量上限的订阅，测试前查看客户端或服务页面是否显示用量。
第三轮：稳定性和真实业务复测
重复测试是本文的建议流程，不是所有网络都必须遵守的行业标准。为了减少偶然峰值影响，可以对候选节点重复记录多次，并在两个不同时间段各观察一组结果；如果你的使用时间固定，就优先在实际使用时段测试。最后完成真实业务复测，例如打开常用网页、播放一段视频、下载一个合法文件或进行一次短时会议。
建议表格至少记录：测试日期、开始时间、设备、网络类型、客户端、节点、模式、测试地址、延迟、下载、上传、丢包、抖动、加载延迟、真实业务结果和备注。本文流程核验日期为 2026 年 10 月 30 日。
用评分模板选主用和备用节点：权重可以按场景调整
下面是编辑建议的起始模板，不是统一行业标准。它的作用是把“感觉更快”变成可复核记录。总分可以按 100 分计算，先给每项 0—10 分，再乘以权重：
| 项目 | 建议权重 | 评分依据 |
|---|---|---|
| 连通性 | 40% | 是否成功、是否超时、是否能稳定完成目标任务 |
| 稳定性 | 30% | 多次结果是否接近，是否有明显丢包、抖动或中断 |
| 场景吞吐 | 20% | 下载、上传或加载表现是否满足实际用途 |
| 延迟 | 10% | 响应速度是否适合网页交互、实时操作或办公系统 |
如果主要看视频或下载，可以把“场景吞吐”提高到 30%—40%，相应降低延迟权重；如果主要进行视频会议或远程操作，应提高稳定性、丢包和抖动的权重；如果只是网页浏览，连通性、延迟和 DNS 响应更重要。这里的百分比只是可调整的记录模板，不代表任何节点质量等级或官方标准。
主用节点应满足：多次测试成功、真实业务稳定、符合你的主要场景，并且不是只靠一次峰值速度取胜。备用节点应经过独立复测，不能只因为名称、地区标签或单次延迟较低就加入备用列表。假如主用节点晚间出现超时，优先切换到此前已验证过的备用节点，再重新记录结果。
按场景选择节点：延迟、速度和稳定性谁更重要
| 场景 | 优先指标 | 选择重点 |
|---|---|---|
| 日常网页 | 连通性、响应延迟、DNS 和稳定性 | 优先选择打开多个常用网页都稳定的节点，不必只追求最高下载峰值。 |
| 视频播放 | 持续下载、加载延迟、负载后稳定性 | 观察播放开始和持续一段时间后的表现，重点复测实际使用时段。 |
| 文件下载 | 中位下载速度、持续时间、重连情况 | 不要用短时最高速度判断，记录下载过程中是否反复降速或中断。 |
| 实时互动 | 延迟、丢包、抖动、持续连接 | 稳定性通常比峰值带宽更重要，出现断续时先排查本地 Wi‑Fi 和负载延迟。 |
| 视频会议 | 上传、下载、抖动、丢包 | 上下行都要观察；只测下载无法说明会议发送画面的质量。 |
不要把节点地区、名称、协议标签或倍率直接当作速度结论。它们最多是筛选线索，最终仍要以当前设备、当前网络、当前时间和实际目标的复测结果为准。
测速异常怎么分流：先判断是路径、规则还是本地网络
- 全部节点超时：先关闭代理确认直连网络正常，再检查订阅是否成功更新、客户端权限、系统时间、网络连接和本地安全软件。不要立即认定所有节点同时失效。
- 延迟测试成功但网页打不开：确认当前域名是否被规则直连，检查 DNS 解析和代理模式，再用同一节点访问其他合法目标。延迟请求成功不代表所有域名都能访问。
- 测速很快但真实业务很慢：更换测速服务器，观察负载延迟和持续速度，并用真实网页或下载目标复测。单次测速峰值不能代表长时间表现。
- 只有某个应用失败：检查应用是否读取系统代理、是否需要 TUN、是否被单独规则绕过，以及本地防火墙或权限是否拦截。
- 连接时快时慢：记录时间、节点、网络类型和指标，分别在直连、普通代理和目标客户端模式下对比；一次只改一个设置，并保留原配置以便恢复。
丢包也不一定只来自节点。微软的排查资料指出，本地策略、资源、路由、远端拥塞以及 MTU 等都可能导致丢包或连接失败；因此，发现异常后应结合设备、局域网、客户端和目标路径分层验证，而不是只更换节点，详见Microsoft 丢包诊断说明。
可直接复制的节点筛选清单
- □ 已确认测试请求经过代理，而不是直连。
- □ 已固定设备、网络、客户端、测试工具和测试服务器。
- □ 已完成连通性和延迟初筛。
- □ 只对少量候选节点做下载、上传或负载测试。
- □ 已记录多次结果，没有只看一次最高速度。
- □ 已在实际使用时段观察稳定性。
- □ 已按使用场景调整评分权重。
- □ 已用真实网页、视频、下载或会议完成最终验证。
- □ 已保留一个经过独立复测的备用节点。
- □ 已记录测试日期，便于后续比较。
最简决策路径可以概括为：先排除超时节点，再选择多次成功且稳定者，随后按实际场景做吞吐和真实业务复测。没有统一实测数据时，不应直接声称某个地区、协议或节点名称一定更快。
常见问题
代理节点测速时，最低延迟是不是最好的选择？
不一定。最低延迟只说明特定测试请求响应较快，不能代表下载速度、上传速度、丢包、抖动和长时间稳定性。应结合实际场景，再用真实业务复测。
代理节点测速应该用客户端还是浏览器测速？
两者用途不同。客户端内置测试适合批量比较节点是否能响应；浏览器测速适合观察下载、上传、空闲延迟和负载延迟；真实业务测试则用于最后确认。先用客户端初筛，再对少量候选使用浏览器和真实业务复测。
测速会不会消耗很多流量？
延迟测试通常比下载、上传测速消耗少，但具体用量取决于客户端、测试地址、测试时长和并发方式。建议先小流量完成延迟初筛，只对少量候选做吞吐测试，并在有流量限制时先查看工具的测试设置。
为什么测速显示成功，但打开网页仍然很慢？
可能是测速请求经过代理而目标网页被规则直连，也可能是 DNS、目标服务、测速服务器或节点在负载下表现不同。先确认代理模式和出口，再比较加载延迟、持续速度和真实网页表现。
所有代理节点都超时，应该先换节点还是换客户端？
先确认直连网络正常，再检查订阅、客户端权限、系统时间、代理模式、DNS 和本地网络限制。如果所有节点同时失败，应优先排查本地网络或配置，而不是直接认定所有节点都不可用。
主用节点和备用节点应该怎么选？
主用节点应是多次测试成功、真实业务稳定且符合主要场景的节点；备用节点应提前独立复测，不能只凭名称、地区或单次最低延迟选择。最好记录明确的切换条件，例如主用节点连续超时或真实业务无法完成时再切换。