最近后台收到不少朋友的私信，都在问怎么把家里的监控摄像头、无人机图传或者自己录好的视频流，稳定地推到 Web 页面或者 App 上实时观看。有人直接用 Nginx 搭 RTMP 服务，结果延时要好几秒，移动端兼容性也麻烦；有人折腾了一天编译 ZLMediaKit，最后卡在依赖问题上。其实没必要这么折腾，我一直用的方案是 SRS（Simple Realtime Server），配合 Docker 部署，前后不到半小时就能把一套支持 RTMP、HTTP-FLV、WebRTC、HLS 的流媒体服务跑起来，而且后续换机器、迁移配置都特别省心。

这篇文章就围绕我实际搭建 SRS 流媒体平台的完整过程来写，内容包括为什么选 SRS 而不是其他方案、Docker 部署前后要做哪些准备、一条命令跑起来之后怎么验证推拉流、以及把 RTSP 摄像头接到 WebRTC 低延迟播放的实战配置。无论你是刚接触流媒体的小白，还是已经在用其他服务想迁移过来的老手，都能照着这篇文章一步步落地。文中涉及的坑基本都是我踩过的，直接抄作业就行。

1. 为什么是 SRS：流媒体服务器的选型分析与部署思路

1.1 SRS 到底解决了什么问题

SRS 是一个开源的实时音视频服务器，核心定位就是把各种来源的音视频流接收进来，再转成用户端能播放的格式分发出去。它原生支持 RTMP、HLS、HTTP-FLV、WebRTC、SRT、GB28181 等一大堆协议，可以说覆盖了当前直播和实时通信的主流场景。

我最早用的是 Nginx 加 nginx-rtmp-module，简单推流播放确实没问题，但一旦涉及低延迟的 WebRTC 播放、多路流转发、HLS 切片回放，扩展就变得很吃力。SRS 在协议支持上更全面，尤其是 WebRTC 这块，它内置了 WHIP 和 WHEP 端点，可以直接和浏览器原生连接，不需要额外装插件，这在现在的直播、在线教育、视频会议场景里太重要了。

单论服务本身，SRS 支持常规的 RTMP 推流、HTTP-FLV 低延迟播放、HLS 直播和录制、DASH、SRT 等。它还有一套 HTTP API 和钩子机制，可以对接自己的后台系统，做鉴权、统计、转码通知等操作。这些都是真实生产环境里会用到的东西。

1.2 对比其他方案，为什么 Docker 部署 SRS 更合理

很多人在 Nginx-RTMP、ZLMediaKit、Janus 和 SRS 之间犹豫。我简单说说我的感受：

• Nginx-RTMP：配置简单，但功能偏弱，WebRTC 需要额外插件，HLS 切片质量和灵活性也一般，适合做最简单的推拉流演示。
• ZLMediaKit：性能和协议支持也很强，但依赖库比较多，编译配置门槛高，需要自己花时间踩坑。
• Janus：偏向 WebRTC 网关，做 SFU 场景很专业，但直播分发这块不如 SRS 直接，学习曲线也陡。
• SRS：开箱即用，配置文档特别全，Docker 镜像官方维护，社区也活跃。它既能当直播服务器，也能做 WebRTC 网关，属于综合能力均衡的方案。

Docker 部署最大的优势是环境隔离和快速起停。SRS 是一个 C++ 写的服务，虽然编译安装也不算难，但要编译出支持 WebRTC、SRT、GB28181 的完整版本，依赖库和编译参数都得仔细处理，新手很容易在 ./configure 阶段就卡住。用 Docker 镜像后，这些全部打包好了，pull 下来就能跑，迁移的时候也只要把镜像和配置文件带走，避免了各种“我这能跑你那不能跑”的麻烦。

1.3 我能想到的典型应用场景

• 家里有 IPC 摄像头或树莓派摄像头，想把 RTSP 流转成浏览器里低延迟播放的 WebRTC 流，随时用手机看。
• 用 OBS 或 vMix 做直播推流，需要分发到自己的网页或小程序，希望延迟在 1 秒以内。
• 录好的视频要提供给小范围用户回看，用 HLS 切片比较稳妥，兼容性最好。
• 想接 GB28181 国标设备的场景，SRS 也有对应模块，不过那是另一个大主题，本文先聚焦最常用的直播流转发。

文章后面的内容，我以 Docker 部署官方镜像为主线，带着你把整个平台搭起来，再通过实际案例演示推流和播放。

