直播画面偶尔卡顿、声音断续或者清晰度突然下降，很多时候并不是服务器CPU性能不足，而是网络链路出现了短时拥塞、抖动或带宽突发。尤其是使用香港服务器承接大陆推流、海外平台转播或跨境直播时，线路质量、推流协议和流量分配方式，往往比单纯增加服务器配置更重要。

先判断丢包发生在哪一段链路

一套常见的直播链路通常包括：

主播端 → 公网线路 → 香港接入服务器 → 转码或转推节点 → CDN → 观众端

任何一段出现拥塞，最终都可能表现为直播卡顿。因此，排查时不能只对服务器IP执行一次Ping测试，而应分别检查主播到香港服务器、香港服务器到CDN以及观众到播放节点的网络质量。

建议在业务高峰期连续执行：

mtr -rwzc 200 服务器IP
iperf3 -c 服务器IP -u -b 50M -t 60

MTR主要用于观察路由跳数、延迟变化和持续丢包，iperf3 UDP测试则可以模拟直播流量，更直观地查看实际吞吐、抖动和丢包率。

如果Ping没有明显丢包，但UDP测试丢包较高，通常说明链路可以正常连通，却无法稳定承载当前直播码率。

案例配置：用100M CN2承接直播推流入口

以一套常见的活动直播部署为例，接入节点采用A5IDC香港大带宽服务器：

• CPU：Intel Xeon Gold 6138，20核40线程

• 内存：32GB

• 硬盘：800GB SSD

• 带宽：升级至100M CN2

• IP数量：3个

该服务器主要负责接收主播推流、协议转换和向CDN回源，不直接承担所有观众的播放流量。

测试环境同时接入8路1080P直播，每路平均码率约6Mbps，基础推流流量约48Mbps。未做限制时，叠加录制上传、日志同步和CDN回源，瞬时出口一度达到90Mbps以上。

在晚间高峰时段，测试结果如下：

这些数值属于同一测试环境下的示例结果，实际表现仍会受到主播所在地、运营商线路和直播时段影响。真正起作用的并不是某一项参数，而是带宽余量、协议、队列和分发架构同时调整。

第一项优化：不要把带宽长期跑满

直播业务最容易忽略的问题，是只按照平均码率计算带宽。

例如8路6Mbps直播，理论流量为48Mbps，但实际运行中还会出现关键帧突发、重传流量、录制文件上传、监控数据和CDN回源请求。如果按照50Mbps准备出口带宽，网络很容易在高峰时段进入拥塞状态。

比较稳妥的做法，是将持续业务流量控制在出口带宽的60%—70%以内。100M带宽建议将稳定流量控制在60M—70M，剩余部分用于吸收短时突发和协议重传。

如果服务器同时承担推流接入和大量观众播放，即使总流量暂时没有跑满，两类业务也可能相互抢占出口。更合理的结构是：

• CN2线路负责大陆主播接入和控制接口

• 大带宽节点或CDN负责观众播放

• 录制文件和回放内容走独立存储或国际带宽

这样可以避免播放流量突然增长时，把主播的上行推流一起挤掉。

第二项优化：跨公网推流优先考虑SRT

RTMP部署简单、兼容性较好，但它主要依赖TCP传输。遇到跨运营商抖动或短时丢包时，TCP需要等待数据重传，容易出现延迟不断累积的情况。

对于活动直播、跨境直播或网络环境不稳定的主播端，可以使用SRT作为主播到香港服务器之间的推流协议。SRT基于UDP传输，同时支持丢包重传、延迟缓冲和链路加密，更适合质量波动较大的公网环境。

常见设置可以从以下范围开始测试：

• SRT延迟缓冲：200—500ms

• 单路1080P码率：4—8Mbps

• 关键帧间隔：2秒

• 码率模式：CBR或受控VBR

• 音频码率：128—192Kbps

延迟缓冲并不是越低越好。将SRT延迟设置为80ms，看起来更“实时”，但链路稍有抖动就来不及完成重传。普通活动直播可以先从300ms测试，再根据网络质量逐步降低。

第三项优化：控制系统队列，避免Bufferbloat

服务器出口接近满载时，大量数据包会堆积在网卡或系统发送队列中。此时虽然带宽利用率很高，但延迟可能从几十毫秒突然升到几百毫秒，这种现象通常称为Bufferbloat。

Linux服务器可以根据业务类型启用更合理的队列调度。对于以RTMP、HLS等TCP流量为主的服务器，可以检查是否支持BBR：

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

启用BBR时通常配合FQ队列：

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

需要注意，BBR主要优化TCP传输，对SRT这类UDP推流不会直接产生同等效果。SRT业务还需要提高UDP收发缓冲区，并在应用层设置合理的重传和延迟参数。

系统参数修改前应保留原配置，并通过实际压测判断效果，不建议直接复制一套参数到所有直播服务器。

第四项优化：检查MTU和分片问题

直播经过VPN、GRE隧道、云防火墙或多层转发后，实际可用MTU可能低于1500。如果数据包超过链路允许的大小，就可能发生分片甚至被直接丢弃。

可以通过禁止分片的Ping测试路径MTU：

ping -M do -s 1472 目标IP

如果1472字节无法通过，可以逐步降低数值。经过隧道或复杂跨境链路时，MTU可能需要调整到1400—1450之间。

MTU设置过大容易产生分片，设置过小则会增加数据包数量和协议开销，因此应以实际测试结果为准，而不是统一改成某个固定数值。

第五项优化：按运营商和时段测试线路

直播线路白天正常，不代表晚间同样稳定。大陆电信、联通和移动到香港的路由可能完全不同，同一条线路在20点至23点的表现也可能明显变化。

正式上线前，至少应完成以下测试：

• 电信、联通、移动分别推流测试

• 工作日和周末分别测试

• 白天与晚间高峰分别测试

• 连续推流不少于30分钟

• 记录丢包、抖动、码率和重连次数

如果主播来源比较固定，可以优先选择对应运营商优化线路；如果主播分布在全国多个地区，则需要考虑CN2、CMIN2、联通优化或多线BGP组合，而不能只看某一个地区的Ping延迟。

第六项优化：建立实时监控，而不是出问题后再测试

直播丢包通常具有明显的瞬时性。等直播结束后再执行Ping，网络可能早已恢复，难以定位真正原因。

服务器至少应监控：

• 网卡实时流量和峰值

• TCP重传数量

• UDP丢包与乱序

• 推流连接中断次数

• SRT重传率和RTT

• CPU软中断占用

• CDN回源失败率

可以使用iftop、nload、sar -n DEV、ss -s和tc -s qdisc查看基础网络状态，再结合SRS、ZLMediaKit或直播平台自身的监控指标建立告警。

当出口利用率持续超过70%、抖动突然升高或重传率连续增长时，应在画面明显卡顿前提前处理。

对于直播业务来说，降低丢包率并不等于单纯购买更大的带宽。线路选错、带宽没有预留、推流协议不合适或播放流量与推流流量混在同一出口，即使升级到更高配置，晚间高峰仍然可能出现卡顿。正式开播前进行一次覆盖三网、高峰时段和满负载的连续压测，通常比直播过程中临时调整服务器更稳妥。