RTMP 与 1935 端口
1935 是 Adobe RTMP 协议的默认端口，也是直播链路最靠近源头的一段：推流软件把音视频推到流媒体服务器，服务器再转封装成 HLS、HTTP-FLV 或 WebRTC 分发给观众。RTMP 基于 TCP，延迟较低但明文传输，推流地址中的串流密钥会随之暴露。现代播放端已普遍改用基于 443 的协议，1935 只应保留给推流侧使用。
基本信息
| 服务 | RTMP（SRS、nginx-rtmp、Wowza 等流媒体服务器） |
|---|---|
| 协议 | TCP（RTMPS 为 TLS 版本，常用 443） |
| 用途 | 直播推流、低延迟拉流、录制转码入口 |
| 配套端口 | 观看侧通常走 443 的 HLS 或 HTTP-FLV |
| 权限要求 | 推流需串流密钥或平台签发的凭据 |
| 安全等级 | 仅对推流来源开放，勿全网开放 |
典型使用场景
- 直播推流：OBS 等软件把画面推到自建或云端流媒体服务器
- 监控与工业视频汇聚：设备或网关把码流推到中心平台统一分发
- 会议与连麦场景的上行入口，再由服务端做转码与合流
- 录制归档：推流同时落盘，作为直播回看与存证
- 多平台转推：一份推流由服务器转为多路分发到不同观看端
推流与探测
推流与探测
ffmpeg -re -i demo.mp4 -c copy -f flv rtmp://live.example.com/live/streamkey # 模拟推流
ffprobe -v error -show_streams rtmp://live.example.com/live/streamkey # 探测流是否可用
nc -vz live.example.com 1935 # 网络层连通性与鉴权结果
ss -lntp | grep 1935 # 服务器侧确认监听直播链路端口分工
| 环节 | 常用端口 | 说明 |
|---|---|---|
| 推流上行 | 1935 | RTMP，仅对推流来源开放 |
| 观看分发 | 443 | HLS、HTTP-FLV、WebRTC over HTTPS |
| 低延迟推流替代 | 按平台约定 | SRT 等协议常使用自定义端口 |
| 服务端管理界面 | 按产品定 | 管理入口严禁公网开放 |
推流侧安全要点（nginx-rtmp 片段）
推流侧安全要点（nginx-rtmp 片段）
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on; # 启用直播模式
record all; # 按需开启录制
record_path /data/rec;
allow publish 203.0.113.0/24; # 只允许已知推流来源
deny publish all; # 其余来源一律拒绝
}
}
}串流密钥泄露是最常见的直播事故：他人可以顶替你的推流通道，覆盖画面或盗用带宽；应使用一次性密钥、限制推流来源地址，并在推流路径上增加鉴权。
协议分工要分清：1935 负责上行推流，播放端不应再连 RTMP；把观众流量留在 443 上更利于穿透防火墙与 CDN 加速，也便于统一证书与访问日志。
排障顺序：先用探测工具确认流是否真的推上去了，再看服务器日志中的鉴权与断流原因，最后检查观看侧的转封装配置；推流正常但观众黑屏，问题通常在分发协议而不在 1935。