Docker部署go2rtc：统一多品牌摄像头视频流的流媒体网关实战

先说说我为什么折腾这个。家里和工作室加起来七八个摄像头，海康、大华、萤石还有几个杂牌，每个牌子一个APP，想看的时候得挨个打开。有一回半夜手机弹窗说门口有动静，我打开对应APP等了快半分钟画面还没出来，等人影消失了才看到个尾巴。那之后我就琢磨着搞一个统一平台，把多路摄像头都收进去，在一个页面里看。试过几套方案，最后留在go2rtc上。它是一个用Go写的轻量级流媒体网关，核心思路是把不同来源的视频流（RTSP、RTMP、本地文件都行）统一收进来，再按需转成你想要的协议吐出去。配合Docker部署，几分钟就能把一套多协议流媒体平台跑起来。这篇文章写给同样被多品牌摄像头折磨的朋友，也记录一下我自己踩过的坑。

1. go2rtc是什么？为什么选它来统一摄像头视频流

1.1 从"多个APP来回切"到"一个页面看全部"

先说痛点。普通人家里装两三个摄像头，用原厂APP也还行，但一旦数量上来、品牌还不一样，问题就来了：海康的录像在A APP里，大华的报警在B APP里，萤石的回放在C APP里，想看全貌就得来回切。更麻烦的是，想把摄像头接进Home Assistant、Frigate、群晖Surveillance Station这类第三方系统，很多平台对单一协议（比如RTSP）支持得很好，但对各家私有协议就束手无策了。

go2rtc解决的就是这个中间层问题。它是一个独立运行的流媒体网关服务，你不必去改任何摄像头的配置，只需要让go2rtc拿到摄像头的RTSP地址，它就能统一管理这些视频流，并对外提供统一的接入能力。相当于所有摄像头先汇聚到go2rtc这一个节点，再由go2rtc按客户端的需求分发出去。这个设计思路和生活里“换一个中控遥控器”差不多，摄像机还是各干各的，但查看入口只留一个。

我实际用下来还有个额外收获：排查问题方便了。以前摄像头连不上，我得分品牌去找原因，现在所有视频流入口都在go2rtc，哪一路断了、为什么断，一个页面加一行日志就能看到。对于设备多、品牌杂的环境，这种“统一入口”本身就是最大的价值。

1.2 go2rtc的核心能力与协议生态

go2rtc支持的能力比我预期宽不少。它的名字里有WebRTC，所以最拿手的就是WebRTC低延迟播放，浏览器打开页面直接看，延迟能做到几百毫秒级别，这在摄像头实时预览场景下非常实用。同时它也兼容RTSP、RTMP、HLS、MJPEG、MP4等多种协议，既可以拉流也可以推流，还能把一路视频流同时以多种协议输出给不同端。

举个例子，我在go2rtc里加了一路海康摄像头，之后可以同时做三件事：电脑浏览器用WebRTC看实时画面，延迟基本无感；手机用HLS地址在不稳定网络下慢慢缓冲播放，兼容性好；家里一个小程序直接抓MJPEG截图做门铃提示。这些都基于同一路源流完成，不需要为每个场景单独部署一套服务。如果你对延迟不敏感、对兼容性要求高，HLS最稳；如果要实时看门口来人，WebRTC的优势就非常明显。

另外要赞一下go2rtc对编码的容忍度。它默认走不转码直接转发的路子，只要源端编码在目标播放端能解出来，就尽量不额外消耗CPU。H.264、H.265都能通过不同播放链路适配。当然这也带来一个限制，某些情况下需要播放端或者摄像头端配合编码格式，这点我在第4章会展开聊。

1.3 为什么用Docker而不是直接装在主机上

直接运行go2rtc也不难，官方有编译好的二进制，下载下来一条命令就能跑。但我最终选择Docker部署，原因有三点。

第一，安装干净。Go写的程序虽然依赖少，但总归要在系统里放二进制、配置、日志，时间长了容易弄乱。用Docker容器把程序和数据隔离在固定目录，卸载时直接删容器和挂载目录就行，不留垃圾。

第二，升级方便。go2rtc迭代不算慢，隔几个月就有新版本。如果用二进制部署，每次都要下载、停服务、替换文件，出问题还得回滚。用Docker只需要改一下镜像tag，重启容器就完事，旧版本通过镜像tag保留着，随时能切回去。

