SRS 加 OBS 自建直播推流方案：从部署到优化实战指南

1. 为什么选择 SRS 加 OBS 这套组合

1.1 从一次直播卡顿说起

去年帮一个做在线教育的朋友处理直播卡顿的问题，他当时用的是某款付费直播云服务，每个月花不少钱，但高峰期延迟高得离谱，学生端经常要等十几秒才能看到画面。我过去看了一眼他的推流配置，发现他推的是 1080p60 帧、码率拉到 8000kbps，而他的上行带宽实测只有 10Mbps 左右，稍微有点波动就直接丢帧。后来我建议他自己搭一套 SRS 流媒体服务器，用 OBS 推流，把码率降到 3500kbps、分辨率改成 720p30 帧，延迟直接从十几秒降到了两秒以内，而且服务器成本一个月不到五十块。

这件事让我意识到，很多人对“推流”这件事的理解还停留在“装个软件点一下开始直播”的层面，但真正要跑得稳、延迟低、画质可控，背后涉及的东西其实不少。SRS 加 OBS 这套组合之所以被大量中小团队和个人开发者采用，核心原因就三个：开源免费、可控性强、社区活跃。SRS 是国内开发者主导的开源流媒体服务器项目，支持 RTMP、HLS、HTTP-FLV、WebRTC 等多种协议，OBS 则是目前最主流的开源推流客户端，两者配合几乎可以覆盖所有常见的直播场景。

1.2 SRS 到底解决了什么问题

简单来说，SRS 扮演的是“中转站”的角色。OBS 把本地的音视频画面编码后推给 SRS，SRS 再把这些数据分发给观看端。没有 SRS 的话，你就得依赖第三方平台，画面质量、延迟、并发数都受平台限制。自己搭 SRS 之后，你可以决定用什么协议分发、要不要开转码、要不要录制、并发上限是多少，这些在第三方平台上要么收费要么根本不给调。

SRS 的另一个优势是协议支持全面。RTMP 适合推流，延迟低但需要 Flash 时代遗留的播放器支持；HTTP-FLV 适合 Web 端播放，延迟同样很低；HLS 兼容性最好但延迟高，适合对实时性要求不高的场景；WebRTC 则是超低延迟场景的首选。你可以根据实际需求选择不同的分发协议，甚至同时开启多种协议。

1.3 OBS 在整条链路中的位置

OBS 负责的是“采集加编码加推流”这三件事。采集包括屏幕、摄像头、麦克风、窗口捕获等，编码就是把原始画面压缩成 H.264 或 H.265，音频压缩成 AAC，推流则是把编码后的数据通过 RTMP 协议发给 SRS。OBS 的强大之处在于它的插件生态和场景管理能力，你可以配置多个场景、多个来源，随时切换，还能通过插件实现抠像、美颜、字幕等功能。

很多人第一次用 OBS 的时候会被它的界面吓到，觉得选项太多不知道从哪下手。但实际上，对于“推流到自建 SRS 服务器”这个需求，你只需要关注几个核心参数：推流地址、码率、分辨率、帧率、编码器。把这几个搞定了，剩下的都是锦上添花。

1.4 适合哪些人参考这套方案

这套方案适合以下几类人：一是做在线教育、企业培训、游戏直播的个人或小团队，需要低成本、可控性强的直播方案；二是开发者想学习流媒体技术，需要一个能动手实践的实验环境；三是有内网直播需求的场景，比如公司年会、校园活动，不想把画面传到公网；四是对延迟有要求的互动场景，比如连麦、远程操控演示。

如果你只是偶尔开个直播，用第三方平台可能更省事。但如果你对画质、延迟、并发、数据归属有要求，或者想长期运营一个直播业务，自建 SRS 加 OBS 这套组合值得花时间研究。

2. 环境准备与 SRS 服务器部署

2.1 服务器选型与系统要求

SRS 对硬件的要求不算高，但也不是随便一台机器就能跑。官方推荐的最低配置是 1 核 CPU、1GB 内存，但这只是“能跑起来”的水平。实际使用中，如果并发观看人数超过 10 人，或者需要转码，建议至少 2 核 4GB 起步。带宽方面，推流端的上行带宽和观看端的下行带宽都要考虑。以 720p30 帧、2500kbps 码率为例，推流端至少需要 3Mbps 的稳定上行，每个观看端需要 2.5Mbps 的下行。如果 10 个人同时观看，服务器出口带宽至少要 25Mbps。

操作系统方面，SRS 官方支持 Linux、macOS 和 Windows（通过 WSL），但生产环境强烈建议用 Linux。Ubuntu 20.04 或 22.04 LTS 是最省心的选择，CentOS 7 也可以但要注意 glibc 版本。我个人的习惯是用 Ubuntu 22.04，因为它的软件源比较新，编译依赖装起来方便。

