1. 破除迷信：Ping 延迟与下载带宽的物理区别
初学者经常将「延迟」与「带宽」混为一谈：
- **Ping 延迟（RTT）**：好比从北京到上海高铁的**最高车速**（物理光速决定）；
- **下载带宽（Mbps）**：好比高铁列车的**车厢载客容量**（机房出口吞吐决定）；
- 一辆车速极快但只有 1 节车厢的微型车（低延迟、小带宽），运载能力远远不如一列车速稍慢但拥有 16 节大车厢的高铁（高带宽）。
💡 测速节点的 Ping 只能反映连接建立响应快慢，无法代表真实吞吐上限。
2. BDP 带宽时延积与微量丢包的致命打击
TCP 协议通过滑动窗口机制控制发包：
- **理论公式**：最大吞吐速率 = `TCP 发送窗口大小 / RTT 延迟`；
- 如果一条线路存在哪怕 2% 的微小丢包；
- 传统的 TCP 拥塞控制算法（如 Cubic）会误以为网络严重塞车，**立即将发送窗口强行减半**；
- 导致虽然延迟只有 30ms，但发送窗口被死死压制在几 KB，下载速度自然宛如龟速。
bash
# Linux 终端查看当前 TCP 拥塞控制算法 (推荐启用 BBR 算法)
sysctl net.ipv4.tcp_congestion_control
# 输出为 bbr 代表已启用 Google BBR 高吞吐拥塞控制算法3. 跑满千兆带宽的实战调优方案
1. **使用多线程下载工具**：在 PC 上安装 IDM（Internet Download Manager），开启 16 线程或 32 线程并发下载，多条流同时发包冲破单线程窗口限制；
2. **换用高吞吐协议**：选择支持 Hysteria 2 或 VLESS XTLS 流控的节点；
3. **更换大带宽落地节点**：在客户端中挑选标有「大带宽 / 10Gbps」的专属下载节点。
❓ 常见疑问与排查步骤
用测速网站测速能跑满 500M，为什么看视频卡顿？
因为测速网站使用了上百个并发连接并发拉取，能够掩盖丢包；而流媒体播放器通常是单长连接流式缓冲，对单线程丢包极为敏感。
开启客户端的 TUN 模式能提升下载速度吗？
若 TUN 模式配置了 `stack: system` 或 `mixed` 并开启了巨型帧（MTU 9000），可以减少操作系统的分包开销，显著提升大文件吞吐性能。
为什么晚上的下载速度总是比白天慢一半？
因为晚高峰期间机场机房的总出站带宽被大量用户同时分享，触发了服务端的流量调度限速。