第三，迁移友好。我在一台小主机上部署好了配置，想迁到另一台机器上，直接把 docker-compose.yml 和配置目录复制过去，docker compose up -d就完成了。家里也好、工作室也好，只要Docker能跑，这套部署方式就是一致的。后续如果你想接Home Assistant、Frigate这些同样容器化的服务，网络打通也顺理成章。

2. Docker部署go2rtc的完整过程

2.1 部署前需要想清楚的几件事

动手之前，先花两分钟确认环境，省得后面来回折腾。

第一，Docker版本。理论上Docker 20.10以上都行，我自己是在Ubuntu 22.04上用Docker 24系列部署的，跑得很稳。如果还在用老版本Docker，建议先升级，避免个别镜像特性和compose语法不支持。

第二，端口规划。go2rtc默认用1984端口提供Web界面和API，同时需要UDP 8555端口做WebRTC媒体传输。如果你的服务器、软路由、NAS已经占用了这两个端口，要么换端口，要么用host网络模式。我建议尽量保持1984和8555不变，因为go2rtc很多内置调用、第三方集成（比如Home Assistant的go2rtc集成）都默认这两个端口，改动后还得去各处适配，划不来。

第三，摄像头网段和RTSP账号。go2rtc要能拉到摄像头视频流，前提是它和摄像头之间网络互通。如果Docker跑在软路由上，而摄像头在另一个VLAN，需要在网关上放行相关流量。摄像头端的RTSP用户名密码也要提前准备好，后面配置都会用到。

我把经常需要确认的信息整理成一张表，部署前对照打勾就行：

2.2 Docker命令行部署演示

最简单的跑法，一条命令：

mkdir -p /opt/go2rtc && cd /opt/go2rtc touch go2rtc.yaml docker run -d --name go2rtc --restart=unless-stopped \ -p 1984:1984 \ -p 8555:8555/udp \ -v /opt/go2rtc/go2rtc.yaml:/config/go2rtc.yaml \ alexxit/go2rtc:latest

拆解一下这条命令里每个参数的含义。-p 1984:1984是把容器的1984端口映射到宿主机，Web界面和API都走这个端口。-p 8555:8555/udp映射WebRTC需要的UDP端口，少了这个，你能打开页面但大概率连不上WebRTC实时流。-v /opt/go2rtc/go2rtc.yaml:/config/go2rtc.yaml是挂载配置文件，go2rtc在容器里的默认配置路径就是/config/go2rtc.yaml，这样配置在宿主机上一份，备份、修改都方便。

执行完成后，用下面的命令确认容器状态：

docker ps | grep go2rtc docker logs go2rtc

日志里如果出现类似server listening on :1984的输出，说明服务已经起来了。这时候在浏览器打开http://服务器IP:1984，能看到go2rtc的Web界面，页面虽然简陋但功能都在：左侧是源列表，右侧是播放预览。如果你是在群晖、威联通、飞牛这类NAS上部署，方法也一样，只是挂载路径按NAS的目录结构来填就好。

第一次跑起来的时候，我在屏幕前愣了几秒，因为真没想到会这么顺。浏览器打开就能看到一个可以点击播放的控制台，这对一个部署过程来说，已经是相当友好的体验了。

2.3 用docker-compose管理更省心

虽然一条docker run能跑起来，但我个人更推荐docker-compose，尤其当你后面还要加Frigate、Home Assistant容器时，compose可以统一管理。我的compose文件长这样：

services: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc restart: unless-stopped ports: - "1984:1984" - "8555:8555/udp" volumes: - ./go2rtc.yaml:/config/go2rtc.yaml

在/opt/go2rtc目录下保存为docker-compose.yml，然后执行docker compose up -d即可。这里有个小细节：restart: unless-stopped保证宿主机重启后容器自动拉起。摄像头监控这种事，最怕断电后还要手动启动服务，我吃过一次亏，所以这个参数一定会加。

如果你的Docker宿主在NAT后面，或者WebRTC一直连不通，可以把网络模式改成host再试：

services: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc restart: unless-stopped network_mode: host volumes: - ./go2rtc.yaml:/config/go2rtc.yaml

host模式下容器直接共享宿主机网络栈，没有端口映射这一层，优点是能降低NAT问题的影响，缺点是1984和8555必须确认没被占用。普通家庭环境建议先用端口映射方式，不行再换host，这样最省心。

2.4 配置文件怎么写

go2rtc的配置是一个典型的YAML文件，核心就是streams字段。最简单的配置：

streams: door: rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101 backyard: rtsp://admin:password@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0

