典型场景是：VPS标称10Gbps，测速只到800Mbps，持续压测却上不去，单连接更明显，延迟与重传同时升高。带宽数字只是接口上限，并不保证vCPU、队列、宿主机和链路持续供数。只看峰值，常把带宽整形失真误判为线路缩水。随身服务器可作多节点对照，结论仍要回到队列与丢包计数。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：liteserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先看发送侧。tc -s qdisc show中的qlen、backlog、drops与overlimits反映等待队列。若qdisc队列积压持续增长、出口速率却贴着固定上限，优先怀疑整形规则或vCPU调度；令牌突发还会造成“峰值高、持续带宽低”的错觉。
再看虚拟化通道。virtio-net通过多队列和vhost-net把guest描述符交给宿主机；描述符补充过慢或宿主机线程繁忙，会表现为virtio队列饱和。guest丢包，如rx_queue_*_drops，与宿主机vhost统计应一起看，虚拟网卡显示10Gbps不代表通道未受限。
guest与宿主机的高包率都会挤占各自的接收预算。NAPI每次清理数量有限，软中断或ksoftirqd调度稍慢，报文可能堆满网卡环形缓冲区，出现rx_no_buffer_count、rx_missed_errors或rx_dropped等计数。缓冲区太小会丢突发流量，太大则可能只增加延迟，不会凭空提高吞吐。
判断时固定并发、报文长度、持续时间和MTU，每秒同时采集tc、ethtool -S、mpstat、/proc/softirqs和ss -ti。不要用一次测速截图与累计计数器直接比较，要按时间序列对齐“队列增长丢包重传”的先后关系。
证据链要闭环：整形上限存在且overlimits上升，多为qdisc限速；%soft升高并伴随ring miss，偏向软中断处理延迟；guest队列长期满且宿主机同队列有压力，才考虑virtio通道；本机无丢包却持续重传，则转查MTU、路径拥塞和TCP窗口。
常见踩坑有三类：把短测峰值当持续吞吐；忽略TSO/GRO等卸载造成的包数错觉；以及重置累计计数后继续沿用旧结论。调整ring或队列后必须重新压测，并观察延迟、吞吐和重传是否同时改善；若只让一项变好，往往只是把瓶颈移到了下一层。
测速显示带宽已满，不等于有效吞吐正常。qdisc队列积压常发生在出口整形器之后：令牌补充赶不上突发流量，数据会等待、排队甚至被丢弃。先看tc -s qdisc的backlog、drop、overlimits，再对照网卡丢包计数；只有drop增加，不能直接认定物理链路拥塞。
VPS中，virtio队列饱和常早于宿主机带宽上限出现。前端队列满时，虚拟设备取包不及时，流量看似很高，应用却会卡顿。用/proc/interrupts和/proc/softirqs确认软中断是否集中在单核，并检查virtio-net队列数量、启用状态及中断亲和性。若处理集中在一个vCPU，可测试把中断分散到其他vCPU；不要盲目加队列，否则可能只是把瓶颈推向宿主机物理队列。
网卡环形缓冲区过小会频繁触发中断，过大则可能掩盖延迟。先用ethtool -g查看RX/TX ring，再用ethtool -S核对miss、timeout、no buffer、reset计数。调整时一次只改一个参数，并同时比较吞吐、丢包、重传与软中断延迟。RX ring可适度增加，但TX ring并非越大越好，仍受qdisc、virtio队列和CPU共同限制。
不少“带宽高、速度低”来自带宽整形失真。HTB/TBF的rate、ceil、burst、cburst若与测速模型不匹配，单连接会长期低于上限，多连接并发又可能突然耗尽令牌。检查父类、子类和整形器实际挂载位置，并用tc -s class查看borrowed、overlimits。临时移除整形器做A/B测试，比反复调参更可靠。
常见坑包括：拿单流结果对比多流上限；忽略MTU、分片和TCP重传；把缓存中的瞬时下载当成稳定吞吐；用ping低延迟代替应用性能；直接在生产环境关闭qdisc。应固定测速时段、并发数、报文大小和目标端口，并用ss -ti查看rtt、retrans、cwnd，确认瓶颈不是应用读取慢或TCP窗口受限。
最终按此顺序执行：①记录ip -s link、ethtool -S，区分发送、接收、丢包和重传；②用tc -s qdisc/class定位队列与整形瓶颈；③检查virtio队列、vCPU软中断分布及宿主机steal time；④核对ring大小和驱动计数；⑤做有或无整形、单流或多流、不同包长的对照测试；⑥每次只改一个变量，复测吞吐、RTT、重传和错误率，再决定是否扩容或调整队列。
