我最早接触 go2rtc 是在做家庭监控整合的时候。当时家里同时有海康的RTSP摄像机、一个USB摄像头接在小主机上，还有一台旧手机装了个IP摄像头App，三个设备三种取流方式，想在同一个界面统一查看，还得让 Home Assistant 能直接调用画面，折腾了不少方案，最后落到 go2rtc 上用 Docker 一部署，整个事情就顺了。这篇文章就把我自己的部署路线、配置细节和踩过的坑完整写出来，给想用 Docker 搭建摄像头多协议流媒体平台的朋友一个可以直接抄作业的参考。

1. 整体思路：go2rtc 解决的是什么问题

1.1 摄像头取流为什么这么乱

做过监控接入的人应该都有同感：摄像头厂家各玩各的，海康走 RTSP 还分老协议新协议，大华有自己的规则，宇视、雄迈、TP-LINK 取流地址格式都不一样。更麻烦的是，不同消费端需要的协议又不一样——浏览器原生播放倾向于 WebRTC 或 MSE，手机端低延迟要看 WebRTC，低带宽环境适合 HLS，旧系统又只认 MJPEG。你不可能让摄像头直接输出这么多协议。

go2rtc 这个名字全称是 Go Real Time Codec，核心定位就是一个流媒体网关。它负责从各种源把视频流拉进来，再对外提供多种协议输出。换句话说，摄像头只需要能吐出一个 RTSP 流，go2rtc 就能把它转成 WebRTC、HLS、MJPEG、LL-HLS，甚至原生 RTSP/RTMP 转发。你不需要逐个设备去配编码、调协议，所有转换和分发集中在 go2rtc 这一层完成。

1.2 为什么推荐用 Docker 部署

go2rtc 本身是一个 Go 语言写成的单二进制程序，官方也提供 Linux、Windows、macOS 的预编译包，你直接下载运行也能用。但放到实际项目里，尤其是要长期跑监控、中转多路流的话，我强烈建议走 Docker 部署，原因有三点。

第一，依赖和运行环境完全隔离。go2rtc 虽然依赖少，但它经常要和 ffmpeg 配合使用，ffmpeg 的版本、编译参数、硬件加速驱动这些一旦在宿主机上乱掉，查起来很头疼。Docker 镜像把这些都打包好了，容器内是什么环境就是什么环境。

第二，升级和回滚非常干净。官方镜像更新很频繁，新版本可能修了 WebRTC 的 bug 或者加了对某类摄像头的适配。用 Docker 的话，换 tag 重启容器就能升级，不满意了切回旧 tag 也就一行命令的事，宿主机上不会留下任何残留文件。

第三，端口和资源管理清晰。一个 NAS 或小主机上往往同时跑着 Home Assistant、MySQL、Redis 一大堆容器，Docker 的端口映射、存储卷、网络管理能让 go2rtc 变成一个标准化的服务，而不是又多一个占用乱七八糟的进程。

1.3 这套平台适合谁用

如果你是以下情况之一，go2rtc 这套方案基本是刚需：

• 家里有多路网络摄像头，品牌还不统一，想在一个统一界面里看所有画面；
• 在用 Home Assistant 做智能家居，希望把摄像头画面无延迟地接到仪表盘上；
• 想把监控流接入到 Frigate 做人体识别，但又想保留 WebRTC 低延迟预览；
• 需要在公网环境下远程查看监控，但不方便直接暴露 RTSP 端口；
• 只是想在家里局域网内多设备（手机、平板、电视）同时看监控，对 App 绑定厂家无好感。

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

2.1 硬件和系统要求

go2rtc 本身非常轻量，纯转发模式下 CPU 和内存占用都很低，哪怕是一个树莓派 4B 或者 J4125 的小主机都能同时处理十几路 1080P 的流。真正吃性能的是转码，如果你需要把 4K 摄像头流实时转成 1080P 输出，那就得考虑 CPU 性能或者显卡硬件加速。前期测试阶段，一台 2GB 内存的 x86 小主机完全够用。

