ping 一个包都不丢，文件却传到一半卡死，这中间差的那一段到底在哪？
差在测的不是同一条路：ping 发的是 ICMP，一秒一个包，而且挂了 SOCKS5 之后它根本不进隧道；传文件时 TCP 一秒切出几百上千个段，只要几个段没等到确认，发送端就会重发。判断这类问题只有一个动作——取五分钟内「已重传段数 ÷ 已发送段数」的差值。站内 4 元档（沧海）与 6 元档（天行、鲸云）的线路，两条线读数差一个数量级才说明是线路差异；差两三成在无线环境下属于噪声，不值得为它换平台。
🔗 快速入口：一站式注册入口（24 家平台自助开通） ｜ 价格中心（全平台横向比价） ｜ 代理工具中心（客户端与配置教程）
文中价格按 30 天套餐口径列示，核实于 2026-11-03；价格如有调整，以平台后台实时显示为准。
| Windows | netstat -s -p tcp → 已发送的段 / 已重传的段 |
| Linux | nstat -az TcpOutSegs TcpRetransSegs；单连接看 ss -ti 的 retrans |
| 判读门槛 | 同机同时段换线，差一个数量级才算真实差异 |
ping 全绿，文件却传不完：差的不是同一条路
ICMP 回显请求是逐个发的，默认一秒一个，一个包几十字节；TCP 传文件是按 MSS 切段连续发的，10M 带宽下每秒也是上千个段。用 100 个 ICMP 样本去推断几十万个 TCP 段的处境，样本量差了三个数量级，中间任何一次瞬时拥塞都测不到。
更关键的一点常被忽略：常规 SOCKS5 客户端只实现 CONNECT（建立 TCP 连接），ICMP 不会被转发。也就是说，挂着代理去 ping 目标站，测的是你本机宽带直连的那条路径，跟代理线路一点关系都没有；真要验线路，得用走代理的 HTTP 或 TCP 请求，而不是 ping。
链路设备对 ICMP 的处理也普遍特殊。不少机房和运营商对 ICMP 限速、降优先级，甚至只给骨干节点回包，于是 ping 的丢包率既可能虚高，也可能虚低。这也是为什么有人 ping 一切正常、业务却跑不起来，反过来也有人 ping 一片红、实际用着没感觉。
| 测法 | 实际测的是什么 | 能不能反映代理线路 |
|---|---|---|
| ping 目标域名 | 本机到目标的 ICMP 往返 | 不能，ICMP 不进 SOCKS5 |
| 浏览器打开一个重页面 | TCP 连接、TLS 握手、首屏资源 | 能，但只看得到”成不成” |
| 持续上传或下载一个文件 | 整条 TCP 流的稳定吞吐 | 能，连续流量才暴露重传 |
| 平台后台的线路检测 | 从机房侧发起的探测 | 能，但测的是机房到目标 |
站内的代理线路检测做的是 TCP 建连与握手层面的验证，它回答”通不通”；要看”稳不稳”，还得回到本机的重传计数。
重传有三种触发，丢包只是其中一种
发送端每发出一段数据就等对方的确认（ACK）。等不到确认时它不会无限等，而是按三种机制中的一个重发，这三种机制的成因完全不同。
最长的一种是超时重传。发送端根据往返时间估一个等待上限，超过就重发，并且每失败一次把等待时间翻倍，避免把已经拥塞的链路压得更死。第二种是快速重传：后面序号的段陆续到了，接收方每收到一个越序的段就回一个重复 ACK，发送端连收三个重复 ACK 就判定中间那段丢了，不等超时直接重发。
第三种最容易被误判：乱序。包的先后顺序在链路上被打乱，接收方看到越序同样回重复 ACK，发送端同样重发——可那段数据其实一点没丢，只是晚到了。于是”重传率高”和”线路丢包”之间并不能画等号，必须再叠一个条件：吞吐有没有掉下来。
| 触发 | 链路里发生了什么 | 是否真丢 | 谁的问题 |
|---|---|---|---|
| 超时重传 | 等不到 ACK，等待上限被击穿 | 多数是，也可能 ACK 自己丢了 | 链路或目标站 |
| 快速重传 | 连收三个重复 ACK | 多数是 | 链路 |
| 乱序引发 | 多路径负载均衡把包打散了顺序 | 没有 | 不是故障，不用处理 |
| 窗口满探测 | 对方处理不过来，接收窗口被塞满 | 没有 | 目标站侧或本机内存 |
所以看到重传计数在涨，先别下”线路差”的判断。看同一段时间里吞吐有没有跟着掉，是分成两种完全不同的病的关键一步。
量重传率：用差值，别用开机以来的累计
操作系统的这两个计数从开机起一直累加，重启才清零。直接读出来的数除以发送段数，算出的是这台机器过去几天甚至几个月的历史平均值，对判断”刚才那五分钟”毫无帮助。正确做法是取差值：跑业务前记一次，跑五到十分钟再记一次。
分母要选”发出的段数”，不是字节数——重传是段级别的行为，用字节算会得到没有意义的数。另外统计到的只是本机发出方向，也就是上行；下行的丢失只能在接收侧或抓包时看到。
| 系统 | 命令 | 取哪两个数 |
|---|---|---|
| Windows | netstat -s -p tcp |
已发送的段、已重传的段 |
| Linux | nstat -az TcpOutSegs TcpRetransSegs |
TcpOutSegs、TcpRetransSegs |
| Linux 单连接 | ss -ti |
retrans 后面两个数，直接是比率 |
| macOS | netstat -s -p tcp |
sent、retransmitted 两行 |
| 抓包 | 过滤器 tcp.analysis.retransmission |
重传条数 ÷ 该流总包数 |
ss -ti 是这几条里最省事的：它按连接给出重传段数和总段数，不用自己做减法，也不用等一个时间窗。缺点是只保留当前还活着的连接，连接一断记录就没了，所以发现卡顿时要立刻在服务器上跑一次。
| 记录项 | 填什么 | 为什么要它 |
|---|---|---|
| 时间窗 | 开始与结束，精确到分钟 | 平台查日志、判断是不是高峰 |
| 发出与重传 | 前后两次读数，算差值 | 把历史累计剔掉 |
| 目标与端口 | 卡住的那个站，不是随便找的站 | 排除目标站侧限速 |
| 当时的并发 | 几个窗口、几条连接同时在跑 | 分清是跑满还是线路坏 |
同一台机器，重传只在某个站上高
把目标固定成一个，跑五分钟，再看另外两个不同运营商的目标。如果只有一个站高，问题基本不在你的线路上——对方限速、反爬策略、或者是它自己的上行拥塞，换多少条代理都一样。这一步能排掉相当一部分”换线无效”的折腾。
反过来，如果三个不同目标都高，再回到本机做减法：换有线、关掉同网段的其他大流量任务、看路由器是不是在跑 QoS，逐个排除。无线链路的误码率天生比有线高一个量级，笔记本连 2.4G、隔一堵墙，重传读数难看是常态。
| 触发源 | 留下的痕迹 | 该查哪一段 |
|---|---|---|
| 本机无线或网卡 | 换有线立刻下降，本地网关也重传 | 本机这一跳 |
| 出口线路拥塞 | 只对远端高，本地网关干净，多条线差别明显 | 平台到目标这一段 |
| 套餐带宽被打满 | 跑满时才高，降并发就回落 | 档位额度，不是线路质量 |
| 目标站侧 | 只对单一站点高，常伴随 RST、403 或验证码 | 对方，换线无效 |
高重传要配合吞吐一起看，才有结论
重传率高但下载速度照常，多半是乱序或轻微拥塞，TCP 自己已经吸收了，业务侧无感。真正需要动作的是”重传抬升 + 吞吐掉下来”这一格：这说明确实有段在反复丢，发送端一半时间在补发。
还有一格容易被误读：重传不高、吞吐也低。这往往跟重传无关，是单连接限速、TCP 窗口太小、或者并发开得太多把带宽切成很多份，每条都跑不快。这类问题在站内跑不满速的四段定位里已经拆过，本篇不重复。
| 重传 | 吞吐 | 结论 | 动作 |
|---|---|---|---|
| 高 | 正常 | 乱序或轻微拥塞，已被 TCP 吸收 | 不用处理 |
| 高 | 明显下降 | 真丢包，且在持续丢 | 换线或报障，带上差值 |
| 低 | 明显下降 | 跟重传无关：限速、窗口、并发切碎 | 查档位与客户端设置 |
| 低 | 正常 | 这条线没问题 | 去查业务代码或目标站 |
能自己改的三件事，和只能换档的两件事
先分清归属。客户端侧的并发数、连接复用、有线还是无线，这些不用花钱，改了立刻能看到读数变化。档位带宽是被套餐写死的，4 元档给的是 3 到 5M 的可用上限，十个窗口同时拉流必然跑满，跑满就必然出现排队丢包——这种”重传”加钱能解决，但只能靠升档，不能靠换平台。
真正值得换平台的只有一种情形：同一个目标、同一个时段、同样并发，两条线的重传率差一个数量级。差异不到这个量级就换，换完大概率是同一水平，白折腾一次还得重新配客户端。
| 处置 | 适用前提 | 代价 |
|---|---|---|
| 降并发、合并连接 | 重传随并发数同步上升 | 单窗口速度下降 |
| 换有线、改 5G 频段 | 本地网关也重传 | 几乎为零，先做这个 |
| 升一档带宽 | 跑满套餐上限时才出现重传 | 每月多几十元，未必需要 |
| 换平台 | 同目标同时段两条线差一个数量级 | 重配客户端，旧余额处置 |
| 改系统重传参数 | 不建议，除非你能说清改的是哪一项 | 故障期被拉长，问题被掩盖 |
最后那条值得多说一句。把重传次数上限调大、把超时时间调长，故障看起来是”好了”，实际是发送端愿意等更久才放弃，卡顿的时间反而变长。这类参数只适合在你能明确解释每一项含义时动手。
报障时把时间窗和前后读数一起给
只说”卡”，平台只能回你”线路正常”。把三样东西一起发过去，处理速度会完全不同：精确到分钟的时间窗、前后两次的段数与重传数、卡住时的目标站和并发数。这三样让对方能直接去查那个时段的节点日志，而不是从零开始猜。
如果对方要路径，跑一次 tracert（Windows）或 mtr（Linux、macOS）附上。同一时刻本机到目标的路径节点与丢包分布，比任何文字描述都有用。注意别用 ping 的结论替代，前面说过，它走的不是代理那条路。
| 材料 | 格式 | 作用 |
|---|---|---|
| 时间窗 | 2026-11-03 14:05 至 14:20 | 定位节点日志的时间段 |
| 读数 | 发送段与重传段的前后四个数 | 证明丢的是数据段 |
| 路径 | tracert 或 mtr 完整输出 | 指出可疑节点 |
| 复现方式 | 哪个站、几个窗口、单文件多大 | 让对方能自己复现一次 |
它和丢包、MTU、限速的分界线在哪
这四类故障的体感都在”卡”，但落点完全不同。重传看的是 TCP 层有没有被确认；丢包看的是 ICMP 与 TCP 在哪一段掉的；MTU 看的是大包能不能过；限速看的是谁在压你的速率。按症状对号入座，比逐个试要快得多。
有个粗略的分法：小包全通、大包全丢，去查 MTU，站内MTU 与 MSS 那篇已经把量法和改法写全；连不上、连上就没流量，去看丢包的三段定位；能连上、速度一到某个数就上不去，先怀疑限速。
| 症状 | 最可能的落点 | 怎么确认 |
|---|---|---|
| 小包通、大包全丢 | MTU 与 MSS 不匹配 | 禁止分片 ping，找临界值 |
| 连不上、连上没流量 | 某一段在丢包 | TCP 握手测第一段，tracert 看后面 |
| 速度卡在一个固定数 | 档位上限或单连接限速 | 多连接并发能不能突破 |
| 忽快忽慢、进度条停住 | 重传，确认丢失后补发 | 取五分钟重传差值，配合吞吐 |
官方入口与相关页面
要按档位横着比价，先在价格中心对齐 24 家的月价与带宽；客户端侧的并发、连接复用与协议切换步骤，在代理工具中心有现成教程；想把手头这条线一次测清楚，IP 综合检测中心的线路、测速与业务模拟三项都能免费跑，速度实测则用来对照本机读数是否和实际带宽对得上。要直接开通，走聚合注册入口选平台即可，注册后按页面提示填邀请码。
常见问题
Q1：ping 显示 0% 丢包，是不是就能排除线路问题？
A：不能。ICMP 样本少，而且挂了 SOCKS5 之后它不进隧道，测的是本机宽带那条路。要验代理线路，跑一段持续的 TCP 传输再看重传差值。
Q2：重传率多少算高？有没有一个通用阈值？
A：没有可跨环境套用的数。无线、4G、跨省长途干线天生比同城有线高，绝对值没有可比性。用同机、同时段、换线对比，差一个数量级才有意义。
Q3：Linux 上 ss -ti 的 retrans 是 0/0，说明没问题吗？
A：0/0 表示这条连接还没发出过段，或连接刚建立。跑一段真实流量再看，数字会变。想按时间窗统计，用 nstat 的前后差值更稳。
Q4：换了 L2TP 以后重传会不会消失？
A：不会自动消失。L2TP 只是把整机流量放进隧道，外层丢包会变成内层重传，读数一样会涨。它能解决的是”按窗口走代理”的限制，不是线路质量问题。
Q5：4 元档跑十个窗口，重传高是正常的吗？
A：大概率是跑满了。3 到 5M 的可用上限分给十个窗口，每条连接分到的带宽很小，排队丢包就会出现。把并发降到三五个再看，读数回落说明是档位问题，不是线路坏了。
Q6：报障一定要给命令输出吗，只说卡不行吗？
A：只说卡，对方只能回”检测正常”。给出时间窗、前后读数与目标站，对方能直接查那个时段的节点日志，处理效率差很多。
📚 相关阅读
更多帮助
如需获取更多帮助，请访问官网：socks5ip.com.cn
🛠️ IP综合检测中心：IP质量/线路/测速/业务模拟免费测
📝 官方注册入口：https://linkdd.cn/socks5ip（24 家平台自助开通，注册后按提示填邀请码）
💬 微信：17720135827 — 7×24h在线
全网低价IP｜聚合24家代理IP平台，全部免费测试，先测后买零风险
评论0