2. Docker 部署前的环境准备与端口规划

2.1 安装 Docker 时容易忽略的细节

SRS 的镜像不挑系统，只要 Docker 能跑就行。Linux 服务器上我一般用官方安装脚本，Windows 和 macOS 直接装 Docker Desktop 就可以。不过有几点要提醒：

• 老机器上如果 BIOS 里没有开启 CPU 虚拟化，Docker Desktop 会启动失败，报错信息类似 “virtualization support not detected”。这个问题在 Windows 上特别常见，需要进 BIOS 打开 Intel VT-x 或 AMD-V。
• Windows 下 Docker Desktop 默认使用 WSL 2，如果之前装过旧版的 WSL 内核，最好先执行 wsl --update 升级，否则容器运行时会莫名卡顿。
• Linux 下 docker 命令如果提示权限不足，说明当前用户不在 docker 用户组里。执行 sudo usermod -aG docker $USER 后，重新登录一次生效。别直接 sudo 套在每条命令前面，后面挂载目录、写日志时权限会很乱。

2.2 镜像加速配置

国内拉取 Docker Hub 镜像经常不稳定，这跟网络环境有关。最简单的方式是给 Docker 配置镜像加速源。这里我用自己的云厂商提供的加速器地址，不同服务商给的地址不一样，也可以搜一下当前可用的公共加速源来配置。

注意：不要随意添加来路不明的镜像源，尽量使用云厂商或可信的公共源，避免拉到被篡改的镜像。

配置方法分两种：

• Docker Desktop 用户：在 Settings -> Docker Engine 里修改 registry-mirrors 配置。
• Linux 用户：编辑 /etc/docker/daemon.json，内容格式类似：

{
  "registry-mirrors": ["https://你的加速地址"]
}

改完执行 systemctl daemon-reload && systemctl restart docker 重启服务。这个配置只影响拉取镜像，不影响运行容器。

2.3 端口规划与防火墙放行

SRS 涉及的典型端口如下：

端口	协议	用途
1935	TCP	RTMP 推流和拉流
1985	TCP	HTTP API、Web 后台、WHIP/WHEP 信令
8080	TCP	HTTP-FLV、HLS、WebRTC 播放资源
8000	UDP	WebRTC 媒体传输
9000	UDP	SRT 媒体传输（如用到）

端口规划的原则是：信令走 TCP，媒体流走 UDP。WebRTC 场景如果 8000 端口不通，播放一定会失败，所以防火墙和安全组里要把 UDP 8000 也加上。很多朋友服务器部署完推流正常，网页却播放不出来，90% 是 UDP 端口没放行。

Docker 容器里还有个细节，启动时通过 -p 映射端口，建议显式指定主机端口和容器端口，例如 -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 8000:8000/udp。不要图省事用 -P 自动映射端口，因为 SRS 生成的播放地址里会用到固定端口，自动映射会把端口变成随机值，带来额外的配置成本。

2.4 目录规划：配置、日志、录像分开

虽然 Docker 里可以直接把配置写在启动命令里，但我还是建议把配置文件和录像目录挂载出来。原因有两个：

• 升级镜像时，容器内的文件会全部替换，挂载到宿主机才能保留自定义配置和历史录像。
• 排查问题方便。直接进宿主机目录就能看日志和切片文件，不用 docker exec 进容器里面翻。

我会在宿主机上建一个 /opt/srs 目录，下面再分 conf、log、objs 三个子目录，分别放配置、日志、临时切片或录像文件。用 docker compose 管理时，挂载关系一目了然。

3. Docker 部署 SRS 的完整实操记录

3.1 官方镜像与标签选择

SRS 官方镜像在 Docker Hub 上，仓库名是 ossrs/srs。稳定版本建议直接用 release 标签对应的镜像版本，比如 ossrs/srs:5.0，这比用 latest 更稳妥，因为 latest 有时会指向开发中的版本，配置格式和模块可能有变化。

拉取命令是：

docker pull ossrs/srs:5.0

拉取完成后可以用 docker image inspect ossrs/srs:5.0 查看镜像信息，包括暴露的端口和默认启动命令。

3.2 先别急着 docker run：理解 SRS 配置结构

SRS 的配置文件是 srs.conf，采用 key-value 结构，核心是定义 listener、vhost、app 和转发规则。默认配置里已经包含了一个简单的 RTMP 和 HTTP-FLV 生效的配置，但 WebRTC 和 HLS 需要额外开启。