注意：如果你用的是云服务器，安全组规则一定要放行相关端口。RTMP 默认 1935，HTTP-FLV 和 HLS 默认 8080，WebRTC 默认 8000/UDP。很多人部署完发现推不上去，十有八九是安全组没开。

2.2 编译安装 SRS 的完整步骤

SRS 提供了多种安装方式，包括 Docker、源码编译、二进制包。Docker 最省事，但如果你想深入理解 SRS 的配置和运行机制，源码编译更合适。下面是我常用的源码编译流程。

先装依赖：

sudo apt update sudo apt install -y git gcc g++ make cmake pkg-config libssl-dev libsrtp2-dev libusrsctp-dev

然后拉源码。SRS 的 GitHub 仓库在国内访问可能不太稳定，可以用 Gitee 的镜像：

git clone https://gitee.com/ossrs/srs.git cd srs/trunk

编译配置。SRS 支持多种编译选项，如果你不需要 WebRTC 和 SRT，可以关掉以加快编译速度：

./configure --with-ssl --with-hls --with-http-flv --with-http-server --with-rtmp --without-srt --without-webrtc make -j$(nproc)

编译完成后，启动 SRS：

./objs/srs -c conf/srs.conf

如果看到类似“Server started, listen at port 1935”的日志，说明启动成功了。

2.3 配置文件的关键参数解读

SRS 的配置文件在conf/srs.conf，默认配置已经能跑起来，但有几个参数建议根据实际情况调整。

listen 1935是 RTMP 的监听端口，一般不用改。max_connections 1000是最大连接数，根据服务器性能调整。daemon on表示以守护进程方式运行，生产环境建议开启。srs_log_tank file表示日志输出到文件，方便排查问题。

HTTP 服务器部分，listen 8080是 HTTP-FLV 和 HLS 的端口，crossdomain on允许跨域访问，Web 播放器需要这个。http_remux部分开启后，RTMP 流会自动转成 HTTP-FLV，播放地址格式是http://你的IP:8080/live/流名称.flv。

HLS 部分，hls_fragment 10表示每个 TS 切片 10 秒，hls_window 60表示播放列表保留 60 秒。这两个参数直接影响 HLS 的延迟，切片越短延迟越低但服务器压力越大。一般建议hls_fragment设为 2 到 4 秒，hls_window设为 30 到 60 秒。

2.4 防火墙与端口放行

Ubuntu 默认用 ufw 管理防火墙，如果你开了 ufw，需要放行相关端口：

sudo ufw allow 1935/tcp sudo ufw allow 8080/tcp sudo ufw allow 8000/udp

如果你用的是云服务器，还要在控制台的安全组里放行同样的端口。这一步看起来简单，但我见过太多人卡在这里，推流地址填对了但就是连不上，最后发现是安全组没配。

2.5 验证 SRS 是否正常运行

启动 SRS 后，可以通过几个方式验证。一是看日志，tail -f objs/srs.log能看到实时日志。二是用netstat -tlnp | grep 1935检查端口是否监听。三是直接访问http://你的IP:8080，如果看到 SRS 的欢迎页面，说明 HTTP 服务器正常。

还有一个很实用的工具是 SRS 自带的 HTTP API，访问http://你的IP:1985/api/v1/streams/可以看到当前推流列表。这个 API 在排查“推流是否成功”时特别有用。

3. OBS 推流配置的完整流程

3.1 OBS 的下载与安装注意事项

OBS 的官网是 obsproject.com，下载时注意选择对应系统的版本。Windows 用户建议下载完整安装包而不是便携版，因为完整安装包会自动注册一些必要的组件。macOS 用户下载 dmg 后拖到 Applications 即可。Linux 用户可以通过 PPA 安装，但版本可能比官网旧。

关于版本选择，热词里提到的 obs studio 27.2.4 是一个比较稳定的老版本，但现在已经更新到 30.x 了。新版本在性能和功能上都有提升，建议用最新稳定版。如果你有特定的插件只兼容老版本，那就另说。

安装过程中有一个选项是“安装虚拟摄像头”，如果你需要把 OBS 画面作为摄像头输入到其他软件（比如腾讯会议、Zoom），这个要勾选。安装路径建议用默认的，避免中文路径导致插件加载失败。

3.2 推流地址的正确填写方式

OBS 的推流设置里有两个关键字段：服务器和串流密钥。对于自建 SRS，服务器填rtmp://你的服务器IP:1935/live，串流密钥填一个自定义的流名称，比如test或者mystream。最终推流地址就是rtmp://你的服务器IP:1935/live/test。