冒号左边是流的名字，右边是源地址。名字最好用有意义的英文，比如door、backyard、driveway，因为后面播放URL、接入Home Assistant时都靠这个名字来引用对应摄像头。你可以直接在Web界面的设置里改配置并保存，也可以改了宿主机上挂载的yaml文件后重启容器。我习惯直接编辑宿主机文件，因为可以纳入版本管理，出问题回滚也快。

配置文件里还可以设置日志级别等全局参数，默认值基本够用。这里要特别注意一点：go2rtc本身没有强制密码保护，如果它跑在公网可达的环境，强烈建议在前面挂一层反向代理加basic auth，别把裸的1984端口直接暴露出去。我见过有人图方便把1984映射到公网，结果摄像头画面被陌生地址访问，这种教训真的不希望你们再踩一次。

3. 摄像头接入与多协议播放实操

3.1 摄像头端准备：开启RTSP并确认地址

go2rtc要拉摄像头视频流，最通用的方式就是RTSP协议。绝大多数IPC摄像头（海康、大华、萤石、TP-Link、小米部分型号）都在后台提供RTSP开关，不同品牌位置不太一样，但思路相同：在摄像头管理页面开启RTSP服务，设置一个专门用于取流的账号（权限只给视频流），然后记下RTSP地址。

这里我把几个常见品牌的RTSP地址格式整理成表，方便你直接对照配置：

需要注意，这个地址里的端口如果不写，默认是554，一般不用加，但如果你改过摄像头端口，就必须显式写上。海康的101结尾表示通道1主码流，102是通道1子码流；大华则是subtype=0表示主码流，subtype=1表示子码流。子码流分辨率低、码率小，适合预览和多路同看；主码流清晰但更吃带宽，这个选择在后面的播放流畅度里会直接影响体验。

我自己的习惯是：预览墙和报警推送用子码流，回放和AI识别需要细节时用主码流，两个码流都分别在go2rtc里配置好，需要时随时切换。

3.2 把摄像头接进go2rtc

拿到RTSP地址后，把它填到go2rtc配置里。比如我在配置里写了：

streams: front_door: - rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101 - rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/102 backyard: - rtsp://admin:pass@192.168.1.65:554/cam/realmonitor?channel=1&subtype=1

注意我用了列表形式，也就是一个流名下可以写多个地址。go2rtc会优先选择链路质量高的那个源，如果第一个断了会自动切换第二个。我把海康的主码流和子码流都挂到front_door下面，这样默认用主码流预览，遇到带宽波动时可以自动切到子码流，实际使用中这个机制帮了不少忙。

配置保存后，重启容器，或者直接在go2rtc页面点刷新，就能看到对应流开始工作。页面会显示源状态和进程信息。如果配置错误，页面上会直接抛异常提示，也可以在容器日志里定位问题。我第一次配置时手滑把RTSP地址里的密码多打了一个字符，页面提示拉流失败，我还怀疑是端口映射有毛病，后来看日志才知道是认证失败。所以看到问题先看日志，别瞎猜。

3.3 多协议输出：WebRTC、HLS、MJPEG、MP4

go2rtc的核心魅力在于，接入一路源流后，不仅能在它自己的页面看，还能按需输出多种协议给不同客户端。以我的经验，最常用的四个输出形态如下：

• WebRTC是首选，在go2rtc页面点击播放，默认就是用WebRTC传输，延迟极低，局域网内基本感觉不到延迟，适合实时看门口、看孩子房间。
• HLS是兜底方案，把流切成一小段一小段通过HTTP提供，兼容性最好，任何浏览器、播放器都能播，代价是延迟会高几秒。
• MJPEG适合需要“静态图”的场景，比如做门铃预览、嵌套到网页仪表盘。
• MP4适合临时录制，点个链接就能下载当前时间段片段，应急取证很好用。

这些输出对应的URL我整理如下：

WebRTC：直接在 go2rtc 页面打开，或者用支持WebRTC的播放器 HLS： http://IP:1984/api/stream.m3u8?src=front_door MJPEG：http://IP:1984/api/frame.jpg?src=front_door MP4： http://IP:1984/api/stream.mp4?src=front_door

其中src参数指的就是你配置的流名。这几个URL可以直接填到支持相应协议的播放器、Home Assistant卡片、网页代码里。比如我给家里的智能家居仪表盘嵌入了一张MJPEG的门口画面，加载速度和稳定性都远超原厂APP的小窗口。实际测试下来，局域网内一路MJPEG请求占用带宽不高，动态画面下也能稳定刷新，嵌入网页最合适。

3.4 在手机、电视和第三方系统里播放