理解 SRS 配置的关键点是：

• listen 表示监听端口列表，SRS 默认在 1935 端口监听 RTMP。
• http_api 和 http_server 分别对应 API 端口和 HTTP 文件服务端口。
• vhost 是逻辑上的虚拟主机，用来区分不同业务线，可以针对每个 vhost 单独设置转码、转发、HLS 等。
• rtc_server 负责 WebRTC 相关配置，包括 UDP 端口范围。
• hls 配置里要指定切片存放路径，以及切片时长。

Docker 启动时可以用 -p 把端口映射出来，也可以用 --env 传一些环境变量，但最核心的配置我建议直接写在 srs.conf 里，然后挂载进容器，这样在任何环境下都能保持一致的配置。

3.3 一条 docker run 命令跑起 SRS

先进行最小化启动验证。执行下面的命令，把容器跑起来：

docker run -d --name srs \
  -p 1935:1935 \
  -p 1985:1985 \
  -p 8080:8080 \
  -p 8000:8000/udp \
  -v /opt/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf \
  -v /opt/srs/log:/usr/local/srs/objs \
  ossrs/srs:5.0

命令里每个参数都有含义：

• -d 表示后台运行，让容器在退出终端后继续跑。
• --name srs 给容器起一个固定名字，方便后续 docker logs srs 查看日志。
• -p 把宿主机端口映射到容器端口，注意 UDP 端口要写成 8000/udp。
• -v 把宿主机上的 srs.conf 覆盖容器内的默认配置。

跑起来后先看日志：

docker logs srs

如果看到类似 “SRS is running fine” 的输出，说明服务已经正常启动。这时候用浏览器访问 http://服务器IP:8080，如果能看到 SRS 的默认提示页面，就说明 HTTP 服务也通了。

3.4 用 docker-compose 固定配置，避免手滑删容器

docker run 适合快速测试，但每次重启容器都要重新敲一长串参数，而且配置文件在宿主机哪个位置全靠记性。我更推荐用 docker compose 管理，尤其是服务器上服务很多的时候。

我一般是新建一个 /opt/srs/docker-compose.yml 文件：

version: "3.8"

services:
  srs:
    image: ossrs/srs:5.0
    container_name: srs
    restart: unless-stopped
    ports:
      - "1935:1935"
      - "1985:1985"
      - "8080:8080"
      - "8000:8000/udp"
    volumes:
      - /opt/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf
      - /opt/srs/log:/usr/local/srs/objs

restart: unless-stopped 这个策略强烈建议加上。服务器重启或者容器异常退出时，Docker 会自动把 SRS 拉起来，省了很多人工干预。

配置文件准备好后，在 /opt/srs 目录下执行：

docker compose up -d

后期需要更新配置时，先 docker compose restart 让配置重新加载。如果改了端口或挂载目录，就 docker compose down && docker compose up -d 彻底重建容器，避免旧容器残留干扰。

3.5 搭建完成后的连通性自检清单

容器跑起来不等于全部可用，我一般按下面的顺序排查：

1. RTMP 端口通不通：本地用 telnet 服务器IP 1935 看是否能够连接。
2. API 端口通不通：curl http://服务器IP:1985/api/v1/versions，如果返回 JSON 版本信息，说明 API 正常。
3. HTTP 8080 通不通：浏览器访问 http://服务器IP:8080，能看到 SRS 默认页面。
4. UDP 8000 通不通：这个没法用 telnet 直接测，可以留到后面用 WebRTC 播放实测。

如果前三步都通了，SRS 基础服务就算搭建完成。接下来进入推流和播放验证阶段。

4. 推流、播放与转码配置：从一条流到完整直播链路

4.1 推流地址的组成规则

SRS 默认的推流地址格式为：

rtmp://服务器IP:1935/live/流名称

比如我定义流名称为 cam_main，那么完整推流地址是：

rtmp://192.168.1.100:1935/live/cam_main

这里的 live 是默认的 vhost/app 名，流名称可以自定义，用来区分不同的直播频道。同一台 SRS 上跑多路流，只要流名称不重复就行。

4.2 用 OBS 推一套流做验证

OBS 是最常用的推流软件，操作路径是：打开 OBS -> 设置 -> 直播，在服务里选自定义，服务器填 rtmp://服务器IP:1935/live，推流码填流名称 cam_main。