这里有个容易踩的坑：串流密钥不要带空格或特殊字符，否则 SRS 可能解析失败。另外，如果你在服务器和串流密钥里都填了完整地址，OBS 会拼接错误。正确的做法是服务器只填到应用名（live），密钥只填流名称。

如果你用的是 SRS 的默认配置，应用名就是live。如果你在 srs.conf 里改了vhost或app配置，那就要对应修改。

3.3 编码器与码率参数怎么选

编码器选择是 OBS 推流配置里最影响性能的部分。Windows 用户如果用的是 NVIDIA 显卡，选 NVENC 编码器，CPU 占用低、画质也不错。AMD 显卡选 AMF，Intel 核显选 QSV。如果没有独立显卡或者显卡不支持硬件编码，就用 x264 软件编码，但 CPU 占用会比较高。

码率的选择取决于分辨率和帧率。下面是一个参考表：

码率不是越高越好，超过上行带宽就会丢帧。我一般建议先用测速工具测一下实际上行带宽，然后取带宽的 70% 作为码率上限。比如上行 10Mbps，码率最多设 7000kbps。

3.4 音频参数与同步设置

音频方面，采样率选 44.1kHz 或 48kHz，比特率 128kbps 到 160kbps 足够。如果你的场景对音质要求高，比如音乐直播，可以设到 320kbps。声道一般选立体声，但如果是语音为主，单声道也能省带宽。

音视频同步是很多人忽略的问题。OBS 默认会自动同步，但如果你的采集设备有延迟（比如某些 USB 摄像头），可能会出现音画不同步。这时候可以在 OBS 的“高级音频属性”里手动调整音频偏移，单位是毫秒。正数表示音频延后，负数表示音频提前。一般摄像头延迟在 100 到 300 毫秒之间，需要实际测试调整。

3.5 场景与来源的配置技巧

OBS 的场景管理是它的核心优势之一。你可以创建多个场景，比如“全屏摄像头”“屏幕共享”“画中画”，然后通过快捷键或鼠标点击切换。每个场景里可以添加多个来源，来源的类型包括窗口捕获、显示器捕获、视频捕获设备、图像、文本、浏览器等。

一个实用技巧是给来源设置“滤镜”。比如给摄像头来源加一个“色度键”滤镜就能实现绿幕抠像，加“色彩校正”滤镜可以调整亮度对比度。热词里提到的 obs 抠像插件，其实 OBS 自带的色度键滤镜已经能满足大部分需求，不需要额外装插件。如果你用的是物理绿幕，把“相似度”调到 400 左右、“平滑度”调到 80 左右，效果通常不错。

3.6 开始推流与状态确认

配置完成后，点击 OBS 右下角的“开始推流”。如果一切正常，底部状态栏会显示绿色的推流指示灯，以及实时码率、丢帧率、CPU 占用等信息。丢帧率如果持续超过 1%，说明网络或编码有问题，需要排查。

同时，在服务器端用tail -f objs/srs.log看日志，如果看到“publish”相关的日志，说明推流成功。也可以访问 SRS 的 HTTP API 确认流是否在列表中。

4. 常见问题排查与实战经验

4.1 推流失败：连接被拒绝或超时

这是最常见的问题，表现是 OBS 提示“无法连接服务器”或一直重连。排查思路按以下顺序来：

先确认 SRS 是否在运行，ps aux | grep srs看进程在不在。如果不在，检查启动命令和日志。再确认端口是否监听，netstat -tlnp | grep 1935。如果端口没监听，说明 SRS 没启动成功或者配置有误。然后检查防火墙和安全组，这是最容易忽略的一步。最后确认推流地址格式是否正确，特别是 IP 和端口有没有写错。

实操心得：我习惯在服务器上用telnet 127.0.0.1 1935先测本地端口通不通，再用另一台机器测远程端口。这样能快速定位是 SRS 的问题还是网络的问题。

4.2 推流成功但播放不了

OBS 显示推流正常，但播放器打不开画面。这种情况通常是播放地址或协议的问题。如果你用的是 HTTP-FLV，确认 SRS 配置里http_remux的enabled是on。播放地址格式是http://IP:8080/live/流名称.flv，注意端口是 8080 不是 1935。

如果是 HLS，播放地址是http://IP:8080/live/流名称.m3u8。HLS 有个特点是需要等第一个切片生成后才能播放，通常要等 10 秒左右。如果你刚推流就打开播放器，可能看到 404，等一会儿再试。

还有一个常见原因是跨域。Web 播放器通过 HTTP 请求 FLV 或 HLS 时，如果 SRS 没开跨域，浏览器会拦截。确认http_server配置里crossdomain on已开启。

4.3 画面卡顿、丢帧严重

