代理页一堆节点，哪个能用？内置延迟测试只反映握手快慢，不代表视频、下载或 AI 补全一定流畅。它是个初筛工具，不是质量报告——测完还要按场景挑，再验一次真实业务。
操作入口：分组右上角的闪电图标测延迟；若一片全红，先把测速 URL 改成 http://www.gstatic.com/generate_204 再看。选好节点后开系统代理或 Tun；给 ChatGPT / Claude / Gemini 用时还要额外看地区是否匹配（Tun 与 AI）。
怎么测、数字怎么读
看分组延迟分布，别只盯最小延迟：一堆绿里挑稳定的，全红先查测速 URL、网络、订阅是否空（不出节点、更新失败）。自动选择适合日常；重要会话可手动置顶，避免 url-test 跳来跳去导致时好时坏。
延迟低却仍卡
延迟只是握手。带宽打不满、晚高峰拥堵、协议不合适、国内大站绕行，都会「绿却慢」。转到网速慢优化，并给国内下载加直连（Steam 直连、直连规则）。延迟绿但 TLS 握手失败：换节点或查 DNS（DNS）。
按场景选节点
- 浏览：延迟稳、少断即可。
- 下载/流媒体：吞吐优先，晚高峰复测。
- AI：地区 + 长连接稳定，单看延迟不够。
机场本身差，换节点也有限——选源见机场怎么选。
测速数字不可信时先查什么
- 测速 URL 本身超时：默认地址在你网络下不通会造成「全红」假象，换成可直连的 generate_204 再看。
- 一次测太多：分组大时并发打满，机场侧限速或本机连接数吃紧，数字会失真，先测一组。
- 只盯最小值：最小延迟那个节点可能正被最多人用，实测反而更差；看分布与稳定性。
- url-test 自动跳：延迟抖动会让策略组不断切换节点，表现为时好时坏；关键会话锁定固定节点。
这些属于「数字没问题、体感不对」——本质是测速只测了握手，没测吞吐和长连接。
选完三步验收
- 目标站连接页有记录且规则合理（规则）。
- 实际打开页面/接口，不只看测速数字。
- 高峰再测一次；url-test 乱跳就固定节点。
测速通了业务仍失败：系统代理/DNS/站点封锁，分别见对应专文。客户端：下载中心。