这里有个很容易踩的坑：推流地址和串流密钥是分开的，不同软件叫法不一样，但底层就是把 RTMP URL 拆成两部分。在 SRS 里，实际接收的完整地址是 服务器IP:1935/live/cam_main，所以 OBS 里服务器填 rtmp://IP:1935/live，串流密钥填 cam_main 就行。

点击开始推流后，回到 SRS 容器日志里验证：

docker logs -f srs

看到类似 “new subscriber” 或 “rtmp: post publish” 的日志，说明推流成功。

4.3 播放地址与内置 demo 播放器

SRS 容器里带了一个简单的前端播放页面，路径是：

http://服务器IP:8080/players/rtc_player.html

这个页面可以直接播放 WebRTC 流，不过默认播放地址需要自己填。如果只是快速验证，我通常用 VLC 或 ffplay 拉流：

• RTMP 播放：rtmp://服务器IP:1935/live/cam_main
• HTTP-FLV 播放：http://服务器IP:8080/live/cam_main.flv
• HLS 播放：http://服务器IP:8080/live/cam_main.m3u8

注意，HLS 和 FLV 需要配置里开启对应模块才能使用。默认配置可能只开启了 RTMP，所以要先确认 srs.conf 里的 http_remux 和 hls 配置。

4.4 配置 HLS 和 HTTP-FLV 的细节

HLS 的用户体验是兼容性最好，几乎所有播放器都支持，缺点是延迟一般在 3 到 10 秒。HTTP-FLV 是低延迟场景的好选择，延迟可以压到 1 秒左右，在浏览器里用 flv.js 就能播放。

在 srs.conf 里，我在 vhost 块中加一段配置：

vhost __defaultVhost__ {
    http_remux {
        enabled on;
        mount [vhost]/[app]/[stream].flv;
    }
    hls {
        enabled on;
        hls_path ./objs/nginx/html;
        hls_fragment 2;
        hls_window 10;
    }
}

hls_fragment 表示切片时长，单位是秒。我一般设成 2 秒，这样 HLS 延迟能控制在 5 秒左右。hls_window 表示保留多少个切片的时长，设置太短会导致回看只有最近几秒钟的内容。

改完配置后不要逐个页面刷新去验证，直接看日志和生成的文件：

ls /opt/srs/log/nginx/html

如果能看到类似 cam_main.m3u8 和 .ts 切片文件，说明 HLS 模块正常工作。

4.5 内置转码：需要时才加的硬骨头

SRS 本身不内置 FFmpeg 转码器，但它可以调用外部 FFmpeg 做转码。比如摄像头推上来的流是 H.265 编码，而多数浏览器播放不了 H.265 的 WebRTC 流，这时候就需要转码成 H.264。

转码配置基本思路是在 srs.conf 里加 transcode 模块，然后指定 ffmpeg 可执行文件和转码参数。但说实话，如果你只是自己玩玩，我建议先不要碰转码，等流媒体基础链路走通后再考虑。转码是 CPU 密集操作，转一路 1080p 流，普通服务器压力就很大。更简单的思路是直接让推流端用 H.264 编码，比如 OBS 或摄像头后台设置里改成 H.264，这样 SRS 就不需要转码，性能开销小很多。

5. 实战案例：把 RTSP 摄像头画面接入 SRS，实现浏览器低延迟播放

5.1 RTSP 拉流转发的实现原理

很多监控摄像头都支持 RTSP 协议，地址类似 rtmp://摄像头IP:554/stream1 或者 rtsp://用户名:密码@摄像头IP:554/Streaming/Channels/101。浏览器没法直接播放 RTSP，所以需要 SRS 主动去拉取摄像头的 RTSP 流，再转成 WebRTC 或者 HTTP-FLV 分发给浏览器。

SRS 5.0 版本提供了 stream_caster 或者通过 FFmpeg 拉流转推的方式实现这个过程。这里我用的是最直接的方式：在 SRS 容器里或宿主机上调用 ffmpeg，把 RTSP 流转推给 SRS。

5.2 宿主机方式：稳定且容易排查

我在宿主机上装一个 ffmpeg，然后用一条命令把摄像头流推给 SRS：

ffmpeg -rtsp_transport tcp -i "rtsp://用户名:密码@摄像头IP:554/Streaming/Channels/101" \
  -c:v copy -c:a aac -f flv rtmp://服务器IP:1935/live/cam_main