系统方面，只要支持 Docker 就行。Linux 服务器用 Docker Engine 或者 Docker Compose 插件，Windows 上用 Docker Desktop，群晖和威联通 NAS 也能通过套件或 Container Manager 直接跑。需要注意的一点是，容器是 linux/amd64 还是 linux/arm64 架构，官方镜像自动适配，但 macOS 的 Apple Silicon 用户记得检查 Docker Desktop 的镜像平台设置，避免拉错架构。

2.2 端口规划

go2rtc 默认监听 1984 端口，Web 管理界面和所有流媒体输出都走这个端口。如果你没有和其他服务冲突，就用默认的 1984，后续配置引用的时候也方便记忆。如果你的公网端口需要映射，可以在路由器上把外网的一个端口（比如 9841）转发到内网主机的 1984，这样外部访问 Web 管理界面就输入 http://公网IP:9841 。

这里还要考虑 UDP 端口的问题。如果后面要接 WebRTC，浏览器播放的时候需要 UDP 传输媒体数据。go2rtc 本身使用 ICE 协商，大多数局域网环境下直接就能通，公网环境就复杂一些，建议在路由器上开放一段 UDP 端口范围（比如 50000~50100）并映射到容器，具体配置放到后面 WebRTC 排障部分详细说。

2.3 提前整理摄像头 RTSP 地址

在部署前，我建议先把你要接入的每个摄像头的 RTSP 取流地址整理好，存到一个文本文件里。这个动作看着简单，实际能省很多后面反复改配置的时间。各家摄像头的地址格式大致如下：

品牌	RTSP 地址示例
海康威视	rtsp://用户名:密码@IP:554/h264/ch1/main/av_stream
大华	rtsp://用户名:密码@IP:554/cam/realmonitor?channel=1&subtype=0
TP-LINK	rtsp://用户名:密码@IP:554/stream1
宇视	rtsp://用户名:密码@IP:554/live
通用 ONVIF 设备	rtsp://用户名:密码@IP:554/onvif1

地址里的用户名密码是摄像头的 Web 管理账号，不是 ONVIF 服务账号，很多人在这里搞混。如果提示认证失败，先进摄像头管理后台确认 RTSP 功能是否打开、RTSP 认证方式默认是什么，一般改成 Digest 或 Basic 都能被 go2rtc 兼容。主码流和子码流也建议各记一条，默认接入用子码流可以大幅降低带宽和转码压力。

3. Docker 部署实操：把 go2rtc 跑起来

3.1 使用 docker run 快速启动

部署 go2rtc 的官方镜像是 alexxit/go2rtc ，GitHub 主仓库是 AlexxIT/go2rtc ，注意别拼成别的镜像。最基础的启动命令如下：

docker run -d \
  --name go2rtc \
  --restart unless-stopped \
  -p 1984:1984 \
  -v /opt/go2rtc:/config \
  alexxit/go2rtc:latest

这条命令做了四件事：容器命名为 go2rtc，设置了开机自动重启策略，把宿主机的 1984 端口映射到容器 1984，把宿主机的 /opt/go2rtc 目录挂载为容器的 /config 配置目录。挂载之后，go2rtc 的配置文件 go2rtc.yaml 就会自动生成在这个目录里，后面修改配置不需要进容器内部，直接在宿主机上编辑就行，改完重启容器生效。

如果你不想用宿主机目录，用 Docker 命名卷也完全可以：

docker run -d \
  --name go2rtc \
  --restart unless-stopped \
  -p 1984:1984 \
  -v go2rtc_config:/config \
  alexxit/go2rtc:latest

命名卷的好处是 Docker 统一管理，不太容易误删文件，但查看和修改配置会比目录挂载麻烦一点，需要借助 docker exec 或者 docker cp 进容器操作。我自己的习惯是目录挂载，因为配置改起来最直接，配合 VS Code 的 Remote 插件甚至能直接在宿主机上编辑。

