做实时音视频这几年如果只让我选一个开源流媒体服务器我会毫不犹豫推荐 SRS。Docker 部署 SRS 如今已经是搭建实时音视频流媒体平台最主流的玩法之一容器化之后部署成本低到离谱项目本身又足够活跃遇到问题基本都能在社区找到答案。这篇博文把我从零开始用 Docker 跑起 SRS 的全过程记录下来包括为什么选 SRS 而不是 Nginx-RTMP、端口到底怎么开、配置文件怎么挂载、推流拉流怎么验证以及我在实战中踩过的坑。不管你是刚接触流媒体的小白还是已经在用其他方案想换过来的老手这篇文章都能直接拿来抄作业。1. 做实时音视频为什么选择 SRS1.1 先搞清楚 SRS 到底是什么SRS 全称 Simple Realtime Server是一个开源的实时流媒体服务器项目。它的核心能力就一句话把音视频流收进来、转一下、再发出去。听起来简单但做到极致并不容易尤其是同时支持 RTMP、HLS、WebRTC、SRT、GB28181 这么多种协议还能保持低延迟和高并发这在开源圈里非常少见。SRS 最初是从 RTMP 直播场景起家的后来不断扩展现在已经是国内开源流媒体服务器里生态最完整的项目之一。它的代码托管在 GitHub 上star 数量相当可观社区活跃度也高winlin 等核心开发者常年在线回答 issue。我用了这么久的一个体会是SRS 的文档虽然有些地方写得比较跳跃但只要你愿意读几乎每个配置项都有对应的场景说明这在开源项目里算非常良心了。那为什么偏偏要强调用 Docker 来部署 SRS因为 SRS 本身是 C 写的源码编译安装需要处理一堆依赖比如 OpenSSL、FFmpeg、libsrtp 等等稍有版本不匹配就编不过去。Docker 镜像把这些全打包好了拉下来就能跑省掉的不仅是编译时间更是排查依赖问题的时间。1.2 对比 Nginx-RTMP、ZLMediaKitSRS 赢在哪很多人第一次接触流媒体服务器可能都是从 Nginx-RTMP 模块开始的。我早年也用过一段时间它的配置确实简单一个 rtmp 块就搞定推流。但用久了就会发现几个痛点Nginx 官方已经不维护 RTMP 模块了项目基本处于半停滞状态WebRTC 支持等于没有想做低延迟浏览器播放就得另起炉灶HLS 切片虽然能做但配置灵活性一般。ZLMediaKit 是另一个很优秀的项目性能和协议支持都很强但它的上手门槛比 SRS 高一些配置方式和周边工具链没有 SRS 那么完善。如果只是常规的直播、录播、低延迟播放场景SRS 的开箱即用体验是最好的。SRS 的差异化优势有这么几点第一WebRTC 支持做得非常顺滑配合 WHIP/WHEP 协议浏览器推流拉流的延迟可以压到 500 毫秒左右第二API 接口完善通过 HTTP 接口就能查询服务器状态、踢流、获取流列表方便二次开发第三Docker 镜像官方维护升级和回滚都非常方便。所以我的结论是如果你需要一个通用型实时音视频流媒体平台SRS 是当前开源方案里的最优解之一。2. Docker 部署 SRS 前的准备2.1 环境要求与版本选择在跑 SRS 之前先确认你的 Docker 环境是好的。我在排查过不少“容器起不来”的问题后发现很多其实不是 SRS 的锅而是 Docker 本身的权限、虚拟化、网络问题。首先确认 Docker 版本。建议用 Docker Engine 20.10 以上老版本对容器网络和资源限制的支持不够好。执行docker version看 Client 和 Server 的版本两个都有输出说明 Docker 守护进程跑起来了。如果你在 Linux 上用docker ps遇到 permission denied那是当前用户没加入 docker 用户组执行sudo usermod -aG docker $USER然后重新登录就行。其次是镜像版本选择。SRS 官方镜像的命名规则是ossrs/srstag 有6、5、4等主要版本。我强烈建议直接用ossrs/srs:6因为 SRS 6.0 在 WebRTC、SRT、GB28181、DVR 录播等方向都做了大量改进尤其是 WebRTC 相关能力5.0 和 6.0 的差距不是一点半点。还要注意一下你的硬件架构。SRS 官方镜像支持 amd64 和 arm64树莓派或者各类 ARM 开发板也能跑只是部分高级功能比如某些硬件编码加速在 ARM 上支持不太好。如果只是软件转码或者直接转发流ARM 完全没问题。2.2 端口规划这一节不看肯定踩坑SRS 的端口规划是整个部署过程中最容易被忽略、也最容易出问题的地方。很多人容器起来了结果推流失败最后发现是端口没放通。SRS 默认涉及这几个端口端口协议用途1935TCPRTMP 推流和拉流1985TCPHTTP API 接口用于查询状态和管理8080TCPHTTP 服务提供 HLS、DASH 播放和简单演示页面8000UDPWebRTC 推流SRTP8001UDPWebRTC 拉流SRTP在 Docker 部署的时候这些端口都要映射到宿主机。尤其要注意 8000 和 8001 是 UDP 端口写-p参数时必须显式带上udp关键字否则默认只映射 TCPWebRTC 肯定不通。如果你在云服务器上部署除了 Docker 的端口映射还要去云控制台的安全组里把对应端口放开。我曾经排查过一个用户的 WebRTC 问题Docker 映射没问题、防火墙也放行了结果最后发现是安全组只开了 TCPUDP 全被挡了。这种问题非常隐蔽报错还容易误导人所以建议动手部署之前先把端口规划写在纸上。2.3 配置文件和数据目录要提前想好SRS 的默认配置可以直接用但生产环境一般都要改。官方镜像里默认配置文件路径是/usr/local/srs/conf/srs.conf日志和数据输出目录是/usr/local/srs/objs/。我建议在宿主机上先创建好配置挂载目录后面修改配置就不用重新构建镜像了。例如mkdir -p /data/srs/conf mkdir -p /data/srs/objs然后把你自己的srs.conf放到/data/srs/conf/下启动容器的时候用-v参数挂载进去。这里有个小细节需要注意宿主机目录的权限。如果挂载后 SRS 容器内无法写入日志或者 DVR 文件通常是目录的用户 ID 和容器内进程的用户 ID 不匹配。SRS 官方镜像默认以 root 运行dev 模式所以一般权限问题不多但如果你用了自定义启动参数或者非 root 容器就要留意一下。数据目录则要看你的业务场景。如果开启了 HLS切片文件默认写在/usr/local/srs/objs/nginx/html下如果开启了 DVR 录播录制文件写在/usr/local/srs/objs/下。这些目录都要挂载出来不然容器一删所有录制内容全没了。3. 一步步启动 SRS 容器3.1 先来一条最简单的 docker run 命令很多教程一上来就让你写 docker-compose但对于第一次部署的人来说用一条docker run命令把服务跑起来能最快建立直观感受。最简单的启动命令长这样docker run -d --name srs \ -p 1935:1935 \ -p 1985:1985 \ -p 8080:8080 \ -p 8000:8000/udp \ -p 8001:8001/udp \ ossrs/srs:6-d表示后台运行--name srs给容器起个名字后面管理起来方便。端口映射有一条算一条缺哪个后续哪个功能就不好使。跑完执行docker logs srs看一下输出如果能看到类似SRS is running或者版本信息说明容器已经正常启动了。这个时候你可以先做个快速验证在浏览器里访问http://你的服务器IP:8080如果能看到 SRS 的默认演示页面说明 HTTP 服务已经通了。页面虽然简陋但意义重大——它说明 SRS 进程活着端口映射对了网络链路是通的。3.2 Docker Compose项目化部署的正确姿势生产环境我从来不靠裸docker run维护服务写一份docker-compose.yml无论是参数管理还是服务编排都清晰得多。而且 SRS 往往不是孤立部署的你可能还要同时起 Nginx、Redis、MySQL用 Compose 统一管理才是正确姿势。下面是我在项目里用的一份基础配置version: 3.8 services: srs: image: ossrs/srs:6 container_name: srs restart: always ports: - 1935:1935 - 1985:1985 - 8080:8080 - 8000:8000/udp - 8001:8001/udp volumes: - /data/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf - /data/srs/objs:/usr/local/srs/objs environment: - TZAsia/Shanghairestart: always非常关键它保证 Docker 守护进程重启或者宿主机重启后SRS 容器能自动拉起来。TZAsia/Shanghai设置时区避免日志时间和本地时间对不上。配置写好后执行docker compose up -d如果docker compose命令不存在说明你的 Docker 版本比较老需要先升级 Docker 或者用docker-compose带连字符这个旧版本命令。3.3 用自定义 srs.conf 替换默认配置官方默认配置适合跑通流程但如果你要做 HLS 切片、开启 WebRTC、改端口、加鉴权就得自己写配置文件。我先把一份带 HLS 和 WebRTC 的最小配置贴出来listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; dir ./objs/nginx/html; } rtc_server { enabled on; listen 8000; # WebRTC over TCP, not necessary for UDP } vhost __defaultVhost__ { rtc { enabled on; } hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 5; hls_window 30; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } }这份配置我实际用过跑直播和回放都够用。几个参数重点说一下hls_fragment 5表示切片文件每个 5 秒hls_window 30表示时间窗口 30 秒也就是最多保留最近 6 个切片。如果你要做低延迟直播不想用 HLS那就把hls这个段落注释掉直接用http_remux输出 FLV 流播放器用 flv.js 就行。写好配置后挂载进容器并重启docker compose restart srs如果配置语法有问题SRS 会直接把错误打在日志里。我踩过一次坑是配置文件里少了daemon off;导致容器启动后 SRS 进程立刻进入后台运行但 Docker 的前台进程找不到存活进程容器就反复重启。这个参数务必保留。4. 验证流媒体服务推流拉流完整流程4.1 用 FFmpeg 推流测试服务起来了配置也挂载了接下来最关键的一步是验证链路通不通。最直接的方式就是用 FFmpeg 推一路流到 SRS。首先确认本机装了 FFmpeg。没装的话Ubuntu 执行sudo apt install ffmpegmacOS 执行brew install ffmpegWindows 可以下载官方编译版或者用包管理器。找一个视频文件执行ffmpeg -re -i test.mp4 -c copy -f flv rtmp://你的服务器IP/live/livestream-re表示按视频原始帧率读取模拟实时推流效果-c copy表示不转码直接复制原始编码数据省 CPUrtmp://IP/live/livestream是推流地址live是应用名livestream是流名称可以随意取。推流开始后终端会不断刷新发送速度。看到类似speed1x的输出说明推流正常。这时候再验证一下能不能从 SRS 拉流播放。4.2 拉流播放验证 HLS 和 HTTP-FLV播放验证我推荐用 VLC跨平台且不需要额外插件。打开 VLC选择“打开网络串流”输入以下地址http://你的服务器IP:8080/live/livestream.m3u8如果配置了 HLS这个地址能直接播放延迟大概在 5 到 10 秒之间属于正常水平。想更低延迟就改用 HTTP-FLV 地址http://你的服务器IP:8080/live/livestream.flvVLC 对 FLV 的支持没有 HLS 那么好偶尔会出现有声音没画面或者打不开的情况遇到这种情况我建议直接用网页播放器测。SRS 默认的演示页面里有一组测试播放器你把流地址填进去如果页面里的播放器能出画面那说明 HTTP-FLV 链路没问题。WebRTC 的验证稍微麻烦一点SRS 提供了 WHIP 协议地址一般是http://你的服务器IP:1985/rtc/v1/whip/?applivestreamlivestream不过 WebRTC 最好用官方的在线测试工具或者集成到自己的网页里测试单纯用 VLC 是测不了的。4.3 用 API 接口确认服务器状态SRS 有一组 HTTP API这是它的一个很大优势。部署完最好花两分钟把这些接口都试一遍后续排查问题都用得上。浏览器访问http://你的服务器IP:1985/api/v1/versions正常情况下会返回一个 JSON里面包含 SRS 的版本号、启动时间等信息。再访问http://你的服务器IP:1985/api/v1/streams就能看到当前服务器上所有活跃的流包括流名称、客户端数量、推流地址这些信息。这个接口在排查“流到底有没有上来”这种问题时特别好用比翻日志快多了。有些老版本 API 的路径略有差异如果返回 404可以访问http://你的服务器IP:1985/api/v1/看一眼 API 列表。5. 常见问题与排查技巧实录5.1 推流失败握手超时怎么解决推流失败是最常见的问题现象是 FFmpeg 一直卡在Handshaking然后报Connection timed out。遇到这种情况我的排查顺序是固定的。先确认端口通不通telnet 你的服务器IP 1935通则显示Connected不通则卡住或者报错。如果 1935 端口不通99% 是端口没映射或者防火墙/安全组没放行。然后再确认 SRS 日志执行docker logs --tail 50 srs看看有没有收到来自你这台机器的连接请求。如果在日志里看到了连接但握手失败可能是 RTMP 推流地址格式不对检查一下是不是少了live应用名。还有一个小概率问题推流机器的系统时间不对。RTMP 握手对时间戳比较敏感时间差太大会握手失败。5.2 Docker 日志怎么高效查看SRS 容器运行中调试信息基本都在日志里。我常用的命令是# 查看最近100行日志 docker logs --tail 100 srs # 实时跟踪日志输出 docker logs -f srs # 按时间过滤 docker logs --since 5m srs不过要注意SRS 配置文件里srs_log_tank决定日志输出到哪里。如果写成file日志会写到 SRS 自己的日志文件里docker logs就看不到。调试阶段建议像我上面的配置一样写成console让 Docker 直接收集标准输出排查问题最方便。5.3 宿主机重启后容器不自动启动很多人部署完 SRS 觉得万事大吉结果服务器重启了一次发现服务回不来。这个极大概率是因为启动容器时没有设置restart策略。用docker run启动的话加参数--restart always用 Compose 的话在 service 下写restart: always。这个没啥好说的属于基础习惯问题但在实际项目里就是有大量人漏掉。如果已经启动的容器没加这个参数又不想重新创建容器可以执行docker update --restart always srs5.4 常见问题速查表问题可能原因解决方案容器反复重启配置文件缺少daemon off;在 srs.conf 开头加daemon off;1935 端口连不上端口未映射或防火墙拦截检查 docker 端口映射和安全组放行WebRTC 连不上8000/8001 UDP 端口未放行确认映射的是 UDP 协议安全组同步放开HLS 播放打不开未开启 hls 配置或端口被占用检查 srs.conf 中 hls 配置确认 8080 端口映射Docker 权限报错用户未加入 docker 组sudo usermod -aG docker $USER后重新登录Docker Desktop 虚拟化检测失败BIOS 中虚拟化技术未开启重启进 BIOS开启 Intel VT-x 或 AMD SVM镜像拉取慢网络原因给 Docker 配置 registry-mirrors 加速器选择可访问的镜像源如果你同时用 Docker Desktop 在 Windows/macOS 上跑 SRSWindows 下比较容易遇到 Hyper-V 或者 WSL2 相关的问题。SRS 镜像本身没有问题问题基本都出在 Docker 环境上。遇到 Docker Desktop 启动失败优先检查 BIOS 里的虚拟化开关这个在热搜词里出现频率很高说明确实是大众难题。5.5 一个隐蔽的坑HLS 文件权限与目录挂载最后分享一个我真正踩过的坑。当时我在服务器上用 Docker 部署 SRS开启 HLS 录播推流一直正常但播放 m3u8 时始终 404。翻日志发现切片文件写不进去报的是权限错误。排查后发现宿主机上创建的/data/srs/objs/nginx/html目录属主是 root而 SRS 容器内进程没有写权限。解决方法是直接在宿主机上调整目录属主chown -R 0:0 /data/srs/objs或者更简单粗暴一点直接chmod -R 777 /data/srs/objs反正是内部服务问题不大。但如果你对安全要求高建议了解一下容器镜像里 SRS 进程实际使用的 UID 和 GID再去对应设置宿主机目录的属主。这个问题的隐蔽之处在于SRS 推流本身是正常的没有任何报错只有 HLS 切片写不进去导致播放端拿到 m3u8 但里面引用的 ts 文件全都不存在。我当时排查了很久才发现是权限问题所以特别提醒一下。实战体会SRS 是我目前接触到的最适合快速搭建实时音视频平台的服务器尤其是配合 Docker十分钟内就能从零跑到推拉流全通。做这个部署的时候我最大的感受是步骤本身不复杂真正耗时的是排查各种环境问题端口没开、UDP 忘映射、目录权限不对、配置文件少了个daemon off。所以这篇文章花了大量篇幅讲排查思路而不是只给命令。最后再分享一个小技巧SRS 的官方镜像里其实内置了多个示例配置在容器里执行ls /usr/local/srs/conf/就能看到。需要什么场景的配置比如 WebRTC、SRT、GB28181直接找到对应的.conf文件拷出来改改就能用比自己从零写靠谱得多。这个细节官方文档提得不多但是真节省时间。