1. 为什么选择 SRS + OBS 这套组合
1.1 从一次直播卡顿说起
去年帮一个做在线教育的朋友处理直播卡顿的问题，他当时用的是某云厂商的直播服务，按流量计费，一个月下来账单吓人，而且延迟忽高忽低，学生端经常反馈“老师声音和画面对不上”。我问他有没有考虑过自建流媒体服务器，他第一反应是“那玩意儿是不是很复杂”。实际上，SRS（Simple Realtime Server）加上 OBS Studio 这套组合，从零到跑通推流，熟练的话真的只要五分钟。
这篇文章就是把我这些年反复搭建、调试、踩坑的经验整理出来。SRS 是一个开源的流媒体服务器，支持 RTMP、HLS、HTTP-FLV、WebRTC 等协议，OBS Studio 则是目前最主流的开源推流客户端。两者搭配，你可以用极低的成本搭建一套属于自己的直播推流系统，适用于在线教育、游戏直播、企业内训、活动直播回放等场景。不管你是刚接触流媒体的新手，还是已经用过其他方案想换一套更可控的，这篇内容都能直接抄作业。
1.2 SRS 到底解决了什么问题
很多人第一次听到“流媒体服务器”会觉得离自己很远，其实你可以把它理解成一个“中转站”。OBS 负责把摄像头画面和麦克风声音打包，推送到 SRS 服务器；SRS 再把这份数据分发给所有观看端。没有这个中转站，每个观众都要直接连到你的电脑上，显然不现实。
SRS 的核心优势在于：第一，它是国产开源项目，文档中文友好，社区活跃；第二，资源占用低，一台 2 核 4G 的云主机就能扛住几百路并发；第三，协议支持全，RTMP 推流、HTTP-FLV 和 HLS 拉流、WebRTC 低延迟通话都能搞定。相比动辄按流量计费的商业方案，自建 SRS 的成本几乎只有服务器本身的费用。
1.3 OBS 在推流链路中的角色
OBS Studio 负责的是“采集 + 编码 + 推送”这三件事。采集包括屏幕、摄像头、麦克风、窗口捕获等；编码就是把原始画面压缩成 H.264，音频压缩成 AAC；推送就是通过 RTMP 协议把编码后的数据发给 SRS。OBS 的插件生态也很丰富，比如抠像插件、语音朗读插件、比赛回放插件等，都可以按需加载。
需要特别说明的是，OBS 的版本更新比较频繁，目前常见的有 27.x、28.x、29.x 等。不同版本在界面布局和插件兼容性上会有差异，后面我会专门讲插件目录的问题。另外，网上有人搜“obs 汉化版”，其实 OBS 官方安装包自带简体中文，在设置里切换语言即可，不需要额外下载所谓的汉化版，那些第三方打包的版本反而可能夹带私货。
2. 五分钟搭建 SRS 服务器的完整流程
2.1 服务器环境准备与选型建议
先说服务器。你可以在本地电脑上跑 SRS 做测试，也可以买一台云主机。本地测试的话，Windows 和 macOS 都能用 Docker 跑，Linux 直接编译或下载二进制包。云主机的话，建议选 2 核 4G 起步，带宽根据你的并发观看人数来定。假设每路流码率是 2 Mbps，10 个人同时观看就需要 20 Mbps 的出带宽，这个账要提前算清楚。
操作系统推荐 Ubuntu 20.04 或 22.04，CentOS 7 也可以但已经停止维护了。我实测下来 Ubuntu 的兼容性最好，遇到问题搜资料也方便。如果你用的是华为云、阿里云这类平台，注意安全组要放行相关端口，否则推流会一直连不上。
注意：云主机的公网 IP 和私网 IP 要分清。OBS 里填的推流地址必须是公网 IP 或者绑定的域名，填成私网 IP 只有同内网的机器能访问。
2.2 三种部署方式对比与选择
SRS 的部署方式主要有三种：Docker 部署、二进制包部署、源码编译部署。我整理了一个对比表，你可以根据自己的情况选。
| 部署方式 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|
| Docker | 一条命令搞定，环境隔离 | 需要先装 Docker | 新手、快速验证 |
| 二进制包 | 解压即用，不依赖 Docker | 版本更新需手动替换 | 有一定 Linux 基础 |
| 源码编译 | 可定制功能，最新特性 | 编译耗时长，依赖多 | 开发者、深度定制 |
如果你只是想快速跑通，直接用 Docker。命令如下：
docker run -d --name srs \ -p 1935:1935 -p 1985:1985 -p 8080:8080 \ ossrs/srs:5 \ ./objs/srs -c conf/docker.conf这条命令启动了 SRS 5.0 版本，映射了三个端口：1935 是 RTMP 推流端口，1985 是 HTTP API 端口，8080 是 HTTP-FLV 和 HLS 的播放端口。跑起来之后，用docker logs srs看一下日志，出现 “Server started” 就说明成功了。
2.3 配置文件的关键参数解读
如果你用二进制包或者源码编译，核心配置文件是conf/srs.conf。我挑几个最关键的参数讲一下，这些参数直接决定了你的推流能不能成功、延迟有多高。
listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_server { enabled on; listen 8080; dir ./objs/nginx/html; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 10; hls_window 60; } }max_connections控制最大连接数，根据你的服务器性能调整。http_remux开启后，可以用 HTTP-FLV 协议拉流，延迟比 HLS 低很多，大概 1 到 3 秒。hls_fragment是 HLS 切片时长，设成 10 秒意味着每 10 秒生成一个 ts 文件，延迟会比较高，但兼容性好，适合对延迟不敏感的场景。hls_window是播放列表长度，60 表示保留最近 60 秒的切片。
提示：如果你追求低延迟，优先用 HTTP-FLV 或者 WebRTC，HLS 的延迟天然就高，这是协议本身决定的，不是配置能解决的。
3. OBS 推流配置的详细步骤
3.1 推流地址与串流密钥的填写规则
OBS 里配置推流的位置在“设置” -> “推流”。服务类型选“自定义”，服务器填你的 SRS 地址，格式是rtmp://你的服务器IP:1935/live，串流密钥填一个你自定义的流名称，比如teststream。注意，这里的live是应用名，可以改，但要和 SRS 配置里的 vhost 对应上。
很多人第一次填的时候会把服务器写成rtmp://IP:1935/live/teststream，然后把串流密钥空着，这样也能推，但规范做法是服务器只写到应用名，流名称放在串流密钥里。两种写法 SRS 都认，但分开写更清晰，后面做多路流管理的时候不容易乱。
推流成功后，你可以用以下地址测试播放：
- HTTP-FLV:
http://你的服务器IP:8080/live/teststream.flv - HLS:
http://你的服务器IP:8080/live/teststream.m3u8
用 VLC 或者 ffplay 打开这个地址，能看到画面就说明整条链路通了。
3.2 编码参数怎么调才不卡
OBS 的编码设置直接影响到推流质量和服务器压力。在“设置” -> “输出”里，输出模式选“高级”，然后重点调这几个参数：
- 编码器：优先选硬件编码，比如 NVIDIA NVENC 或者 Intel QSV，比软件编码 x264 省 CPU。如果没有独立显卡，就用 x264，预设选
veryfast或faster。 - 码率：720p 建议 2500 到 4000 Kbps，1080p 建议 4500 到 6000 Kbps。码率太高，上行带宽扛不住会丢帧；太低画面会糊。
- 关键帧间隔：设成 2 秒。这个参数影响拉流端首屏速度和 seek 体验，太大太小都不好。
- 预设：x264 用
veryfast，NVENC 用quality或balanced。
我踩过的一个坑是：码率设了 8000 Kbps，结果家里上行只有 10 Mbps，推流一直重连。后来降到 3500 Kbps，稳定得很。所以推流前一定要测一下自己的上行带宽，留出至少 30% 的余量。
3.3 音频设置与常见误区
音频这块，采样率设 44.1kHz 或 48kHz，声道选立体声或单声道。如果你的内容只是人声讲解，单声道就够了，还能省一半音频码率。音频码率设 128 Kbps 或 160 Kbps 都行，再高意义不大。
常见误区是有人把音频码率拉到 320 Kbps，觉得音质会更好，实际上经过 RTMP 传输和服务器转发，观众端听到的差异微乎其微，反而增加了带宽负担。另外，如果麦克风有底噪，可以在 OBS 里加一个“噪声抑制”滤镜，比后期处理省事得多。
4. 常见问题排查与实战避坑指南
4.1 推流连不上服务器的排查思路
推流连不上是最常见的问题，排查顺序应该是：网络 -> 端口 -> 配置 -> 防火墙。先确认服务器 IP 能不能 ping 通，然后 telnet 一下 1935 端口通不通。如果端口不通，检查云主机安全组和服务器本机防火墙。Ubuntu 上用ufw status看防火墙规则，CentOS 用firewall-cmd --list-ports。
如果端口通了但 OBS 还是报错，看 SRS 的日志。日志里会明确告诉你连接是否建立、握手是否成功。常见错误有“RTMP handshake failed”，一般是推流地址写错了；“no app found”，是应用名对不上。我遇到过最隐蔽的一个问题是服务器时间不对，导致 RTMP 握手校验失败，用date命令同步一下时间就好了。
4.2 播放端黑屏、卡顿、延迟高的原因
播放端黑屏但 OBS 显示推流正常，大概率是拉流地址写错了，或者播放器不支持对应的协议。HTTP-FLV 地址必须以.flv结尾，HLS 必须以.m3u8结尾。用浏览器直接打开 FLV 地址是播不了的，需要支持 FLV 的播放器，比如 VLC 或者专门的 Web 播放器。
卡顿的话，先看服务器带宽是否跑满，用iftop或者nload监控一下。如果带宽没问题，再看 OBS 的丢帧情况，OBS 底部状态栏会显示“丢帧”百分比，超过 1% 就说明上行有问题。延迟高的话，HLS 天然延迟在 10 到 30 秒，换成 HTTP-FLV 能降到 1 到 3 秒，WebRTC 可以做到 500 毫秒以内，但配置更复杂。
4.3 OBS 插件目录与版本兼容问题
关于“obs plugin插件放到那个文件夹内”这个问题，不同系统路径不一样：
- Windows:
C:\Program Files\obs-studio\obs-plugins\64bit - macOS:
/Applications/OBS.app/Contents/PlugIns - Linux:
/usr/lib/obs-plugins或~/.config/obs-studio/plugins
需要注意的是，OBS 27.x 和 28.x 之后的插件接口有变化，有些老插件在新版本上会加载失败。如果你装了插件但 OBS 里看不到，先确认插件版本是否匹配你的 OBS 版本。另外，OBS 29 之后对插件签名有要求，未签名的插件可能被拦截，需要在设置里手动允许。
注意：不要随便下载来路不明的插件包，尤其是所谓的“汉化版”整合包，里面可能捆绑了不需要的软件。官方插件一般发布在 GitHub 上，下载前看一下 issue 区有没有兼容性反馈。
4.4 高频问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| OBS 推流失败，提示连接超时 | 端口未放行 | 检查安全组和本机防火墙 |
| 推流成功但播放黑屏 | 拉流地址错误 | 确认协议和路径后缀 |
| 播放卡顿、花屏 | 码率超过上行带宽 | 降低码率或分辨率 |
| 延迟十几秒 | 使用 HLS 拉流 | 换 HTTP-FLV 或 WebRTC |
| 插件加载不出来 | 版本不兼容 | 核对 OBS 版本和插件版本 |
| 服务器 CPU 跑满 | 软件编码 + 高并发 | 启用硬件编码或升级配置 |
5. 进阶玩法与场景扩展
5.1 多路推流与回放录制
SRS 支持同一个流被多个客户端拉取，也支持把推流内容录制下来。在 vhost 配置里加上 DVR 相关配置，就能自动把每路流存成 FLV 或 MP4 文件。这个功能对于“比赛回放”这类场景特别实用，直播结束后直接提供点播地址就行。
dvr { enabled on; dvr_path ./objs/nginx/html/[app]/[stream].[timestamp].flv; dvr_plan session; }dvr_plan选session表示按推流会话录制，一次推流生成一个文件。如果选segment，会按时间切片。录制文件默认是 FLV 格式，想转 MP4 可以用 ffmpeg 批量处理。
5.2 结合第三方工具的扩展思路
OBS 的插件生态可以玩出很多花样。比如抠像插件可以做虚拟背景，适合在线教学；语音朗读插件可以把弹幕读出来，适合互动直播；还有各种转场、滤镜插件，能提升画面质感。SRS 这边，可以通过 HTTP API 获取流列表、踢掉某个流、查询在线人数，方便做后台管理。
如果你想把直播嵌入自己的网站，可以用 SRS 提供的 HTTP-FLV 地址配合 flv.js 播放器，几行代码就能搞定。HLS 的话直接用 video.js 或者原生 video 标签就行，兼容性更好但延迟高。
5.3 安全加固与访问控制
默认配置下，任何人知道你的推流地址就能推流，这显然不安全。SRS 支持推流鉴权，可以在 URL 里加 token，服务器校验通过才允许推流。配置方式是在 vhost 里加http_hooks，推流时回调你的鉴权接口。
另外，播放端也可以做防盗链，通过 Referer 白名单或者 URL 签名来限制。如果只是内部使用，最简单的办法是把 RTMP 端口只对特定 IP 开放，其他 IP 一律拒绝。这些安全措施虽然会增加一点配置成本，但能避免流被恶意盗用。
6. 我踩过的那些坑与实操心得
6.1 关于服务器时间同步的教训
前面提过服务器时间不对导致 RTMP 握手失败，这个坑我踩了两次。第一次排查了半天，以为是端口或者配置问题，最后无意中date看了一下，发现时间差了十几分钟。RTMP 握手时会校验时间戳，偏差太大会直接拒绝连接。所以新服务器上手第一件事，就是ntpdate或者chrony同步时间，这个习惯能省很多事。
6.2 码率与带宽的匹配经验
很多人推流卡顿第一反应是服务器不行，其实大部分情况是上行带宽不够。我一般建议按“上行带宽 × 0.7”来设码率。比如上行 10 Mbps，码率最多设 7000 Kbps，留出余量给网络波动。另外，OBS 的“动态码率”功能在 28 版本之后有改进，网络差的时候会自动降码率，但画质也会降，看你能不能接受。
6.3 插件管理的个人建议
插件这东西，够用就行，不要贪多。每装一个插件都会增加 OBS 启动时间和崩溃风险。我自己的习惯是，只装当前项目必须的插件，项目结束就卸载。另外，插件更新前先备份 OBS 的配置目录，万一新版本有问题可以快速回滚。Windows 下配置目录在%APPDATA%\obs-studio，macOS 在~/Library/Application Support/obs-studio。
6.4 日志是最好的老师
不管是 SRS 还是 OBS，出问题先看日志。SRS 的日志在./objs/logs/目录下，OBS 的日志在“帮助” -> “日志文件”里可以打开。日志里会记录每一步的状态和错误码，比瞎猜高效得多。我现在的习惯是，每次搭建新环境，先把日志级别调到 debug，跑通之后再调回 info，这样排查问题的时候信息最全。
最后再分享一个小技巧：如果你经常需要给别人演示推流配置，可以把 SRS 和 OBS 的配置做成模板，换服务器的时候只需要改 IP 和流名称，其他参数直接复用。这样五分钟搭建真不是吹的，熟练之后三分钟就能跑起来。
