代理丢包怎么测试？三层对照定位本地、线路与节点问题
简答：先关闭代理测试本地网络，再测试代理入口，最后用 curl 发起真实 HTTPS 请求。只有应用层请求也持续失败或超时，才能更有把握判断代理链路存在丢包或不稳定。
定义：代理丢包是数据包经过代理或隧道转发时未能按预期到达并返回，表现可能是超时、断流、重传、视频缓冲或请求成功率下降。
先试这一步：三层测试顺序与结果速查
不要只看客户端里的延迟数字。代理丢包至少要分成三层测试：本地直连、代理入口或隧道、真实应用请求。ICMP ping、mtr 和 curl 测到的是不同对象，不能互相替代。
| 层级 | 测试对象 | 适合回答的问题 | 不能单独证明什么 |
|---|---|---|---|
| 直连基线 | 路由器、运营商可达地址或固定目标 | 本地 Wi-Fi、网卡和基础网络是否已经异常 | 不能证明代理节点一定正常 |
| 代理入口 | 代理服务器地址、端口或 WireGuard 隧道内目标 | 节点入口是否可达，TCP 端口是否能建立连接 | ICMP 正常不代表 HTTPS 或视频长连接正常 |
| 应用层 | 经过 HTTP、SOCKS5 或隧道访问的 HTTPS 地址 | 真实请求是否超时、断流或成功率下降 | 单次失败不能直接归因于代理丢包 |
判断原则是：直连正常、代理入口异常，优先检查节点或线路；入口正常但 HTTPS 请求失败，继续检查代理协议、DNS、规则、MTU 和目标服务；只有在多个时间段、固定目标和同一节点上重复出现，才适合把问题记录为线路稳定性异常。
命令参数和功能说明可分别参考 Microsoft Test-Connection 文档、Microsoft Test-NetConnection 文档 与 curl 官方手册。
Windows：先测 ICMP，再测 TCP 端口和真实代理请求
以下命令适用于 Windows PowerShell。把 目标地址、代理主机、代理端口 和 测试网址 替换为实际值。不要把订阅地址、密码或带身份信息的代理串直接发给他人。
- 测试直连基线：
Test-Connection -TargetName 目标地址 -Count 30。它发送 ICMP echo request，可观察是否出现超时和 RTT 波动，但这一步没有经过应用层代理。 - 测试代理入口的 TCP 端口：
Test-NetConnection -ComputerName 代理主机 -Port 代理端口 -InformationLevel Detailed。重点看 TCP 测试是否成功；端口能连通只表示连接建立，不代表后续转发稳定。 - 测试 HTTP 代理：
curl.exe --proxy http://代理主机:代理端口 --connect-timeout 10 --max-time 30 -sS -o NUL -w "code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} " https://测试网址。 - 测试 SOCKS5 代理：
curl.exe --proxy socks5h://代理主机:代理端口 --connect-timeout 10 --max-time 30 -sS -o NUL -w "code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} " https://测试网址。其中socks5h表示由 SOCKS5 代理解析目标主机名；curl 官方文档区分了socks5与socks5h的解析位置。
如果 PowerShell 能 ping 通目标，但 curl 经代理反复超时，不能直接说是 ICMP 丢包；这更像是应用层代理、DNS、目标端口、规则或隧道路径需要继续拆分。若 TCP 端口都无法建立，先核对代理地址、端口、客户端模式和本机防火墙。
macOS 与 Linux：用 ping、mtr、curl 做对照
macOS 和 Linux 都可以使用 ping 与 curl。mtr 将 ping 与 traceroute 的观察方式结合起来，并持续显示各跳的统计；官方仓库同时提醒，中间路由器可能限制或不回应探测，因此某一中间跳显示丢包、但末跳正常时，不能单独认定该跳正在丢转发流量。可参考 mtr 官方仓库。
- 直连基线：
ping -c 30 目标地址。macOS 使用-c指定次数；Linux 的 ping 选项以本机手册为准。 - 查看路径和各跳统计：
mtr -r -w -n -c 60 目标地址。-r输出报告，-w使用宽格式，-n不做 DNS 反查，-c 60设置探测次数。没有 mtr 时先按当前系统的软件包说明安装；不要为了安装工具修改不熟悉的系统源。 - HTTP 代理：
curl --proxy http://代理主机:代理端口 --connect-timeout 10 --max-time 30 -sS -o /dev/null -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} ' https://测试网址。 - SOCKS5 代理：
curl --proxy socks5h://代理主机:代理端口 --connect-timeout 10 --max-time 30 -sS -o /dev/null -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} ' https://测试网址。
mtr 主要帮助观察路径和探测回应，curl 才是在测试一次实际 HTTPS 请求。若使用 WireGuard，通常没有 HTTP 或 SOCKS5 代理参数可填，应在隧道已连接的前提下，对固定目标执行 ping、mtr 或 curl，并记录是否走到预期接口；具体路由和 DNS 以当前客户端配置为准。
如何读结果：不要把中间跳丢包直接当成线路故障
| 现象 | 更可能的方向 | 下一步 |
|---|---|---|
| 直连 ping 就出现超时或明显波动 | Wi-Fi、网卡、路由器、运营商接入段 | 改用网线或另一网络复测，并同时测试本地网关与固定目标 |
| 直连正常，代理入口 TCP 端口无法建立 | 代理地址、端口、客户端模式或节点入口 | 核对配置，换同一服务的另一个节点，再重复测试 |
| mtr 中间某跳有丢包，但末跳无丢包 | 中间路由器限制 ICMP 或探测回应 | 不要仅凭该跳下结论，观察末跳和应用层请求 |
| 末跳也持续异常，curl 同时超时 | 路径末段、节点出口或目标服务 | 换固定目标、换节点、换时段，确认是否能复现 |
| curl 成功但视频仍卡顿 | 带宽、抖动、长连接、分片请求或播放器策略 | 用同一视频、同一节点和同一时段复测，记录开始播放、缓冲和断流时间 |
这里没有适用于所有地区、协议和目标服务的统一“合格丢包率”。同样的 ICMP 结果，可能因为目标限制回应而与真实转发质量不同；因此应把“探测结果”和“应用层成功率”放在一起看。
curl 的 code、连接耗时、首字节耗时和总耗时可以帮助区分“无法建立连接”“建立后迟迟没有响应”和“请求完成但整体变慢”。这些字段的含义与代理写法以 curl 官方手册为准。
代理丢包测试记录表：固定变量后再横向比较
为了避免把不同条件的结果混在一起，建议每次记录以下项目：
- 时间：记录具体日期和时间，至少覆盖一次出现问题的时段与一次正常时段。
- 本地环境：Wi-Fi 或网线、网络运营商、设备系统，以及是否同时运行其他隧道或代理。
- 节点信息：只记录节点名称或编号，不要公开订阅链接、账号和密码。
- 测试目标：固定一个直连目标、一个 HTTPS 目标；视频验证时固定视频页面和清晰度条件。
- 命令结果：记录 ping 的超时情况、mtr 末跳统计、curl 的 HTTP 状态码和总耗时。
- 重复方式：同一节点至少在不同时间复测，再与另一个节点进行横向比较。
| 日期时间 | 网络环境 | 节点 | 直连结果 | 入口 TCP | mtr 末跳 | curl 结果 | 视频或长连接表现 |
|---|---|---|---|---|---|---|---|
| 填写 | 填写 | 填写 | 填写 | 成功/失败 | 填写 | 状态码与耗时 | 播放/缓冲/断流 |
如果只有单次 ping 或单个中间跳显示异常，结论应写成“需要复测”；如果直连、代理入口和真实 HTTPS 请求在多个时段呈现一致异常，才可以把问题升级为线路或节点稳定性问题，并把完整记录提供给维护人员。
常见问题
ping 代理服务器没有丢包，为什么视频仍然卡？
ping 主要测试 ICMP 探测回应，不能覆盖 HTTP、HTTPS、视频分片、长连接和客户端规则。应继续用 curl 测试真实 HTTPS 请求，并在相同节点、相同时间和相同视频条件下复测。
mtr 中间一跳显示 100% 丢包，是不是线路坏了？
不一定。mtr 官方说明指出，中间路由器可能限制或不回应探测。只要后续末跳仍正常，就不能仅凭该中间跳判定真实转发丢包；应看末跳统计和应用层请求。
HTTP 代理和 SOCKS5 代理的 curl 写法有什么区别？
HTTP 代理使用 <code>--proxy http://主机:端口</code>，SOCKS5 使用 <code>--proxy socks5h://主机:端口</code>。<code>socks5h</code> 让代理解析目标主机名，适合需要把 DNS 解析也交给代理处理的测试场景。
WireGuard 能不能直接用 HTTP 代理参数测试？
WireGuard 是隧道接口，不等同于 HTTP 或 SOCKS5 代理。连接隧道后，应对固定目标执行 ping、mtr 或不带代理参数的 curl，并检查当前路由和 DNS 是否符合配置；具体命令以系统和客户端说明为准。
测试多少次才能判断代理真的丢包？
没有适用于所有线路和目标的统一次数或固定阈值。建议固定目标、节点、网络环境和命令，在正常与异常时段重复记录；单次超时或单个中间跳异常只能作为线索，不能直接下最终结论。