3.2 使用 docker-compose 管理配置

如果和我一样在主机上已经跑了好几个容器，用 Compose 统一管理会舒服很多。在宿主机上建一个 go2rtc 目录，里面放一个 docker-compose.yml 文件，内容如下：

services:
  go2rtc:
    image: alexxit/go2rtc:latest
    container_name: go2rtc
    restart: unless-stopped
    ports:
      - "1984:1984"
      - "8554:8554"
      - "8555:8555/udp"
    volumes:
      - ./config:/config
    environment:
      - TZ=Asia/Shanghai

这里比 docker run 多映射了 8554 和 8555 端口。8554 是 go2rtc 的 RTSP 输出端口，8555 是 WebRTC 的 UDP 端口，如果一开始没规划好，后面想开这两个功能还得重新创建容器，不如部署的时候直接留好。

注意我给容器加了时区环境变量，否则 go2rtc 日志里的时间戳会显示成 UTC 时间，排查问题的时候自己对不上时间会很烦躁。启动命令：

mkdir -p /opt/go2rtc/config
cd /opt/go2rtc
docker compose up -d

启动后访问 http://服务器IP:1984 ，能看到 go2rtc 的 Web 管理界面就说明服务已经正常工作了。这个界面不止是状态展示，它本身就是一个可以添加流、预览画面的工具，很多调试工作可以直接在这里完成。

3.3 几个容易忽略的容器配置细节

先说说日志问题。go2rtc 在默认情况下会把日志打到 stdout，Docker 会自动收集。如果你用 docker logs go2rtc 看不到什么有效信息，可以在启动命令里加 --log-opt max-size=10m --log-opt max-file=3 限制日志文件和大小，避免长时间跑监控后日志占满磁盘。这个参数在 Compose 里的写法是：

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

再说网络模式。默认 bridge 网络模式下，容器内的 go2rtc 访问局域网摄像头 IP 是通过 NAT 出去的，大部分场景没问题。但如果你在宿主机上启用了严格的防火墙，或者跑在 NAS 的容器虚拟网络里，可能出现容器能启动但拉不到摄像头流的情况。这时候先别急着怀疑 go2rtc，可以先进入容器测试一下网络连通性：

docker exec -it go2rtc sh
ping 192.168.1.10

如果 ping 不通但宿主机能 ping 通，那就是容器网络的问题。最简单的方案是把网络模式改成 host ：

network_mode: host

host 模式下容器直接共享宿主机网络栈，端口不用映射、UDP 也不用额外映射，很多跑在路由器或 NAS 上的场景反而更省事。缺点是你没办法像 bridge 模式那样精细控制端口，如果宿主机上的端口资源紧张，还是老老实实用 bridge 加端口映射。

3.4 Docker Desktop for Windows 用户的特别提醒

Windows 用户用 Docker Desktop 部署 go2rtc 也是完全可行的，唯一的坑在于 Docker Desktop 的 VM 网络和 Windows 防火墙。我遇到的典型情况是容器起来了，浏览器访问 http://localhost:1984 没问题，但手机在同一局域网却打不开这个地址。这就是 Windows 防火墙拦截了 Docker 的虚拟网卡流量导致的，去防火墙设置里放行 Docker Desktop 相关程序，或者直接为 1984、8554、8555 添加入站规则，问题就能解决。

另外 Windows 下路径挂载要注意格式， ./config 在 PowerShell 和 CMD 里的解析有差异，建议写成绝对路径或者显式的 Windows 路径格式：

volumes:
  - D:/docker/go2rtc/config:/config

4. 配置 go2rtc：从拉流到多协议输出

4.1 配置文件的结构和加载机制