手机上最省事的办法是直接用浏览器打开http://IP:1984，go2rtc页面做了移动端适配，点开就能看。如果嫌Web界面不够用，也可以用支持WebRTC的App配合URL拉流。电视端的思路类似，通过支持HLS的播放器或者浏览器访问HLS地址就行。

更进阶的玩法是把go2rtc接入第三方系统。Home Assistant和go2rtc关系非常紧密，官方集成直接支持go2rtc，填一下go2rtc地址就能把配置的所有流暴露为摄像头实体。Frigate这个NVR方案也支持把go2rtc作为源再接进来，我后面会再展开讲。这里先给个结论：只要go2rtc里能流畅看到流，基本就等于所有主流系统都能用上这路视频流了。

用VLC这类本地播放器也能直接拉流。在VLC里打开网络串流，输入：

http://IP:1984/api/stream.m3u8?src=front_door

就能在电脑上把go2rtc管的所有摄像头当成普通电视直播一样看。这个调试技巧很实用，排查播放问题时比浏览器环境少很多干扰。

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

4.1 流一直转圈拉不出来

这是新手碰到最多的问题。现象是go2rtc页面能看到流，但点开播放一直转圈。排查路径按优先级排下来：

第一步看日志。执行docker logs go2rtc，重点看有没有rtsp、auth、timeout这几个关键词。如果是401或认证失败，说明RTSP地址里的用户名或密码不对，去摄像头后台确认一下。如果是连接超时，说明网络不通，先ping摄像头IP，再确认Docker宿主和摄像头是不是同一网段。

第二步看摄像头并发限制。有些家用摄像头支持的路数有限，如果你同时让原厂APP、go2rtc、另外一个NVR都在拉同一路流，可能触发摄像头侧的资源限制。我遇到过一台摄像头，最多允许两路RTSP并发，第三路就会拒绝连接，表现在go2rtc这里就是反复重连。解决方法是关掉原厂APP的实时预览，或者减少接入的端数。

第三步看摄像头编码类型。新版摄像头常默认H.265，如果播放端不支持，画面就是黑的或者一直不出流。这个通常不是拉流失败，而是解码失败，这类问题我在4.3节专门讲。

4.2 画面卡顿与延迟优化

画面卡、延迟高，要先分清是“源端拉不动”还是“分发端扛不住”。如果只是单路就卡，基本可以认为是摄像头到go2rtc这段带宽或摄像头性能不够。这时我建议把源地址换成子码流：海康把101改成102，大华把subtype=0改成subtype=1。子码流分辨率低码率小，局域网内非常流畅，代价是细节少一些。

如果多路同时卡，就要考虑Docker宿主性能了。go2rtc的设计是尽量不转码、直接转发，所以CPU占用一般不高，但宿主内存太低或磁盘IO很慢时，多路并发还是有压力。再一个是网络，我的经验是摄像头尽量走有线的POE交换机，不要靠Wi-Fi承载多路主码流，2.4G频段干扰大，丢包率上去了画面就花。

延迟方面，WebRTC延迟低但前提是UDP 8555端口通。如果网络环境NAT很严、UDP打洞失败，go2rtc会退化成TCP中继，延迟会飙升。局域网内一般没事，跨网络访问时才明显。想降低延迟，可以检查宿主机的8555/udp端口是否映射正常，或直接改用host网络模式。

4.3 浏览器黑屏与编码问题

接入后发现go2rtc页面能出界面，但画面黑屏、只有声音或者干脆没画面，多数情况和H.265编码有关。Chrome、Firefox这类浏览器对H.265的支持时好时坏，尤其是不支持的平台，黑屏是很正常的。Safari稍微好一点，但也不能保证所有H.265都能播。

我的建议很朴实：在摄像头后台把视频编码从H.265改成H.264。很多家用摄像头可以选择H.264/H.265，或者主码流H.265、子码流H.264。go2rtc的优势是不转码直接转发，所以尽量在源端把格式统一成H.264，后端所有播放端就省心了。如果你确实需要H.265又要在非Safari浏览器播放，那得引入转码方案，这就不是go2rtc的强项了，建议用带硬件转码的服务配合。

还有一类黑屏是分辨率或帧率导致浏览器解码压力大，比如500万像素主码流在低配电脑上WebRTC解码吃力。这种情况回退到子码流基本能解决，别指望浏览器在监控场景里做超高画质解码。

4.4 WebRTC打洞失败与访问不了

