为什么我的rtmp服务器很卡，rtmp推流延迟高如何优化？

RTMP服务器卡顿的根源，90%以上出在网络链路的瓶颈、并发连接处理能力不足以及编码参数不匹配这三个层面，而非服务器本身“不够快”。

rtmp服务器很卡？先分清是“源头卡”还是“转发卡”

很多人一遇到rtmp服务器很卡,第一反应就是升级服务器CPU和内存，但在我接触的实际案例中，相当一部分卡顿其实发生在推流端到服务器之间的网络链路上，或者服务器转发到播放端的过程中。

• 源头卡：推流端上行带宽不足，导致视频流在进入服务器前就已经丢包，这种卡顿表现为所有观看端同步卡顿，且服务器CPU占用率很低。
• 转发卡：服务器下行带宽跑满，或者并发连接数超过单进程处理极限，这种卡顿表现为人数越多越卡，服务器网络流量曲线接近平顶。
• 混合卡：服务器本身网络栈配置不当，比如TCP拥塞控制算法默认设置不适合直播场景，导致延迟堆积。

你需要做的第一步,是在服务器上执行 iftop 或 nload 观察实时流量，如果流量远没跑满带宽但依然卡顿，请重点检查推流端的码率设置很多人在家用宽带跑8Mbps的推流码率，而上行带宽实际只有6Mbps，这时候任何服务器配置都救不了你。

排查rtmp推流卡顿的五个核心维度

带宽计算：你的真实承载能力是多少

技术圈有个流传很广的粗略公式,我认为对直播场景依然适用：总上行带宽（Mbps）÷ 单路推流码率（Mbps）= 理论并发推流上限。

举个例子,你的服务器带宽是100Mbps，承接5Mbps的直播流，理论上最多允许20路同时推流，但这只是理论值，行业共识认为需要至少预留30%的冗余带宽来处理TCP重传和突发流量，所以实际安全推流数也就14路左右，超过这个数字，rtmp服务器很卡就是必然结果。

服务器配置的“木桶效应”

直播服务器对CPU的核心数和主频敏感,但更关键的是网卡中断队列与CPU核心的绑定关系，如果你的服务器网卡是千兆单队列，而CPU有16个核心，那么所有网络中断都会压在核心0上。

# 查看网卡队列配置
ethtool -l eth0

如果看到 Combined 为1，而你的业务并发高，带宽跑不满但CPU核心0满载，这就是典型瓶颈，解决方案是开启多队列：

ethtool -L eth0 combined 4

Nginx-RTMP的 worker_processes

参数应该设置为CPU核心数，而不是默认的1。

协议选择：为什么部分场景下RTMP显得力不从心

RTMP基于TCP,这种协议在弱网环境下（如跨地域传输、移动网络）重传机制会导致延迟线性增长，如果你用rtmp服务器做全国性的直播分发，尤其是一线城市推到二线城市观看，丢包率超过1%时，卡顿就会非常明显。

近年有个明显趋势是,HTTP-FLV和SRT协逐渐在替代RTMP做源站推流，SRT协议内置了丢包重传和自适应码率，在公网环境下的稳定性远超RTMP，但问题是，很多旧的采集设备只支持RTMP推流，这时候你需要加一层协议转换服务，把RTMP转成SRT再上行，但这会增加转发延迟。

推流客户端：OBS参数设置的常见坑

OBS是多数人使用的推流工具,但很多人不知道的是，OBS里的“码率控制”和“关键帧间隔”需要按服务器配置联动调整。

• CBR（固定码率）：直播推流必须选择CBR，而不是VBR，VBR在画面静止时码率下降，动静切换时码率猛增，容易瞬间打满带宽导致卡顿。
• 关键帧间隔：对应Nginx-RTMP配置里的 gop_cache 参数，如果OBS里关键帧间隔设置过大（比如5秒以上），播放端首屏加载会慢，但不会出现持续卡顿。
• CPU编码预设：使用 veryfast 要比 slow 消耗更少的CPU，但要牺牲画质，如果服务器CPU占用持续超过80%，rtmp服务器很卡就是预料之中。

一个容易忽略的细节：OBS的“网络”测试结果并不等于实际推流质量，你应该在推流时用 ffprobe -rtmp_url 实时监控实际的接收比特率是否和设定值吻合。

播放端与并发连接的处理逻辑

很多人忽略了一个关键点：RTMP播放本身也是消耗上行带宽的，Nginx-RTMP的 rtmp 模块负责任务分发，但当播放请求大量涌入时，它不仅仅是“转发”数据，还需要维护每个连接的状态，如果使用默认的 max_connections 设置，连接数超过限制时播放端会直接黑屏卡死。

排查并发连接数的命令是：

ss -s

CLOSE-WAIT 状态的连接数异常多，说明播放端没有正常断开，这些僵尸连接会逐渐耗尽服务器文件描述符，导致新连接无法建立。

优化rtmp服务器卡顿的实战操作清单