go2rtc 启动后会在 /config 目录下生成 go2rtc.yaml 。这个文件是核心配置，里面可以定义流源、API 密钥、WebRTC 端口、日志级别、录制定时等。每次修改完要重启容器才会生效，重启后 go2rtc 会重新加载配置，并自动重连所有配置的摄像头流。

基础配置文件长这样：

log:
  level: info

api:
  listen: ":1984"

webrtc:
  listen: ":8555"

rtsp:
  listen: ":8554"

streams:
  front_door:
    - rtsp://admin:password@192.168.1.64:554/h264/ch1/main/av_stream
  backyard:
    - rtsp://admin:password@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0

每个流源的名字（如 front_door 、 backyard ）是你自定义的，后面在 Web 界面、Home Assistant 或 API 调用里都用这个名字来引用。名字建议用英文小写加下划线，避免中文和特殊字符带来的兼容性问题。

4.2 接入多协议源：不止是 RTSP

go2rtc 的支持范围其实比很多人以为的广。除了最常见的 RTSP，它还能直接拉取 RTMP 流、HTTP-FLV 流、MJPEG 流，甚至支持本地文件、USB 摄像头（通过 v4l2 或者 Windows 的 DirectShow），还支持把另一个 go2rtc 实例的流作为源。

我自己就在一个项目里同时接了三种源：

streams:
  main_camera:
    - rtsp://admin:password@192.168.1.64:554/h264/ch1/main/av_stream
  usb_cam:
    - ffmpeg:v4l2:/dev/video0
  phone_camera:
    - rtsp://192.168.1.100:8554/phone

usb_cam 这一行用 ffmpeg: 前缀表示让 go2rtc 调用内置 ffmpeg 去读取本机 /dev/video0 设备，这就把 USB 摄像头也纳入了统一管理。手机端装一个支持 RTSP 输出的 IP 摄像头 App，然后局域网内通过 go2rtc 的 RTSP 输出端口访问，也能变成监控源之一。

这里补充一个关键点：go2rtc 的流源本质上是一个 URL 列表，当你配置了多个 URL 时，它不是同时拉多路来做负载均衡，而是按顺序尝试，只有当前一个断开时才会自动尝试下一个。所以如果你有主备两个摄像头源，可以把它们都写在同一个流名下，这样主源挂了会自动切换到备用源：

lobby:
  - rtsp://admin:password@192.168.1.64:554/stream1
  - rtsp://admin:password@192.168.1.65:554/stream1

4.3 输出协议：一键获得 WebRTC、HLS、MJPEG

配置好流源后，你不需要额外配置，go2rtc 会自动为每个流提供多种协议的访问地址。假设你的服务地址是 192.168.1.100:1984 ，流名是 front_door ，那么：

• WebRTC 播放：直接在 Web 管理界面点击流名，go2rtc 会用 WebRTC 推流给浏览器，延迟约 0.2~0.5 秒，是局域网预览体验最好的方式；
• HLS 播放： http://192.168.1.100:1984/api/stream.m3u8?src=front_door ，适合 iOS 原生播放器、电视端 App；
• LL-HLS：把上面 URL 换成 stream.m3u8 并使用支持低延迟 HLS 的播放器即可；
• MJPEG： http://192.168.1.100:1984/api/stream.jpeg?src=front_door ，适合嵌入式页面、老旧浏览器；
• RTSP 转发： rtsp://192.168.1.100:8554/front_door ，可以给外部 NVR 或支持 RTSP 的播放器用。

如果你不需要某个协议，比如不想开放 RTSP 转发端口，可以在配置文件里不启用 rtsp 段，甚至可以通过 api 接口和鉴权机制限制访问。默认情况下 go2rtc 是非常开放的，这是方便调试的设计，生产环境务必加鉴权，我后面会单列一节来说安全加固。

4.4 设置 API 鉴权

go2rtc 支持通过基本认证来保护 API 访问。在 go2rtc.yaml 中加入一段用户配置：

api:
  listen: ":1984"
  username: admin
  password: your_strong_password