参数含义说明：

• -rtsp_transport tcp：强制走 TCP 拉取 RTSP 流，避免默认的 UDP 传输在跨网络时丢包花屏。
• -c:v copy：视频编码格式不变，不做转码，CPU 占用率很低。
• -c:a aac：如果摄像头没有音频，这个参数可以不加；如果有音频，转成 AAC 方便后续 HLS 播放。
• -f flv：输出格式必须是 FLV，SRS 才能通过 RTMP 接收。

这个方案的优点是 ffmpeg 进程和 SRS 相对独立，如果流中断了，单独重启 ffmpeg 进程就行。缺点是宿主机上多了个常驻进程，需要自己管理守护。

5.3 容器内方式：适合 all-in-one 部署

如果不想在宿主机装 ffmpeg，也可以把它打包到同一个容器里，或者单独起一个 ffmpeg 容器。我试过用 docker run 起一个包含 ffmpeg 的容器，然后挂载宿主机的入口脚本，效果也不错，但容器数量变多后管理起来稍微复杂。

更简单粗暴的方法是用 docker exec 进 srs 容器执行 ffmpeg，前提是官方镜像里带了 ffmpeg。我这里直接验证过，实际是可用的，但不建议每个任务都 exec 进入手动执行，重启容器后进程就没了。

综合下来，生产环境我更推荐宿主机 + systemd 维护 ffmpeg 进程的方式，配合日志输出，出问题能快速定位。

5.4 播放端验证 WebRTC 低延迟

摄像头 RTSP 流转推到 SRS 后，浏览器播放地址是：

webrtc://服务器IP/live/cam_main

在 SRS 内置播放器页面里，播放地址选择 WebRTC，填入 webrtc://服务器IP/live/cam_main，点击播放就能看到画面。WebRTC 的延迟通常在 0.3 到 1 秒之间，实际观感像看监控大厅的实时画面，几乎感觉不到延迟。

如果播放失败，优先检查：

1. UDP 8000 端口是否放行。
2. 是否是用 HTTPS 访问的播放页面。WebRTC 的获取摄像头/麦克风权限要求在安全上下文里，但如果只是播放远端流，HTTP 一般也能播放。如果播放器一直报错，可以试试换成 HTTPS 访问页面。
3. 摄像头视频编码是否是 H.264。如果是 H.265，WebRTC 播放大概率黑屏，需要在 ffmpeg 命令里加上 -c:v libx264 转码。

5.5 用 systemd 守护 ffmpeg 拉流任务

为了不让 ffmpeg 因为断网、摄像头重启等原因退出后没人管，我在宿主机上写了一个 systemd service 文件来守护它。

简单示例：

[Unit]
Description=FFmpeg RTSP to SRS
After=docker.service

[Service]
ExecStart=/usr/local/bin/ffmpeg -rtsp_transport tcp -i "rtsp://你的摄像头地址" -c:v copy -c:a aac -f flv rtmp://127.0.0.1:1935/live/cam_main
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

这样只要系统在，SRS 容器在，ffmpeg 挂了会自动拉起，最多丢失几秒画面。我用了好几个月，稳定性很让人放心。

6. 常见问题与排查技巧实录

6.1 Docker 启动失败与端口占用

SRS 容器起不来、瞬间退出，90% 是端口冲突或配置错误。

排查命令：

docker logs srs
docker ps -a

如果是端口被占用，会看到类似 “Address already in use” 的报错。这时候先用 ss -lntp | grep 1935 找到占用端口的进程，再决定是 kill 它还是换个端口。

如果确认端口没问题，但容器启动后立刻退出，多半是挂载的 srs.conf 有问题。SRS 对配置格式要求很严，少一个分号都会报错，而且启动失败时日志会指出具体行号。遇到这类问题，先把挂载配置去掉，用容器默认配置启动看能否正常运行，再逐一加回自定义配置项，缩小排查范围。

6.2 推流建立成功但播放黑屏

这个问题的出现频率极高。特征表现为：OBS 显示推流正常，SRS 日志有订阅记录，但播放器黑屏无画面。

常见原因：

