Docker 部署 SRS轻松搭建实时音视频流媒体平台我最早接触 SRS 是在做一个小型直播项目的时候当时甲方要求在三天内上线一个支持低延迟直播的内测环境还要能跟现有的服务做鉴权对接。说实话用传统方式编译 SRS 再配 Nginx 转封装时间根本不够。后来直接用 Docker 拉镜像跑起来一小时不到就把推拉流全链路打通了。几年用下来Docker 部署 SRS 已经成为我搭建实时音视频流媒体平台的首选方案不管是自己做实验还是交付给客户都省掉了大量踩坑时间。这篇文章就把我实际部署和调优 SRS 的经验完整记录下来。你如果是刚接触流媒体服务、想用 Docker 快速跑起一套能用的 RTMP/HLS/WebRTC 服务或者已经用 Nginx-RTMP 但觉得扩展性不够想试试 SRS 又不想从源码编译这篇内容都能直接帮到你。我会从最基础的概念讲起到 Docker 部署、配置解析、推拉流测试、鉴权接入最后是生产环境常见问题排查一步一步带你走通全链路。1. 为什么选 SRS 而不是 Nginx-RTMP 或其他方案1.1 先说清楚 SRS 到底解决了什么问题SRSSimple Realtime Server是一个开源的实时视频服务器用 C 写的专注于直播和实时音视频分发场景。它支持 RTMP、HLS、HTTP-FLV、WebRTC、SRT 等多种协议既能做直播流的接入和转发也能做简单的录制、转码、鉴权、集群分发。简单说你的手机、电脑、摄像头把流推上来SRS 负责让其他人通过网页、播放器、小程序等不同方式看到这份直播画面并且尽量保持低延迟、高并发、稳定不卡顿。我知道很多人第一反应是 Nginx-RTMP 模块也够用为什么非要换 SRS。我的真实体会是Nginx-RTMP 更像是“顺手做直播”它的核心毕竟是 Web 服务器RTMP 模块只是插件能力。当你需要 WebRTC 低延迟推拉流、需要 GB28181 接入摄像头、需要灵活的 HTTP 回调做鉴权和统计这些场景时Nginx-RTMP 会非常吃力甚至实现不了。SRS 从出生就聚焦在流媒体这个垂直领域对协议的支持、对并发性能的优化、对运维接口的完善程度都明显高一个段位。另外 SRS 的社区活跃度和文档质量在国产开源项目里属于第一梯队遇到问题搜一搜大部分都有答案。它的代码结构也清晰二次开发和定制非常方便。我见过不少团队从 Nginx-RTMP 迁移到 SRS基本上去一次就回不去了。1.2 Docker 在这里扮演什么角色SRS 虽然很强大但也有它的脾气。如果从源码编译需要拉取依赖、配置编译选项、处理系统兼容性整套流程对新手不太友好对时间紧迫的项目来说更是一种奢侈。更麻烦的是不同版本之间配置项有差异编译参数也影响功能开关换一台机器部署就要重新来一遍。Docker 把这些问题挡在了门外。SRS 官方提供了维护完善的 Docker 镜像镜像里已经编译好了所有常用模块拉下来就能跑。用 Docker 部署 SRS 意味着你的宿主机不需要装任何编译工具链和运行时依赖一个 Docker 引擎就搞定全部。另外镜像版本和宿主机操作系统是隔离的你在 Ubuntu 上测试好的一套配置到了 CentOS 或者 Windows Server 上一样能跑不会出现“换台机器就起不来”这种诡异问题。用 Docker 还有一个隐形优势版本回滚极其方便。我在生产环境吃过一次亏升级 SRS 版本后某个鉴权配置写法变了服务起不来急得一头汗。后来只要用到 Docker我都会先做好镜像 tag 绑定升级前保存当前容器出问题一条命令退回旧版本时间成本几乎为零。这种“后悔药”在交付现场真的能救命。1.3 一个类比装修房子和自己烧砖的区别说得直白点从源码编译安装 SRS 就像自己烧砖盖房子过程漫长而且要求你有一定的“施工资质”。而 Docker 部署 SRS 像买精装房钥匙拿到手热水器、马桶、地板都装好了你只需要把家具搬进去改配置马上就能入住。这两种方式的差距在赶工期的时候格外明显。2. 部署前的准备工作环境、镜像与网络规划2.1 Docker 环境安装的常见坑既然要用 Docker 部署 SRS第一步自然是先把 Docker 装好。Windows 用户通常会装 Docker Desktop这个工具集成度高图形界面方便但有两个非常典型的坑。第一个坑是虚拟化未开启。很多人在 Windows 上安装 Docker Desktop 后启动失败提示 virtualization support not detected 或者类似信息。这通常是因为 BIOS/UEFI 里的虚拟化技术Intel VT-x / AMD-V没有打开或者 Windows 的 Hyper-V / WSL2 功能没有启用。解决办法是重启进 BIOS找到虚拟化相关的开关打开然后在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”再执行一次wsl --update更新 WSL 内核最后重启 Docker Desktop。第二个坑是 WSL2 网络模式带来的端口绑定问题。Docker Desktop 在 Windows 上通过 WSL2 作为后端容器端口映射有时候会不稳定表现为映射成功后宿主机无法访问。我遇到这种情况通常会检查 Windows 防火墙是否拦截了对应端口或者直接把 WSL2 的镜像模式打开在.wslconfig文件中设置networkingModemirrored让 Windows 共享 WSL2 的网络栈。这个操作能省掉很多端口访问的烦恼。Linux 服务器上装 Docker 相对简单用发行版官方源安装就行。要注意的是别图省事用旧版本旧版 Docker 对容器网络的兼容性和资源隔离都有差距。安装完成后输入sudo docker run hello-world验证一下是否能正常拉取镜像并运行这比看任何教程都靠谱。2.2 选对 SRS 镜像版本不只是 latest 那么简单SRS 官方镜像在 Docker Hub 上有多个 tag很多人图省事直接拉latest这在我眼里是大忌。流媒体服务器是持续运行的服务稳定性优先latest 版本可能携带尚未充分验证的新特性配置格式也可能跟旧版本不兼容。线上环境一定要用具体版本号比如4.0.168或者至少固定大版本如4.0。SRS 当前主流大版本是 v4相比 v3 在 WebRTC 支持和配置结构上有明显变化。如果你需要 WebRTC 低延迟直播直接选择 v4 或更新版本。v3 也不是不能用但它对 WebRTC 的支持比较原始配置起来更费劲。我在测试环境会保留一个 SRS v5 的容器用来体验新特性但生产环境固定在 v4 的某个稳定版本上这个习惯帮我减少了很多不必要的麻烦。还有一个容易忽略的坑SRS 镜像分oss和full或者对应版本里的不同 tag前者是简化版不包含转码、DVR 等高级模块体积小但功能少。如果你要使用 FFmpeg 转码、录制文件、HLS 切片等功能务必选择功能完整的镜像。我一开始图镜像小用了精简版结果开启 HLS 配置后服务直接报错排查了半天才发现是镜像模块不完整。2.3 端口规划和防火墙策略SRS 用到的端口挺多的规划不好后面会乱。我通常建议预留以下端口1935RTMP 推流和拉流端口直播推流最核心的入口绝大多数推流软件都要用。8080HTTP 服务端口提供 API 接口、Web 控制台、HTTP-FLV 播放、HLS 文件访问。1985HTTP API 端口SRS 的鉴权、统计、回调接口都走这个端口。8000WebRTC over UDP 的媒体端口用于 WebRTC 推流和播放。8003/8081UDP 端口段WebRTC 音视频媒体传输使用。在云服务器上用 Docker 的-p参数映射端口时需要在安全组和宿主机防火墙里同时放行这些端口。我有一次部署完了本地推流正常客户端换到外网就黑屏折腾了半天最后发现是云服务商安全组没放行 UDP 的 8000 端口WebRTC 握手能通但媒体数据传输被拦截。这里特别提醒TCP 和 UDP 都要检查不要只放行 TCP。3. 核心概念梳理RTMP、HLS、HTTP-FLV 与 WebRTC 怎么选3.1 四种协议各自的脾气部署 SRS 之前先把协议这一课补上否则配置写了也不知道在配什么。RTMP 是直播界的老大哥基于 TCPAdobe 搞出来的协议推流端兼容性极好几乎所有直播软件OBS、手机推流 App都支持 RTMP 推流。但是 RTMP 拉流在浏览器里没法直接播放因为浏览器不支持这种格式需要借助 Flash 插件或者做协议转换这也是它逐渐被 HTTP-FLV 和 WebRTC 替代的原因。HLS 是苹果主导的协议原理是把视频切成一个个小 ts 文件通过 m3u8 索引文件让播放器顺序拉取。它的优势是能直接跑在普通 HTTP 服务器上兼容性极佳iOS 和 Android 浏览器原生支持。缺点是延迟非常高切片大小加上播放器缓冲真实延迟通常在 5 到 30 秒之间。所以 HLS 适合对实时性要求不高、但要求稳定可回放的应用比如活动录像回放、教育课程点播。HTTP-FLV 是国内的“土生土长”方案核心思想是把 FLV 数据包封装在 HTTP 响应里播放器通过流式读取的方式实现低延迟播放。延迟能做到 1 到 3 秒而且兼容 H5 播放器很多直播平台在 PC 端就是用它来拉流。缺点是移动端 iOS 原生不支持 FLV需要依赖 flv.js 这类库而且对服务器并发有一定压力。WebRTC 是这两年最火的方案基于 UDP延迟能做到 500 毫秒以内浏览器原生支持。SRS v4 开始对 WebRTC 支持得特别好适合视频连麦、在线课堂、低延迟监看这些场景。缺点是 UDP 在网络穿透上比较复杂服务器和客户端之间可能需要处理 NAT 穿透问题虽然在公网部署 SRS 并且开启相关配置后大部分情况都能直接用。3.2 选择策略不同场景配不同协议实际项目里我会遵循一条简单的选择原则推流端一律采用 RTMP 或 WebRTC拉流端根据用户终端决定。PC 网页用户优先用 HTTP-FLV移动端浏览器优先用 HLS 或者 WebRTC需要超低延迟互动场景直接上 WebRTC。SRS 的厉害之处在于这个配置不用你额外做复杂的转换逻辑。它接受 RTMP 推流进来然后同时输出 HLS、HTTP-FLV、WebRTC 等多种格式客户端各取所需这个过程在 SRS 内部自动完成。我们只需要在配置文件中打开对应模块端口不冲突就能一鱼多吃。3.3 关键参数解释这些配置项到底在干什么看 SRS 配置文件时最影响理解的是几个核心参数。listen设置 RTMP 的监听端口默认 1935一般不用改。http_api里的enabled开启 HTTP API 服务listen对应 1985 端口这里是 SRS 对外暴露控制接口的地方。http_server里的enabled开启 HTTP 文件服务监听 8080 端口HLS 切片文件就是从这里往外发的。rtc_server块负责 WebRTC 相关配置enabled打开 WebRTC 后listen是 UDP 端口candidate和api需要填服务器公网 IP 或域名。这一块是 WebRTC 部署最容易踩坑的地方后面我会专门讲。vhost可以理解为虚拟主机配置块类似 Nginx 的 server 块。你可以针对不同的应用配置不同的转发、鉴权和转码策略。vhost __defaultVhost__表示默认虚拟主机在http_remux块里开启 HTTP-FLV 转发在hls块里开启 HLS 切片在rtc块里开启 WebRTC 支持。4. 实操用 Docker 部署 SRS 并完成首次推拉流4.1 完整部署步骤一条命令启动服务直接进入正题。我以 Docker 方式在 Linux 服务器上部署 SRS v4 为例整个流程如下。确立工作目录和配置目录方便管理mkdir -p /opt/srs/config mkdir -p /opt/srs/objs创建一个基本的配置文件/opt/srs/config/srs.conf。这个配置兼容推流和各类拉流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; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 2; hls_window 6; } rtc { enabled on; rtc_port 8000; } }启动容器。这里我解释一下关键参数docker run -d --name srs \ -p 1935:1935 \ -p 1985:1985 \ -p 8080:8080 \ -p 8000:8000/udp \ -v /opt/srs/config/srs.conf:/usr/local/srs/conf/srs.conf \ -v /opt/srs/objs:/usr/local/srs/objs \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4.0.168参数说明-d表示后台运行--name srs给容器命名-p映射端口-v挂载配置文件和日志目录。这里的-v /opt/srs/config/srs.conf保证你改宿主机上的配置就相当于改容器里的配置不用进容器编辑挂载objs目录则方便你在宿主机直接查看 HLS 切片文件。启动后检查容器状态docker ps | grep srs docker logs srs --tail 50如果看到类似rtmp server started或http server started的输出说明服务已经正常运行。此时访问http://服务器IP:8080/能看到 SRS 的控制台页面访问http://服务器IP:1985/api/v1/versions能拿到 JSON 格式的版本信息。4.2 推流测试用 FFmpeg 模拟一整个直播源首次验证一般不用真实摄像头用 FFmpeg 推送一个测试视频文件是最快的方式。这里我给大家一个可以直接套用的命令ffmpeg -re -i /path/to/test.mp4 \ -c:v libx264 -preset veryfast -tune zerolatency \ -c:a aac \ -f flv rtmp://服务器IP:1935/live/test解释一下各参数-re按视频原始帧率读取模拟直播推流的速度-c:v libx264用 H.264 编码视频-preset veryfast -tune zerolatency追求编码速度和低延迟适合直播-c:a aac音频编码为 AAC-f flv指定输出格式。如果没有现成的测试视频可以用 SRS 官方提供的测试素材或者用另一条命令生成测试画面ffmpeg -re -f lavfi -i testsrcsize1280x720:rate30 \ -f lavfi -i sinefrequency440:sample_rate44100 \ -c:v libx264 -preset veryfast -tune zerolatency \ -c:a aac \ -f flv rtmp://服务器IP:1935/live/test推流成功后在 SRS 控制台http://服务器IP:8080/players/页面输入对应的拉流地址就能直接预览。也可以用 VLC 播放器打开rtmp://服务器IP:1935/live/test验证 RTMP 拉流是否正常。4.3 拉流验证的多种方式RTMP 拉流测试用 VLC 最直观输入地址能播放就说明链路通了。HTTP-FLV 地址则是http://服务器IP:8080/live/test.flv这个地址可以直接在浏览器上用 flv.js 播放也可以用 VLC 打开。HLS 地址是http://服务器IP:8080/live/test.m3u8这个地址在 iOS 手机上直接用 Safari 打开就能播放。WebRTC 拉流地址通常是在控制台提供的形如webrtc://服务器IP/live/test需要通过支持 WebRTC 的播放器页面测试。4.4 为什么用 Docker 跑 SRS 比直接装效率高这么多我这么说可能有点主观但实测下来确实如此。Docker 容器将 SRS 及其运行环境打包在一起宿主机只要装了 Docker 就能跑不管底层操作系统是 CentOS 7、Ubuntu 22.04 还是 Debian结果完全一致。相比之下直接装 SRS 意味着你要先处理编译依赖装 GCC、Make、Python、Perl运气不好还要解决 Perl 模块缺失的问题。这一套下来快的话半小时慢的话一上午就没了。而且 Docker 天然支持多实例。你可以同时跑一个 SRS v3 和一个 SRS v4端口冲突就用不同的映射做新旧版本对比。这种能力在验证配置是否兼容时极其好用直接装的话几乎不可能实现。5. 高级配置鉴权、分发与实时转码5.1 推流鉴权让陌生人无法往你的服务器塞流没有鉴权的流媒体服务器等于裸奔。任何人知道你的服务器 IP 和端口都可以推流上来占用你的带宽和资源。我见过不少项目上线很久才发现服务器在被盗刷流量就是鉴权这层没做。SRS 支持在 HTTP 回调里做鉴权叫 on_publish 事件。当客户端尝试推流时SRS 会向配置的回调地址发送一个 HTTP 请求把推流参数比如 token、sign带过去你的后端服务校验通过就返回 0拒绝就返回非 0。配置只有在 vhost 里加vhost __defaultVhost__ { http_hooks { enabled on; on_publish http://你的回调服务地址:端口/api/srs/on_publish; on_play http://你的回调服务地址:端口/api/srs/on_play; on_stop http://你的回调服务地址:端口/api/srs/on_stop; } }配合推流端OBS 可以设置推流串流密钥之后 RTMP 地址变成rtmp://IP:1935/live/test?token你的密钥。SRS 收到推流后会在回调请求里带上token参数后端校验这个 token 是否有效。这种方式和 CDN 的鉴权思路完全一致上线前我强烈建议务必配好。5.2 多节点分发一台不够时怎么横向扩展随着并发用户增加单台 SRS 可能会成为瓶颈。SRS 支持 Origin 和 Edge 两种角色Origin 负责接收推流和存储流Edge 负责转发给拉流用户。这种架构下推流只需要到 Origin 一台服务器拉流的用户分散到多个 Edge 服务器上自动减轻了单台机器的下行压力。Docker 部署 Edge 节点时配置会简单很多。Edge 不接收推流只做转发类似 CDN 的边缘节点vhost __defaultVhost__ { mode remote; origin http://Origin服务器IP:1985; }这种架构做横向扩展非常容易再跑一个 Docker 容器配置里的 origin 指向同一个 Origin 服务器即可。负载均衡层放一个 Nginx 做多 Edge 之间的流量分发整套体系就能扛住比较大的并发。5.3 实时转码FFmpeg 与 SRS 的协同SRS 本身不做转码但可以通过 FFmpeg 来实现。常见的需求是接收 RTMP 推流后给流做转码输出多个清晰度比如 1080P 和 720P 同时输出或者把某些非标准编码转成 H.264 AAC 的标准直播流。SRS 的配置里可以设置转码规则指定 FFmpeg 转出新的流继续在同一个 SRS 里分发。在 Docker 场景下为了让 SRS 能够调用 FFmpeg需要在镜像里包含 FFmpeg 可执行文件。选择full或ffmpeg版本的镜像即可。转码配置比较简单vhost __defaultVhost__ { transcode { enabled on; ffmpeg ./objs/ffmpeg/bin/ffmpeg; engine ffmpeg { vcodec libx264; vbitrate 2500; acodec aac; abitrate 128; output rtmp://127.0.0.1:[port]/live/[stream]_trans; } } }转码会显著消耗 CPUDocker 部署时建议给容器设置 CPU 限制避免转码任务吃满宿主机资源。我一般会在docker run时加--cpus2之类的参数防止某个转码任务把整台服务器拖垮。5.4 Docker 网络模式对性能的影响Docker 的默认网络模式是 bridge容器通过 NAT 访问外网。这种模式对大多数场景完全够用但在高性能流媒体服务中NAT 转发会带来一点点额外开销。如果你非常在意性能可以用--networkhost模式让容器直接使用宿主机网络SRS 直接绑定宿主机的 IP 和端口性能最接近原生部署。使用 host 模式的代价是端口隔离会消失容器监听哪个端口就直接占宿主机的端口。但如果你的宿主机就是专门跑流媒体服务的我建议直接上 host 模式性能和稳定性都有提升。配置起来更简单端口不用映射SRS 配置里的监听端口就是宿主机的端口。6. 常见问题排查与优化实录6.1 推流失败connection refused 和握手失败推流失败最经典的报错是connection refused这种情况分两步排查。第一步确认容器是否在运行docker ps看 srs 容器状态如果容器没起来看docker logs srs的日志找原因。第二步确认端口映射是否正常netstat -tlnp | grep 1935如果宿主机上没监听 1935说明映射有问题重新跑容器即可。如果是握手失败或者推流超时优先怀疑防火墙或者安全组。我做 WebRTC 时踩过一个印象深刻的坑推流地址用的 1935 端口能推上去但网页播放 WebRTC 始终黑屏排查了编码、分辨率、候选地址各种原因最后发现是安全组没放行 UDP 8000 端口。TCP 的握手能通过但真正的媒体数据走 UDP被防火墙拦截后播放端什么都收不到。所以检查安全组时TCP 和 UDP 一定要分开看不能只盯着 TCP。6.2 WebRTC 黑屏、卡顿的排查思路WebRTC 黑屏的排查有三板斧。第一板斧看 SRS 日志日志里会明确提示 candidate 相关错误或者 ICE 协商失败。第二板斧确认配置文件里的candidate是不是服务器正确的公网 IP这个是 WebRTC 能不能打通的命门。如果服务器 IP 是内网 IPSRS 通过容器映射到公网需要在配置里指定公网 IPrtc_server { enabled on; listen 8000; candidate 你的公网IP; }第三板斧是检查浏览器的控制台日志。Chrome 的chrome://webrtc-internals页面能看到完整的 ICE 候选、SDP 协商过程配合 SRS 服务端日志基本能定位问题。实测下来80% 的 WebRTC 问题出在 candidate 配置和防火墙拦截上把这两项检查完才能继续看编码和网络质量问题。6.3 HLS 播放卡顿、延迟高怎么办HLS 延迟高是协议特性决定的但卡顿往往和切片参数有关。hls_fragment是每个切片文件时长hls_window是保留的切片数量。如果hls_fragment设成 10 秒播放器加载一个切片可能要等 10 秒再加上缓冲延迟自然很大。我把hls_fragment调到 2 秒、hls_window调到 6 秒延迟能从十几秒压缩到 5 到 8 秒左右。当然想继续压低就要考虑 HTTP-FLV 或者 WebRTC。HLS 切片写入速度和磁盘 IO 关系也很大。如果宿主机磁盘 IO 性能差切片写入慢播放器拉取 m3u8 索引时会看到文件尚未生成完毕的问题。Docker 部署时挂载的目录尽量用 SSD不要用机械盘尤其在高并发场景下这个因素会被放大。6.4 Docker 容器 OOM 和 CPU 占用过高SRS 默认配置下内存占用不高但并发上来后线程和缓冲会增长。我在docker run时加上了-m 4g --memory-swap 4g之类内存限制防止极端情况下容器占满全机内存。如果内存确实不足优先优化 SRS 的max_connections和队列缓冲而不是盲目升配服务器。CPU 占用过高先看是不是开了转码FFmpeg 转码是 CPU 杀手。转码规格从veryfast改成ultrafast能显著降低 CPU 负载画质损失在直播场景其实感知不强。再检查是不是有人恶意刷流SRS 控制台的统计页面能看到每个流的实时连接数如果某个流异常高直接抓包查来源。6.5 配置了 HTTP 回调但收不到请求HTTP 回调收不到请求是鉴权场景的经典问题。我自己也踩过这个坑最后发现原因很简单配置里的回调地址用了127.0.0.1。容器内的127.0.0.1指向容器自身而不是宿主机。正确的写法应该是用 Docker 的网关 IP或者直接用宿主机在局域网中的 IP。如果你用 Docker Compose 编排服务名可以直接作为主机名使用比如回调地址填http://my-backend:8080/api/srs/on_publish。回调整体调通后可以在回调服务里先记录所有请求参数确认 SRS 发了什么再写业务逻辑。这是调试时的通用做法避免你对着空日志瞎猜。7. 从单机到生产SRS 和 Docker 的进一步玩法7.1 Docker Compose 编排全套流媒体服务单容器部署 SRS 只是第一步。真实项目中SRS 往往和鉴权服务、转码任务、监控告警系统并存。Docker Compose 能把这些服务编排在一起一条命令启动整套平台。一个典型的docker-compose.yml大概长这样version: 3 services: srs: image: registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4.0.168 container_name: srs restart: always network_mode: host volumes: - ./config/srs.conf:/usr/local/srs/conf/srs.conf - ./objs:/usr/local/srs/objs api: build: ./backend container_name: srs-api restart: always ports: - 9000:9000 monitor: image: grafana/grafana:latest container_name: srs-monitor restart: always ports: - 3000:3000使用 Compose 的好处是环境一致性拉满。我交付给客户的方案经常是一整个docker-compose.yml外加几个配置文件客户只需要装好 Docker 和 Compose然后docker compose up -d就能完成部署。这种交付效率比写二十页部署文档高太多了。7.2 容器日志、监控与可视化SRS 本身提供 HTTP API我们可以通过1985端口的 API 获取服务器状态、流列表、连接数等数据。生产环境中我用 Prometheus 采集这些指标Grafana 做可视化面板能一眼看到当前活跃流数、总带宽和错误率。Docker 容器的 CPU、内存数据用 cAdvisor 采集配置好了之后整个平台运行状态尽在掌握。日志方面SRS 在 Docker 里的标准输出可以通过docker logs查看。生产环境建议加一个json-file驱动的日志轮转避免长时间运行后日志文件膨胀占满磁盘。启动容器时加参数--log-driver json-file --log-opt max-size100m --log-opt max-file3这样单日志文件最大 100MB保留 3 个轮转文件磁盘占用可控。7.3 数据持久化与备份策略Docker 容器的文件系统是临时的容器删除后数据就没了。SRS 的 DVR 录制文件、HLS 切片文件都在objs目录一定要通过-v挂载到宿主机否则容器一重启历史数据全部消失。这点提醒过很多人还是有人会踩。备份策略上我会用脚本定期把objs目录里的重要录制文件同步到远端存储比如对象存储或者 NAS。HLS 切片属于临时文件有hls_window控制生命周期不需要全量备份。录制文件则按业务重要性决定保留周期一般是 30 天到 90 天。7.4 实战案例一个小型互动直播系统的完整配置最后分享一个我前几天交付的小型互动直播系统的配置这套方案同时满足低延迟直播WebRTC 播放、标准直播HTTP-FLV/HLS 播放、录制回放DVR 录制三种需求。配置文件关键部分listen 1935; max_connections 2000; daemon off; srs_log_tank console; http_api { enabled on; listen 1985; } 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 2; hls_window 6; } rtc { enabled on; rtc_port 8000; candidate 公网IP; } dvr { enabled on; dvr_path /usr/local/srs/objs/rec/[app]/[stream]/[2006]/[01]/[02]/[15]/[04]/[05].flv; dvr_plan session; } http_hooks { enabled on; on_publish http://api平台地址:9000/api/srs/auth; on_play http://api平台地址:9000/api/srs/auth; on_stop http://api平台地址:9000/api/srs/report; } }这套配置跑在小型云服务器上2 核 4G实测支持同时 50 路 RTMP 推流200 路并发观看录制和低延迟播放同时开启CPU 峰值约 70%稳定运行两周没有重启。Docker 部署、host 网络模式、SSD 数据盘就是全部的架构要点。8. 写在最后的个人心得Docker 部署 SRS 这件事本质上就是现代运维思维在流媒体领域的一次落地。你不再需要关心 SRS 是怎么编译出来的只需要知道这个工具能做什么、配置该怎么写、数据往哪里放。这种“依赖隔离”带来的安心感是直接安装二进制包很难体验到的。如果让我给你一个行动建议第一步先把 Docker 环境装好第二步拉一个 SRS 镜像用默认配置跑起来第三步拿 FFmpeg 推一条测试流第四步打开控制台看看画面。整个流程熟练之后你会发现流媒体服务器不再只是“听起来高大上”的技术而是一个像装 Nginx 一样稀松平常的基础设施。如果后面遇到奇怪的 WebRTC 连不上、内存被打满、回调收不到请求这类问题回头翻翻这篇里的排查思路大概率能帮你省下几小时的折腾时间。流媒体这条路踩的坑不少但每次把问题解决掉把整套服务稳定跑起来还是挺有成就感的。