设置后，Web 管理界面和所有通过 1984 端口访问的流地址都需要输入用户名密码，如果不加认证，任何能访问你端口的人都能看到你所有摄像头画面，这就是相当于把家门钥匙挂在大门上了。设置完密码后，原先那种直接粘贴 http://IP:1984 就能预览的方式会变成弹窗认证，Home Assistant 集成时也需要在配置里写入对应账号。

4.5 用前端 WebRTC 预览页快速验证

配置好之后，直接在浏览器打开 Web 管理页面，左侧会列出所有配置的流源名称，点击任意一个流，go2rtc 就会自动协商 WebRTC 连接并开始播放。如果画面出不来，先注意浏览器是否允许自动播放，再检查 WebRTC 所需的 UDP 端口是否可达。这个界面本身就是一个超好用的调试工具，设置完流的加入、删除、改名都可以实时操作并立即看到结果。

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

5.1 容器启动失败：日志里没有有效错误

docker run 之后容器秒退， docker logs go2rtc 又只看到几行启动信息，这种情况十有八九是配置文件里含有 go2rtc 不允许的格式。最常见的是 YAML 缩进错误，尤其当你用 Tab 键做缩进的时候。go2rtc 对 YAML 的语法要求比较严格，配置出错它不会像某些程序那样自动忽略，而是直接退出。

排查方法是先在宿主机上用现有的 YAML 工具或者 docker run --rm 临时进入容器验证配置内容，但更推荐的做法是把配置文件复制一份到本地，用支持 YAML 语法检查的编辑器打开，或者直接跑 python3 -c "import yaml; yaml.safe_load(open('go2rtc.yaml'))" 检查语法。排除语法问题后，再确认配置项的名称是否写对，比如 streams 下面不支持用大写字母， api 段的 listen 端口不能和 webrtc 段的 listen 端口冲突。

5.2 拉不到摄像头流：先分清楚是网络问题还是协议问题

我见过太多人一拉不到流就怀疑 go2rtc，实际上问题往往出在摄像头侧。判断方法是先做直接测试：在宿主机上用 VLC 或者 ffprobe 直接播放摄像头的 RTSP 地址：

ffprobe rtsp://admin:password@192.168.1.64:554/h264/ch1/main/av_stream

如果宿主机能出流而 go2rtc 容器内不行，那基本是容器网络到摄像头不通，回到前面说的网络模式排查，换个 network_mode: host 试试。如果宿主机也不行，就要去摄像头后台检查 RTSP 服务是否开启、账号密码是否正确、IP 是否变更。

另一种常见情况是 RTSP 地址里的密码包含特殊字符，比如 @ 、 # 、 : 等，这些字符在 URL 里会被直接解析错误，导致认证失败。解决办法是把密码做 URL 编码，或者在配置流源时不使用带密码的 URL，而是使用 go2rtc 支持的用 # 分隔的源格式来显式指定用户名密码。我自己的实操是尽量让摄像头账号密码简单一点，专为监控设置一个简单密码也是可以接受的。

5.3 WebRTC 能出流但画面不流畅

WebRTC 播放偶尔卡顿，先打开 Web 管理页面的调试信息看看延迟和丢包率。局域网内如果丢包率偏高，检查一下 Wi-Fi 信号质量，5GHz 频段比 2.4GHz 稳定得多，摄像头如果支持有线网口，尽量用网线连接。

如果你在同一时间有多个浏览器标签页预览同一个流，go2rtc 会为每个新连接单独分配一路 WebRTC 会话，这可能会让性能不足的 NAS 或者小主机压力大增。我试过在一个树莓派上同时开三个标签页预览 1080P 主码流，CPU 直接飙到 80% 以上。解决方案是统一用子码流作为预览源，或者通过 go2rtc 的 webrtc.video 参数限制输出分辨率。

5.4 RTSP 转发到外部 NVR 显示密码错误