• 视频编码为 H.265：浏览器对 H.265 的支持非常有限，WebRTC 和大部分 HTTP-FLV 播放器都不支持。改成 H.264 编码即可。
• 音频采样率或编码格式不兼容：比如 Opus 音频在 HLS 回放时可能出问题，建议转成 AAC。
• 播放器缓存问题：VLC 有缓存机制，WebRTC 页面如果长时间没有数据就自动断开。换一个播放器或清一下缓存试试。
• 浏览器兼容性：尽量用最新版本的 Chrome、Edge 或 Firefox，旧版本对 WebRTC 的支持有差异。

排查技巧：用 ffprobe 检查推流参数：

ffprobe -v quiet -print_format json -show_streams rtmp://127.0.0.1:1935/live/cam_main

看到 codec_name 是 h264 和 aac，基本上没问题；如果看到 hevc，基本上就是编码不支持的问题。

6.3 拉取镜像速度慢或拉取失败

这个问题在首装时最容易遇到。处理方案就是配置镜像加速器，这个在前文已经提到。如果已经配置了加速还是不行，可以检查一下 Docker DNS 配置：

{
  "dns": ["8.8.8.8", "223.5.5.5"]
}

改完同样需要重启 Docker 服务。如果某个镜像 tag 总拉取失败，可以尝试换一个相近版本的 tag，比如从 5.0 换成 5.0-beta2，或者用到底层操作系统的 stable tag。实测这种“绕路”方式在镜像源同步不完整时很有效。

6.4 公网访问时播放卡顿或连不上

如果服务器有公网 IP，且从外网播放卡顿，大多不是 SRS 的问题，而是带宽和路由的问题。先确认服务器上行带宽是否足够，一路 1080p 流至少需要 3 到 5 Mbps 的上行。

另一个隐藏的问题是多网卡或端口映射环境下的 IP 问题。SRS 在一些 NAT 环境下需要显式配置 IP，否则生成的播放地址不对。解决办法是在 rtc_server 和 http_server 配置里手动指定对外 IP：

rtc_server {
    enabled on;
    candidate 你的公网IP;
}
http_server {
    enabled on;
    listen 8080;
    dir ./objs/nginx/html;
}

这个配置在云服务器和家用宽带内网穿透场景下尤其重要。我遇到过不少明明端口都通了，但 WebRTC 就是连不上，最后发现是 candidate 没配置，SRS 返回给浏览器的候选地址还是内网 IP，浏览器当然连不上。

6.5 其他常见问题速查表

问题现象	大概率原因	解决建议
容器启动后 8080 端口无法访问	HTTP server 未开启	确认配置里 http_server enabled on
能推流但 HLS 文件不生成	hls 配置未生效	检查 vhost 里 hls enabled on，确认 hls_path 目录权限
摄像头的流能拉取，但画面马赛克	RTSP 传输方式丢包	在 ffmpeg 命令里加 -rtsp_transport tcp
WebRTC 播放断断续续	UDP 端口未放行或链路丢包	确认 UDP 8000 端口放行，检查服务器带宽
重启服务器后 SRS 没自动运行	容器没有配置 restart 策略	用 docker compose 时加上 restart: unless-stopped
内存占用越来越高	录像或日志没有轮转	配置 log 文件大小限制和保留时间，定期清理切片

7. 最后再分享几个我自己觉得好用的配置习惯

部署 SRS 用 Docker 这件事本身不难，但要让服务长期稳定跑，光把容器拉起来还不够。我把自己实际维护中觉得最有价值的几个习惯写在这里，供大家参考。

第一，所有配置文件和录像目录都挂载到宿主机统一管理，不要在容器里手工改文件。容器一删，里面的内容全部消失，挂载出来之后哪怕镜像升级也心里有底。第二，每次修改 srs.conf 之前先备份一份带日期后缀的版本，比如 srs.conf.20250101，改坏了能秒回滚。第三，日志要开起来但不要无限增长，SRS 配置里有 log_tank 和 log_file 相关参数，设置日志轮转或者定期清理脚本，避免磁盘被日志撑爆。

另外，如果可能的话，尽量把 Docker 升级到支持 compose v2 的版本，用 docker compose 而不是 docker-compose，管理体验好很多，而且 compose 文件里可以一次性声明端口、挂载、重启策略，迁移时只需要把整个目录复制到新机器，执行 docker compose up -d 就行。

我最初用 Docker 部署 SRS，只是想着省去编译的麻烦，结果发现在后续的版本升级、配置回滚、多机迁移上，容器化带来的收益远超预期。这套方案已经在我自己的项目和几个朋友的服务器上稳定跑了很长时间，希望这篇文章也能帮你少走点弯路。