Nginx-RTMP配置调优的关键参数

执行 vi /usr/local/nginx/conf/nginx.conf，核心参数参考这样的配置：

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        ping 30s;
        ping_timeout 10s;
        max_connections 5000;
        application live {
            live on;
            gop_cache on;
            wait_key on;
            idle_streams off;
        }
    }
}
http {
    server {
        listen 8080;
        location /stat {
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }
    }
}

• chunk_size：推荐4096，过小会增加CPU中断次数，过大会提高延迟，这个值影响直播延迟和网络传输效率之间的平衡。
• gop_cache on：理论上可以加速播放端首屏加载，但会消耗内存，如果你对首屏速度不敏感，可以关闭以降低内存占用。
• idle_streams off：当推流端断开后立即回收资源，避免残留连接占着内存不放。

修改配置后执行 /usr/local/nginx/sbin/nginx -t 验证语法，/usr/local/nginx/sbin/nginx -s reload 生效。

内核网络参数的针对性调整

即使应用层配置优化了,操作系统内核默认参数也可能在拖后腿，修改 /etc/sysctl.conf 加入以下内容：

net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 5000

执行 sysctl -p 使生效。netdev_max_backlog 这个参数很关键，它决定了网卡接收队列的长度，默认只有1000，如果瞬间涌入大量RST包或SYN包，队列一旦溢出，数据包就会直接丢弃，表现为无规律、间歇性的卡顿。

不要随意关闭TCP时间戳或开启 tcp_tw_reuse，直播服务器长连接多，这些优化在某些内核版本下反而会引发数据包异常。

如果要做得更彻底：新增协议INX服务流程

如果你的客户集中在移动端观看,建议使用HTTP-FLV协议替代RTMP作为分发协议，RTMP在移动端浏览器里的兼容性不好，而且跨地域的TCP长连接极易被运营商中断，Nginx-RTMP官方支持 rtmp_translate 功能，但配置复杂，更简单的方案是使用 SRS 作为源站，它原生支持RTMP转HTTP-FLV转发，兼容性和性能比纯Nginx更优。

网络链路的专项检查手段

针对rtmp推流卡顿和延迟叠加的情况,分三步走：

1. 用 ping -t 服务器IP 测试推送链路的延迟和丢包情况，观察丢包率是否超过1%

   

   。

2. 用 mtr 服务器IP 检查路由的每一跳，如果发现某一跳在晚间高峰时段丢包率飙升，说明是跨运营商的问题。
3. 用 iperf3 -c 服务器IP -p 1935 -b 10M 测试到服务器的TCP吞吐量，如果带宽测试不达标，任何应用层调优都是白费功夫。

服务器接入IPLC国际专线或BGP多线机房,能解决大部分跨运营商丢包问题，但价格较高，华东地区（如上海、杭州）的BGP机房单线在几百元到上千元月付不等，具体要看机房的规模和品质，如果你不得不使用单线机房，建议让推流端和播放端都走同一边。

升级方向：从“临时扩容”到“架构调整”

当你的直播间峰值观众数超过千人,单台rtmp服务器的带宽和连接数就会成为硬瓶颈，行业内成熟的应对方案是源站+边缘节点的分发架构，这属于CDN级别的改造，建设成本较高，但这是规模化的必经之路。

• 源站：只接受推流，不直接对观众提供服务。
• 边缘节点：从源站拉流，缓存到本地，再分发给各自区域内的观众。

这个架构的好处是,把单台服务器的带宽压力分摊到多个节点，而边缘节点的建设涉及边缘计算和智能调度，如果你的预算和团队规模不支持，那么可以选择购买云直播服务，目前国内主流云厂商都有现成的RTMP推流接入和CDN分发产品，按量付费，适合中小团队。

常见Q&A：rtmp服务器很卡的后续疑问

rtmp服务器很卡，增加公网带宽就能解决吗？

增加带宽只能解决“带宽耗尽”这一种情况，如果卡顿是因为CPU锁定、连接数超限或推流端码率超出上行能力，加带宽不会有明显帮助，建议先用 top 和 nload 确认瓶颈在哪，再决定是否扩容。

为什么我用2Mbit码率推流，服务器网卡流量却占了10Mbit？

因为播放端也在消耗流量,假设有5个观众同时观看，每一路播放都要从服务器拉取2Mbit的流，加上播放重传的冗余，总流量就是推流码率的5倍以上，所以你的服务器带宽需要按“推流码率×并发观众数”来估算，参考依据是峰值观众数。

使用SRS替代Nginx-RTMP，这个操作可以明显提升并发吗？

SRS在底层处理上比Nginx-RTMP更贴近直播场景，尤其是对GOP缓存和连接管理的实现，多数情况下并发能力能提升2到3倍，但它也需要和业务代码配合，如果你已经在Nginx上做了深度定制，迁移成本会偏高；如果是从零搭建，SRS确实是个更合适的选择。