有时你配置了 go2rtc 的 RTSP 输出端口，把 rtsp://IP:8554/front_door 填到 NVR 或录像机里却提示认证失败。这是因为 go2rtc 的 RTSP 转发默认不带认证，但是部分 NVR 在添加通道时强制要求填写用户名密码，即使源本身是公共流。处理方式是在 go2rtc 配置中开启 RTSP 鉴权：

rtsp:
  listen: ":8554"
  username: viewer
  password: viewer_pass

这样 NVR 添加通道时，用这个账号密码就能正常认了。这个账号和 Web API 的账号可以不同，专门给下游设备用，权限控制也更清晰。

5.5 修改配置文件后不生效

这个是特别新手向的问题。修改了 go2rtc.yaml 后，直接刷新浏览器页面发现流还是旧的，以为是没生效。实际上 go2rtc 的配置是启动时加载的，不执行容器重启就不会重新读取。正确操作是：

docker exec go2rtc kill -HUP 1

或者更简单粗暴一点：

docker restart go2rtc

我个人倾向于 docker restart ，因为配置重载后有没有报错一眼就能在日志里看到。用 HUP 信号重载虽然不用重启容器，但如果有配置错误，容器不会退，你还不容易发现。

6. 扩展玩法：从单一监控到家庭媒体中枢

6.1 接入 Home Assistant 实现低延迟卡片

go2rtc 最流行的用法之一是作为 Home Assistant 的摄像头后端。在 Home Assistant 的 configuration.yaml 里先配置 go2rtc 集成：

stream:
  go2rtc:
    url: http://192.168.1.100:1984

然后在仪表盘的前端用 picture-entity 或者 webrtc-camera 卡片直接展示 go2rtc 流。这样操作后，Home Assistant 前端预览的延迟能从传统 HLS 方案的 2~5 秒降低到 WebRTC 的不到 1 秒，门铃响了你按门铃后几乎能实时看到是谁在门口。

如果你的 Home Assistant 是跑在同一个 Docker 网络里，go2rtc 容器和 Home Assistant 容器可以通过容器名互相访问。Compose 里同时定义两个服务，go2rtc 和 homeassistant 在同一个自定义网络上，Home Assistant 配置里直接写 http://go2rtc:1984 即可，这样不需要依赖局域网 IP，IP 变了也不影响。

6.2 与 Frigate 配合做 AI 识别和录像

Frigate 是另一个很火的 NVR 应用，它的视频源就是从 go2rtc 获得的。Frigate 通过 RTSP 从 go2rtc 拉取子码流做对象检测，同时从 go2rtc 拉取主码流用于录制。这种架构的好处是 go2rtc 统一管理摄像头连接，Frigate 只管消费流，两者互不干扰。

在实际部署中，我建议给 Frigate 单独建一个只读的子码流源，避免因为 Frigate 的重连逻辑把 go2rtc 的源连接搞乱。具体配置就是在 go2rtc.yaml 里同名流下面先写主码流、再写子码流，Frigate 配置里指定 sub 为子码流源地址。

6.3 远程访问的安全建议

远程访问 go2rtc 有两种常见路线，一种是直接路由器端口映射把 1984 暴露到公网，另一种是走反向代理加 TLS 访问。我的建议是不要裸奔端口。哪怕你设置了账号密码，go2rtc 的 RTSP 和 WebRTC 数据还是没有加密的，公网传输等于说把家里的监控画面放到了明网上。

更稳妥的做法是在路由器或内网主机上用反向代理（比如 Nginx 或 Caddy）把 rtsp 、 api 前面加一层 TLS，把第一个请求 HTTPS 化；WebRTC 流则强烈建议通过内部的虚拟组网工具接入，不要让 UDP 端口直接暴露公网。如果不太熟悉这套，至少要保证 go2rtc 的 Web 界面不是默认密码，并且不转发 RTSP 端口 8554 到公网，RTSP 明文流量传到公网等于裸奔。

