判断连接质量需组合多种命令：用 ping -c 20 IP 查丢包率和 mdev（抖动），mtr -n --report 查中间节点异常，nc/curl 验证应用层端口和服务可达性，ss -i 或 /proc/net/snmp 查重传，避免单工具误判。
单纯用 ping 只能看连通性和基础延迟，真要判断“连接质量”，得组合多个命令、关注不同维度——丢包、抖动、路由稳定性、协议层响应，缺一不可。
怎么看丢包率和延迟抖动？
丢包和延迟波动（jitter）比单次 time=12.4 ms 更关键。持续丢包或延迟忽高忽低，说明链路不稳定，哪怕平均延迟很低也不代表质量好。
- 用
ping -c 20 example.com发 20 个包，看汇总里的0% packet loss和min/avg/max/mdev：其中mdev就是抖动值，超过 30ms 就值得警惕 - 避免 DNS 干扰：直接 ping IP（如
ping -c 20 8.8.8.8），排除域名解析失败导致的假丢包 - 加
-W 2缩短超时，防止个别包卡死拖慢整体统计；加-i 0.5控制发包间隔，避免被对方限速误判为丢包
怎么查真实路径和中间节点质量？
ping 只测终点，但问题常出在中间某跳。光看终点响应快，不代表整条路径健康。
- 用
mtr -n example.com（比traceroute更实用）：实时显示每跳的丢包率和延迟，一眼看出哪一跳开始丢包或延迟飙升 - 如果某跳显示
???或持续100% loss，不一定是故障——可能是中间设备禁 ICMP，但后续跳若恢复，说明问题在该设备策略，而非物理断连 - 加
--report参数（mtr -n --report example.com）跑 10 秒后出汇总报告，适合写日志或发给运维
怎么验证应用层是否真通？
TCP 层通 ≠ 应用服务可用。比如防火墙放行 ICMP 但拦截 80 端口，ping 正常但网站打不开。
- 用
nc -zv example.com 443测试目标端口 TCP 握手是否成功，返回succeeded!才算通 - 对 HTTP(S) 服务，用
curl -I --connect-timeout 5 https://example.com：看HTTP/2 200响应头 + 连接超时是否触发，比 ping 更贴近真实请求 - 避免误判：有些 CDN 或 WAF 会主动丢弃 ICMP 包，但放行 HTTP 流量，此时
ping失败而curl成功是正常现象
为什么 ss/netstat 不能反映连接质量？
ss -tuln 或 netstat -tuln 只告诉你“本机监听了哪些端口”或“当前有哪些连接”，它们不测量延迟、丢包、重传率——这些属于传输层和网络层行为，得靠主动探测工具。
- 你看到
ESTABLISHED状态，只表示三次握手完成，不代表数据能稳定收发；可能正经历高丢包、频繁重传，但状态仍维持着 - 想查重传情况？看
ss -i输出里的retrans字段，或直接读/proc/net/snmp中的TcpRetransSegs计数 - 别依赖
lsof -i判断质量：它只列进程和 socket，不提供任何性能指标
真正影响体验的是端到端的稳定性和响应一致性，不是某个命令的单次输出。同一时间跑 ping、mtr、nc，交叉比对结果，才能避开“看起来通、实际卡”的陷阱。