WebRTC连接失败的症状是：页面能加载、画面白屏、日志里出现ICE、STUN相关报错。这通常是因为UDP端口没有放通。如果你用的是端口映射方式，检查是不是漏了8555:8555/udp这一条，只映射TCP 1984是不够的。如果已经映射还不行，建议换成host网络模式，省去NAT映射这一层，很多跨网段访问问题会迎刃而解。

如果你需要从外网访问go2rtc做远程监控，我建议不要直接暴露1984端口，而是用Caddy、Nginx之类的反向代理加HTTPS和基础认证。反向代理把WebRTC涉及的UDP转发处理好相对麻烦，所以远程实时流我一般直接改用HLS，或者干脆配合Home Assistant/Frigate来访问，避免被WebRTC的NAT问题反复折磨。记住一个原则：局域网追求低延迟用WebRTC，跨网络求稳用HLS。

4.5 Docker容器资源占用与异常恢复

go2rtc本身很轻量，部署后空闲时内存占用通常只有几十MB，CPU几乎为0。但如果你发现容器CPU持续飙高，先检查是不是有人在持续拉HLS流或者转码任务被触发。还有，容器日志太大也会慢慢吃磁盘，我习惯在docker-compose里加上日志轮转限制：

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

这样日志最多30MB左右，不会被海量重连日志撑爆磁盘。镜像升级也很重要，建议定期执行docker compose pull && docker compose up -d，保持go2rtc版本较新，因为摄像头和浏览器生态都在变，新版本对WebRTC兼容性和流切换稳定性都有改进。

真正遇到容器挂了怎么办？因为设置了restart: unless-stopped，绝大多数崩溃会自动拉起。如果起不来，先看docker logs最后几行报错，常见的是挂载路径权限问题或yaml格式错误。yaml格式错误最常见的是缩进不对，go2rtc对缩进敏感，我踩过一次坑，在流名下面忘记缩进，结果服务直接拒绝启动。改好配置后重新docker compose up -d即可，容器级的隔离让回滚非常快。

5. 更多玩法与个人使用体会

5.1 把go2rtc接入Frigate做AI识别

go2rtc是Frigate官方推荐的好搭档。Frigate是一个开源的NVR/AI摄像头识别方案，可以对视频流做人形、车辆、宠物检测。直接在Frigate的配置里把go2rtc的流地址指过去，Frigate就能拿到实时流做推理，而预览界面还能借助go2rtc的WebRTC低延迟播放，比传统的MJPEG预览流畅太多。

我的使用方式是这样的：go2rtc统一管理家里所有摄像头，Frigate通过go2rtc拉取主码流做检测和录像，Home Assistant负责报警推送。整个链路里go2rtc只做流量调度，不负责录像也不负责AI，职责单一，出了问题也容易定位。如果你对NVR录像有兴趣，还可以让Frigate把录像写到NAS上，那是另一套部署方案，但基础就是先把go2rtc这层打通。

5.2 多路画面同时看的进阶实践

go2rtc页面默认可以单独点开每一路流，但如果你想一屏看四路、九路，原生界面比较朴素。我的做法是在浏览器里同时开多个iframe，每个iframe指向go2rtc的不同HLS或WebRTC播放地址，拼成一个简单的监控墙。你也可以用Home Assistant的Picture Glance卡片，或者自己写一个带Grid布局的小网页，原理都是引用go2rtc的输出URL。

如果某一刻对低延迟要求特别高，比如正在等快递、要看门口的人走到哪了，我会单独用WebRTC全屏看这一路，延迟低到几乎和摄像头本身的画面同步，这在原厂APP里很难做到。反正gog2rtc把协议转换这层抽象掉了，你只需要关心“用哪个协议去消费这个流”，剩下的它来操心。

5.3 最后分享几个我的使用心得

这套系统我实际用了大半年，从最初的一台Docker加三路摄像头，到现在家里工作室统共九个摄像头都挂在上面，整体稳定性让我比较满意。最明显的感受是：统一入口带来的便利远大于部署时的一点折腾成本。现在我想看任何一路摄像头，打开同一个页面就能解决，不用再记哪个牌子用哪个APP。

踩过的坑也值回票价，我总结三条送给你。第一，摄像头端尽量统一编码为H.264，能省掉后续一大半播放兼容性问题。第二，Docker容器要舍得给稳定网络，我用的是有线POE和一台小主机专门跑，比最初放在Wi-Fi路由器上稳多了。第三，go2rtc配置文件的备份要纳入日常习惯，我把它放到NAS同步目录里，一次配置，多台设备迁移都不用愁。如果你也想改善家里或者公司的摄像头查看体验，这套Docker加go2rtc的方案值得一试。