6.4 录像与回放：go2rtc 做不了但别慌

go2rtc 本身不承担录像存储，它只负责流的接入、转换和分发。但很多人在部署完 go2rtc 后自然会问：我的录像存哪？这就轮到前面提过的 Frigate 或者其他 NVR 系统出场了。Frigate、Scrypted、Shinobi 都能和 go2rtc 无缝配合，go2rtc 输出 RTSP 流给它们录制，它们负责保存、索引和回放。

如果你只是想简单连续录几天，不想搭复杂系统，也可以用 ffmpeg 定时从 go2rtc 取流存文件：

ffmpeg -i rtsp://localhost:8554/front_door -c copy -f segment -segment_time 3600 -strftime 1 "/mnt/recordings/%Y%m%d_%H%M%S.mp4"

这段命令每小时生成一个文件， -c copy 直接拷贝流不转码，CPU 占用可以忽略。搭配 crontab 或者 Docker 的调度任务就能做成个简陋但可用的录像方案。

6.5 多 go2rtc 实例级联

如果你有多栋房子或者多个网段，不同位置的摄像头不能直接互通，可以在每个点位部署一个 go2rtc 实例，然后在中心节点把远端实例的流当作源拉回来：

streams:
  remote_camera:
    - rtsp://remote_go2rtc_ip:8554/front_door

这种方式对带宽要求低、配置清晰，而且远端实例挂了不影响中心节点其他流。做级联的时候注意给每个实例配置不同的 api.listen 端口，避免端口冲突。

7. 从部署到稳定的几个实操心得

最后分享几个我在实际使用中沉淀下来的细节，这些东西文档里写得不多，但对稳定运行影响很大。

第一，摄像头时间同步非常重要。如果你后面要接 Frigate 或 NVR 做检测和录像，摄像头本地时间不准会导致事件时间戳全乱。go2rtc 做不了时间同步，但你可以在路由器上统一启用 NTP 服务，或者在摄像头后台手动设置 NTP 服务器。这个动作和 go2rtc 本身无关，却直接影响整套平台的可用性。

第二，子码流是稳定运行的功臣。曾经我把所有摄像头主码流都接到了 go2rtc，四路 4K 摄像头同时拉流，小主机内存和 CPU 都吃紧，预览体验也很差。后来改成所有要长时间预览的源都指向子码流，只在需要看清细节时手动切换主码流，系统立刻恢复流畅。配置流的顺序建议把子码流放前面、主码流放后面：

gate:
  - rtsp://admin:pass@camera/stream2
  - rtsp://admin:pass@camera/stream1

第三，合理利用 Web 管理页面对所有流做一次健康检查。go2rtc 的界面会显示每个流的状态，如果某个摄像头离线，对应流的连接次数和错误日志会急剧增加。我每隔一段时间就会打开页面看一遍，同时对日志做一次 docker logs go2rtc | grep -i error 的抽查，大多摄像头小毛病都能提前发现。

第四，注意版本更新的节奏。go2rtc 迭代挺快，新功能和新协议的支持都集中在最新版。但如果你当前跑得很稳定，不要一看到 new tag 就马上更新，最好先在测试环境验证一遍，或者直接拉上一次固定的 tag 而不是 latest 。我自己的习惯是固定一个小版本，比如 alexxit/go2rtc:v1.9.7 ，确认没问题后隔几个月再评估升级一次。

如果你是想快速解决"一堆摄像头没法统一看"的问题，按照文章第二、三节的内容把容器跑起来，再把第四节的流配置填进去，基本半小时内就能看到画面了。后面的扩展和优化可以边用边做，go2rtc 这支架构自由度非常高，从几十块钱的 USB 摄像头到专业 NVR 都能纳入同一套体系，我自己现在的主页早就把监控画面和智能家居卡片放在一起了，用一个页面就能看到门外、后院、阳台所有角落，这种体验确实值得折腾一番。