ZLMediaKit推流中断如何排查与解决？

Question

**问题描述：** 在使用 ZLMediaKit 进行推流过程中，偶尔会出现推流中断的情况，表现为客户端断开连接、服务端无推流信息或日志提示异常断开。这种中断可能是由于网络不稳定、推流端异常退出、鉴权失败、RTMP握手失败或服务器资源配置不当等原因引起。如何通过日志分析、网络抓包和配置调整来快速定位并解决推流中断问题，是保障直播系统稳定性的关键。

Answer 1

一、问题现象概述

ZLMediaKit 是一个开源的流媒体服务器，支持 RTMP、HLS、RTP 等多种协议。在实际部署中，推流端（如 OBS、FFmpeg 或移动端 SDK）向 ZLMediaKit 推送视频流时，偶尔会出现推流中断的现象。

常见的表现包括：

• 客户端主动断开连接
• 服务端未收到任何推流信息
• 日志中提示异常断开或鉴权失败
• RTMP握手过程中失败

二、可能原因分析

推流中断的原因多样，需从多个维度进行排查：

原因分类	具体描述	影响范围
网络不稳定	推流端与服务器之间的网络延迟高或丢包严重	广泛存在，尤其在公网环境下
推流端异常退出	推流软件崩溃、设备重启或手动停止	常见于移动设备或非专业推流工具
鉴权失败	URL 中携带的 token 验证失败，或未通过 HTTP 回调验证	安全机制开启后频繁出现
RTMP 握手失败	推流端与服务器版本不一致导致握手失败	特定客户端下偶发
服务器资源配置不当	线程池不足、内存溢出、FD 资源耗尽等	高并发场景下易发生

三、日志分析方法

ZLMediaKit 提供了详细的日志输出功能，是定位问题的第一手资料。

1. 启用调试日志： 修改配置文件 config.ini，将日志级别调整为 DEBUG。
2. 查看关键日志关键词：
   • "onError"：表示推流过程中的错误事件
   • "onClose"：推流通道关闭事件
   • "auth failed"：鉴权失败提示
   • "handshake failed"：握手失败
3. 结合时间戳定位异常节点： 日志中的时间戳可帮助定位是哪个环节出现问题。

四、网络抓包分析流程

当无法通过日志明确问题时，建议使用 tcpdump 进行网络抓包分析。

# 在服务器上执行
tcpdump -i eth0 port 1935 -w rtmp.pcap
    

使用 Wireshark 打开抓包文件，重点关注以下内容：

• RTMP connect 和 publish 消息是否完整
• 是否有 TCP RST 包，表示一方强制断开
• 是否存在大量重传或超时

五、ZLMediaKit 配置优化建议

合理的配置可以有效避免因资源不足引发的推流中断问题。

[General]
maxSession=1000
maxThreads=4
logLevel=DEBUG

[Media]
bufferSize=1024*1024
timeoutMS=60000
    

其中关键参数说明如下：

• maxSession：最大会话数，应根据业务并发量合理设置
• maxThreads：处理线程数，建议与 CPU 核心数匹配
• timeoutMS：超时时间，适当延长可容忍短时网络波动

六、故障定位流程图

graph TD
A[开始] --> B{推流是否成功?}
B -- 否 --> C[检查客户端日志]
C --> D[确认推流地址和鉴权参数]
D --> E{鉴权是否通过?}
E -- 否 --> F[检查回调接口或token校验逻辑]
E -- 是 --> G[抓包分析握手过程]
G --> H{握手是否成功?}
H -- 否 --> I[兼容性问题或协议版本差异]
H -- 是 --> J[观察后续数据传输]
J --> K{有无中断?}
K -- 是 --> L[检查服务器负载/资源/日志]
K -- 否 --> M[结束]
B -- 是 --> N[观察是否中途断开]
N --> O[检查网络稳定性]
O --> P{是否稳定?}
P -- 否 --> Q[优化网络环境]
P -- 是 --> R[检查服务器性能瓶颈]
R --> S{是否过载?}
S -- 是 --> T[升级硬件或优化配置]
S -- 否 --> U[结束]