代理节点怎么选择才稳定？四步筛出主用与备用节点
简答：代理节点是否稳定，不能只看列表中的最低延迟，而要看常用时段的连接成功率、延迟波动、丢包、抖动和真实业务表现。最快做法是先按用途缩小范围，再完成连通性初筛、同条件复测、实际使用验收，最后保留一个主节点和一个备用节点。
定义：稳定的代理节点，是在目标设备、目标用途和常用时段下，能够持续连接，延迟波动与丢包较少，并在网页、会议、视频或办公等真实业务中保持可接受表现的节点。
先试这一步：用一张表筛掉不合适的节点
如果你面对几十个甚至上百个节点，先不要逐个测速。把需求分成“网页与普通办公”“视频”“在线会议”“远程办公”“下载”“需要固定登录状态的业务”几类，再按下表决定优先观察什么。表中的顺序是筛选优先级，不是对任何节点的绝对合格承诺。
| 用途 | 优先观察 | 容易误判的指标 | 验收方式 |
|---|---|---|---|
| 网页、文档、普通办公 | 连接成功率、DNS解析、首包延迟、延迟波动 | 一次测试中的最低Ping | 连续打开多个常用页面并重复刷新 |
| 视频与大文件传输 | 持续吞吐、负载延迟、长连接表现 | 短时测速峰值 | 播放、暂停、拖动和持续下载分别观察 |
| 在线会议、语音和远程桌面 | 丢包、抖动、稳定的往返延迟 | 只看下载速度 | 保持连接一段时间，观察卡顿、断流和重连 |
| 固定账号或长期会话 | 出口地区一致性、连接连续性、手动切换能力 | 自动负载均衡的“平均速度” | 先确认主节点，再单独测试备用节点 |
| 多设备跨境办公 | 协议兼容、DNS处理、系统接管方式和主备方案 | 节点名称中的地区或线路标签 | 在实际设备和办公应用中逐项验证 |
判断网络质量时，延迟、丢包、下载、上传、负载延迟和抖动应一起观察。Cloudflare 的网络质量说明也将这些指标分开评估，说明单一速度数字不能代表完整体验，可参考Cloudflare Aggregated Internet Measurement 文档。
四步筛选法：从测速到真实使用验收
- 第1步：连通性初筛。
先确认客户端已经真正使用代理节点，而不是规则直连、系统代理未生效或只有浏览器走代理。对每个候选节点记录“成功、超时、立即断开”三类结果。Windows 用户可以先用 ping 做基础连通性观察，但 Microsoft 明确提醒，ping 不能单独证明整体连接正常；需要验证具体端口或应用层连接时，可参考Microsoft PsPing 文档。成功标准是：节点能够重复连接，且不是偶尔成功一次。
- 第2步：同条件性能复测。
固定设备、网络、测试目标、客户端模式和测试时间，不要边切换设置边比较。建议至少做三轮：普通时段一轮、常用高峰时段一轮、间隔一段时间后的复核一轮。每轮记录成功次数、延迟中位数、最大与最小延迟、超时次数、丢包或重传现象。用中位数观察典型表现，用失败次数和波动范围观察稳定性；不要因为某次最低延迟漂亮，就把它直接定为主节点。
- 第3步：真实业务验收。
把候选节点放回你的真实使用场景。网页重点看首屏和页面内请求是否连续；视频重点看开始播放、拖动和持续播放；会议或远程桌面重点看长连接、声音画面是否断续；下载重点看持续速度而不是开头几秒的峰值。若节点测速很好，但实际业务频繁重连，应以真实业务结果为准。对于 Windows 网络路径，可使用Microsoft pathping 文档了解路径中的延迟与丢包统计，但中间路由不回应 ICMP 时，结果仍需结合应用层表现判断。
- 第4步：建立主备与回退。
最终不要只留一个“最快节点”。选择一个综合表现最稳定的主节点，再保留至少一个用途相近、地区或路径不同的备用节点。主节点出现连续超时、业务断流或高峰期明显恶化时，先手动切换备用节点，再判断是节点问题还是本地网络、DNS和客户端配置问题。自动切换可以减少手动操作，但固定账号、长期会话或对出口一致性敏感的业务，应优先使用可固定选择的策略，而不是无条件负载均衡。
如果你使用 mihomo 兼容客户端，官方文档将 URLTest、Fallback 和 LoadBalance 分为不同策略组：URLTest会依据健康检查选择节点，Fallback更偏向按可用性回退，LoadBalance则按策略分配请求。具体字段和行为应以当前客户端内核文档为准，可查看mihomo Load-Balance 文档与mihomo API 文档。这些功能是管理手段，不等于节点本身一定稳定。
不要只看延迟：稳定性要看哪些指标
- 连接成功率：节点能否反复建立连接。频繁超时、握手失败或刚连上就断开，通常比延迟稍高更值得优先排除。
- 延迟与延迟波动：平均值或中位数可以帮助排序，但最大值和波动范围更能反映网页卡顿、远程桌面拖影和会议断续的风险。
- 丢包与抖动：实时通信对连续性更敏感。延迟不高但抖动明显，实际通话仍可能不稳定。
- 负载延迟：空闲时延迟很低，开始下载或多人共用后明显升高，说明不能只看空载测试。
- 持续吞吐：大文件和视频要观察一段时间，而不是只看测速开始阶段的瞬时峰值。
- 长连接表现：办公、会议和远程桌面更关心连接能否保持，而不是单次请求是否成功。
- 路径与协议兼容：节点标签不能直接证明线路类型、真实地区或实际路由。必要时用 pathping、MTR 或客户端日志辅助判断，并把结果限定在本次设备和测试目标上。
Windows 的 pathping 会对路径中的中间路由和链路进行多次探测并计算统计结果，但 Microsoft 也说明，某个路由器自身丢弃 ICMP 回包，不一定代表它转发业务流量同样丢包。因此，路径工具适合定位线索，最终仍要结合具体端口和真实业务验证。
按场景做取舍：低延迟不一定是最佳节点
| 遇到的情况 | 更合理的判断 | 建议操作 |
|---|---|---|
| 节点A延迟最低，但晚高峰经常超时 | 高峰期可用性优先于空闲时最低延迟 | 把高峰期成功次数更高的节点设为主用 |
| 节点B速度快，但视频拖动后容易断流 | 持续吞吐和长连接比瞬时峰值重要 | 延长播放与下载测试，记录断流和恢复时间 |
| 节点C地区合适，但办公登录后频繁重连 | 固定会话更需要出口连续和连接稳定 | 使用固定选择，另留同用途备用节点 |
| 所有节点同时变慢 | 不应立即认定为节点全部失效 | 先检查本地网络、DNS、系统代理、TUN、订阅和客户端日志 |
| 只有一个网站打不开 | 可能是目标服务、规则或DNS问题，不一定是节点质量 | 换目标测试，并分别比较直连、代理和不同DNS结果 |
如果所有节点、所有设备在同一时间都异常，优先检查本地网络和客户端接管；如果只有某个节点异常，优先复测该节点；如果只有某个应用异常，则检查应用代理支持、规则匹配和DNS路径。不要用一次测速结果替代分层排查。
服务和节点之外，还要核对这五项
- 试用与退款规则：先确认是否有明确的试用、退款、流量或设备限制，避免只按宣传页面的“高速”“专线”等词判断。
- 节点更新与故障通知：看服务方是否说明维护、下线、替换和异常通知方式；无法核实的内容不要当成稳定性证据。
- 隐私政策：不要把账号密码、财务资料、客户文件或其他敏感数据放入未经确认的连接环境中。
- 协议和客户端兼容：节点能否在你的 Windows、macOS、iOS 或 Android 客户端中正常使用，要以实际导入、连接和业务验证为准。
- 合规边界：仅在所在地区法律、网络管理要求和目标服务规则允许的范围内使用，并确认办公数据处理符合组织安全政策。
选择结果最好写成一张自己的记录表：节点名称、测试日期、设备、网络、客户端模式、普通时段结果、高峰时段结果、真实业务结果、失败现象和备用节点。这样下次遇到变慢或断线时，可以判断是节点变化，还是本地环境变化。
常见问题
代理节点延迟多少才算稳定？
没有适用于所有用途的统一数值。网页和普通办公通常可以先比较延迟中位数与波动范围；会议、远程桌面和实时通信应优先观察丢包、抖动与长连接；视频和下载还要看持续吞吐。应在相同设备、网络和时间条件下横向比较，而不是套用单一门槛。
为什么最低延迟的节点反而不好用？
延迟只反映某类测试的往返时间，不能代表高峰期拥塞、丢包、负载延迟、协议兼容或真实业务表现。先用低延迟做初筛，再完成至少三轮复测和实际使用验收，结果更可靠。
代理节点测速时应该测试几次？
建议至少三轮：普通时段、高峰时段和间隔后的复核。每轮使用相同设备、客户端模式、测试目标和网络环境，并记录成功次数、典型延迟、波动范围和失败现象。次数本身不是保证，条件一致更重要。
自动选择节点和手动固定节点怎么选？
网页等短连接场景可以使用健康检查或自动选择来减少手动切换；固定账号、长期会话、远程办公等场景更适合先固定主节点，并保留一个备用节点。自动负载均衡可能改变出口或连接路径，是否适合要看应用规则和会话要求。
所有节点都连接不上，应该先换节点吗？
先不要连续更换节点。检查系统代理、客户端模式、TUN、订阅是否更新成功、DNS、设备网络和客户端日志；再用另一个网络或设备做对照。如果只有一个节点失败，再重点排查该节点；如果全部设备同时失败，应优先判断本地网络或配置问题。
Android 的私人 DNS 会影响节点判断吗？
可能影响域名解析路径，因此排查时应记录当前设置，并按需比较关闭、自动或指定提供商三种状态，完成后恢复原配置。Android 官方说明了这三种选项，且私人 DNS只保护DNS查询与回答，不等于保护所有网络流量，可参考<a href="https://support.google.com/android/answer/9654714?hl=en-GB">Android 官方帮助</a>。