丢帧的原因通常有三个：上行带宽不足、编码器性能不够、服务器处理能力不足。先看 OBS 状态栏的丢帧率，如果是网络丢帧，降低码率或分辨率试试。如果是编码丢帧，换硬件编码器或降低帧率。如果 OBS 端正常但观看端卡，可能是服务器带宽不够或并发太高。

还有一个隐蔽的原因是关键帧间隔设置。OBS 默认关键帧间隔是 0（自动），但有些场景下自动设置会导致关键帧间隔过长，播放器需要等很久才能出画面。建议手动设为 2 秒，这样首屏时间会短很多。

4.4 延迟高的排查与优化

延迟高是直播场景最头疼的问题之一。不同协议的延迟差异很大：RTMP 和 HTTP-FLV 通常在 1 到 3 秒，HLS 在 10 到 30 秒，WebRTC 可以做到 500 毫秒以内。如果你对延迟敏感，优先用 HTTP-FLV 或 WebRTC。

在 SRS 配置层面，可以调整gop_cache参数。gop_cache on会缓存一个 GOP 的数据，新观众进来能立刻看到画面，但会增加延迟。如果追求低延迟，可以关掉gop_cache，但首屏时间会变长。这是一个权衡。

OBS 端也可以优化。把“关键帧间隔”设为 1 到 2 秒，编码预设设为“低延迟”或“超低延迟”，都能降低延迟。但低延迟预设会牺牲一些画质，需要根据场景取舍。

4.5 常见问题速查表

4.6 几个容易被忽略的细节

第一个是时间同步。服务器和推流端的时间如果差太多，HLS 的切片时间戳会乱，导致播放器无法播放。建议服务器开启 NTP 同步。

第二个是磁盘空间。SRS 如果开了录制或 HLS，会不断写磁盘。我见过一个案例，服务器磁盘写满导致 SRS 崩溃，直播中断。建议设置日志轮转和磁盘监控。

第三个是 SRS 的日志级别。默认是 trace 级别，日志量很大，长期运行会占满磁盘。生产环境建议改成 info 或 warn 级别，在srs.conf里改srs_log_level。

第四个是 OBS 的“自动重连”功能。网络波动时 OBS 会自动重连，但重连后流名称如果变了，播放端会断。建议在 SRS 配置里开启publish的mr或gop_cache，让重连后的流能快速恢复。

4.7 性能调优的几个方向

如果并发观看人数多，SRS 的性能调优就很重要。首先是worker进程数，SRS 默认是单进程，可以通过配置开启多进程。其次是max_connections，根据服务器内存调整，每个连接大约占几十 KB 内存。再次是chunk_size，默认 4096 字节，调大可以减少系统调用次数但会增加内存占用。

如果服务器带宽有限，可以开启 SRS 的转码功能，把高码率流转成低码率，但转码很吃 CPU。另一种方案是用 SRS 的边缘集群，一台源站服务器接收推流，多台边缘服务器分发，这样能大幅提升并发能力。

4.8 从实际项目中总结的经验

我做过一个校园活动的直播项目，推流端用 OBS，服务器用 2 核 4GB 的云主机，观看端大概 200 人。一开始用的是 HLS，延迟 20 多秒，观众反馈互动体验很差。后来改成 HTTP-FLV，延迟降到 2 秒左右，但服务器带宽跑满了。最后的方案是 HTTP-FLV 加 HLS 双协议，对延迟敏感的用 FLV，对兼容性要求高的用 HLS，同时在 SRS 里开了 gop_cache，首屏时间控制在 1 秒以内。

另一个经验是关于 OBS 的编码器选择。有一次在一台没有独立显卡的笔记本上推流，用 x264 编码 1080p，CPU 直接跑满，画面卡成幻灯片。后来降到 720p 并用“veryfast”预设，才勉强流畅。所以如果你的设备性能一般，不要盲目追求高分辨率，流畅比清晰更重要。

还有一个坑是 OBS 的插件路径。热词里有人问“obs plugin插件放到那个文件夹内”，Windows 下是C:\Program Files\obs-studio\obs-plugins\64bit，macOS 下是/Applications/OBS.app/Contents/PlugIns。但注意，OBS 28 之后插件安装方式变了，很多老插件需要重新编译才能用。装插件前先确认版本兼容性，不然 OBS 可能直接启动不了。

最后说一个关于 SRS 配置的小技巧。如果你想让推流更安全，可以在 SRS 配置里开启publish的鉴权，比如用on_publish回调验证推流密钥。这样即使别人知道了你的推流地址，没有密钥也推不上去。具体做法是在vhost里配置http_hooks，指向你自己的鉴权服务。这个功能在企业内训场景里很实用，能防止未授权的推流。