去年给一哥们儿的院子做监控整合时，我差点被一堆摄像头协议搞到崩溃。一台海康 POE 半球、一台萤石云台、一台树莓派上的 USB 摄像头，三个平台三个 App，浏览器里想同时看三路画面比登天还难，更不要说把视频流喂给 Home Assistant 做自动化。最后让我从泥潭里爬出来的，就是 go2rtc 这个工具。它是个用 Go 写的多协议流媒体代理，RTSP、RTMP、HLS、WebRTC、MJPEG、ONVIF 这些协议都能接，配合 Docker 部署只要一条命令就能起服务，直接把各路摄像头的流汇聚成浏览器能直接看的画面，还能再往 VLC、ffmpeg、Home Assistant、Frigate 这些地方转发。这篇文章就把我自己的部署过程、配置写法、踩坑记录和调优经验完整写出来，给想搞摄像头统一接入的人当个参考。

不管你是树莓派玩家、NAS 用户，还是想在工作室里做多路摄像头的统一预览，go2rtc 这套方案都够轻够快。接下来的内容会按我的实际操作顺序走：先讲清楚它到底解决什么问题，再做 Docker 部署，然后写摄像头接入的几种典型配置，最后聊 WebRTC 低延迟播放和生态联动。全部是基于真实项目验证过的做法。

1. 多协议兼容的关键一站：go2rtc 到底解决什么问题

1.1 摄像头的协议散装现状

摄像头行业到今天也没有一个统一标准。专业安防厂商的设备通常支持 RTSP 和 ONVIF，但不同品牌的 RTSP 地址格式完全不一样，海康有海康的路径，大华有大华的写法，宇视又有自己的规则；家用摄像头就更混乱，小米、萤石、360 这类品牌大多优先走自己的私有云协议，局域网里能不能拿到标准 RTSP 流，全看厂家心情；树莓派摄像头模组、USB 摄像头走的又是 V4L2 / UVC / MJPEG 这一套；还有一堆老设备只支持 RTMP 推流或者 HTTP MJPEG 预览。普通人家里同时有两三种摄像头再正常不过，每种都要装独立 App、独立账号、独立网络配置，想统一看画面就得自己想办法。

在这种背景下，我们需要的是一个“流汇聚层”：把不同协议的视频流拉到同一个服务里，对外再输出成统一的、容易消费的格式。go2rtc 就是这个定位。它不是 NVR，不做录像，不做 AI 识别，而是专注于“接入—转换—分发”这件事。说人话就是，它像个多功能转接头，一边插各类摄像头，另一边吐出来的是 WebRTC、HLS、RTSP、RTMP 这些干净统一的流。

1.2 浏览器不能直接播 RTSP 的根源

很多人一开始都纳闷：摄像头明明支持 RTSP，VLC 也能打开，为什么浏览器不行？这里涉及一个最基本的现实：浏览器只实现了 HTTP 与相关媒体协议（比如 MSE、WebRTC），而 RTSP 走的是独立的会话控制流程和传输机制，浏览器没有原生 API 去解析 RTSP 流。即使 HTML5 的 video 标签支持 HLS 和 MP4 播放，也完全不认识 rtsp:// 这种前缀。

所以要实现“浏览器里点点鼠标就看摄像头”，服务端必须做一次协议转换，把 RTSP 拉成 WebRTC 或 HLS 再推给前端。这个转换层可以自己用 ffmpeg 转码推流，也可以用现成项目替代。go2rtc 的聪明之处在于它内置了不少媒体模块，对 H.264 / H.265 的摄像头流可以直接做“拷贝级转发”，不经过重编码，CPU 占用极低，同时通过 WebRTC 输出给浏览器，延迟能控制在几百毫秒级别。

1.3 go2rtc 和 Frigate、EaseNVR 这类项目的分工

很多人在网上搜“海康 4G 摄像头接入安防平台”、“萤石摄像头通过 easynvr docker 接入飞牛 NAS”，这类需求本质上是想搞一套完整的 NVR。NVR 系统比如 EaseNVR、Frigate、Blue Iris 等，功能覆盖录像、回放、报警、AI 检测，但这些系统在“视频源接入”这一层往往会遇到同样的协议碎片化问题。go2rtc 的价值恰恰在于它可以先做统一接入，再把整理好的流喂给上层业务系统。

项目	核心定位	录像能力	对摄像头协议适配	与 go2rtc 的关系
go2rtc	流媒体汇聚与低延迟分发	不内置	很好，多协议原生支持	作为一个独立的流接入层
Frigate	NVR + AI 物体检测	自带	依赖 go2rtc 做拉流与转码	Frigate 内置 go2rtc，常见搭档
EaseNVR	商业/开源 NVR	自带	对海康萤石等有适配	可以并联也可以独立使用
各家官方 App	单品牌云平台	自带云端/本地存储	只适配自家设备	OpenAPI 打通成本高

这张表想表达的是：go2rtc 不抢 NVR 的饭碗，它管的是摄像头和“想要画面的人”之间的那段路。如果你的目标是快速在浏览器里看到几路流，或者把视频流无缝供给其他系统，它就非常合适。

2. Docker 部署前的一堂必修课：镜像、硬件与网络模式

2.1 为什么我推荐 Docker 而不是直接跑二进制

go2rtc 是纯 Go 编译的单文件程序，理论上直接下载二进制文件执行也很快。但我依然推荐用 Docker，原因很简单：一是环境隔离，不会污染宿主机的 Go 环境、ffmpeg 版本、动态链接库这些乱七八糟的东西；二是管理方便，配置目录挂载出来，升级容器就行了，多台机器之间迁移也容易；三是自启动策略写在容器参数里，省去写 systemd unit 的力气；四是官方镜像维护得不错，多架构支持很到位。对树莓派、NAS、软路由、旧笔记本这些常见部署环境，一条 docker run 就能统一管理。

也有朋友问过镜像体积会不会很大，这点倒可以放心。因为 go2rtc 本身是静态编译的二进制，基础镜像很精简，整体镜像体积通常只有几十 MB 级别，比装一套一两个 GB 的专用监控软件干净太多。

2.2 硬件需求到底要多低

直接在树莓派上跑过三路摄像头，如果摄像头输出的是 H.264/H.265，go2rtc 默认只做流拷贝，不做重编码，所以树莓派 CPU 占用基本可以忽略；只有当你需要把 MJPEG 转 H.264，或者把分辨率缩放到指定尺寸时，才会用到转码能力，那才会吃 CPU。内存方面，go2rtc 自身通常占用几十 MB，主要压力来自并发客户端的数量和转码任务。在我的树莓派 4B 上，3 路 RTSP 流加 1 路 ffmpeg 拉流，容器内存大概 50MB 上下，这个开销是相当友好的。

所以硬件没什么好焦虑的。如果你只是局域网内两三个摄像头预览，一个树莓派、一台 NAS、甚至一块旧开发板都够用；如果你要走大量转码或者给十几路摄像头做分发，建议换 X86 小主机或者性能更高一些的 NAS，务必开启硬件转码。

2.3 网络模式：为什么我优先用 host

部署 go2rtc 时最容易被忽略的一件事就是网络模式。很多第一次用 Docker 的人习惯 -p 1984:1984 做端口映射，但这种做法对 go2rtc 来说不够友好，因为它不只是跑一个 Web 端口。go2rtc 既要监听 RTSP 端口对外输出流，又要处理 WebRTC 的 UDP 端口段，如果用 bridge 模式，就得手工把 TCP 1984、8554 和 WebRTC 用到的 UDP 端口段全部映射出来，漏一个端口 WebRTC 就可能在跨网段时打洞失败，画面卡在连接中。

所以我建议只要你能用 host 模式，就直接用。host 模式让容器直接共享宿主机网络栈，所有端口自动暴露，也避免了一层 NAT，WebRTC 的连通性会好很多。这在实际部署中能省掉一大半问题。当然 Windows / macOS 上的 Docker Desktop 对 host 网络支持并不完美，这类环境可以用 bridge 模式手动映射常见端口，后面我会给出具体做法。

2.4 部署前需要认识的几个端口

端口	协议	用途
1984	TCP	Web 管理界面、REST API、WebRTC 信号入口
8554	TCP	go2rtc 以 RTSP Server 形态对外输出流时使用
8555	UDP/TCP	WebRTC 音视频数据传输常用端口，具体以启动日志为准
50000-50100	UDP	部分版本 WebRTC 端口范围，按实际版本确认

端口号并不是拍脑袋定的，都是 go2rtc 默认配置里的监听项。刚开始不熟悉没关系，用 host 模式跑起来后，打开 Web UI 的 Server 页面能看到实际的监听地址和端口，按需调整即可。

3. 一条命令跑起来：目录规划、端口映射与页面验证

3.1 先规划目录结构

我在启动容器之前习惯先建一个项目目录，把配置和数据分离。原因不复杂：config.yaml 是核心配置，要经常改，单独放出来方便维护和备份；录像、转码临时文件放另一个目录，避免把日志和缓存混到配置目录里。下面是我的目录结构：

~/go2rtc/
├── data/
│   └── config.yaml
└── media/

data 目录挂载到容器内的 /config ， media 目录用来放临时文件或者后续接录制脚本的导出目录。首次启动时如果 data/config.yaml 不存在，go2rtc 会自动生成一份默认配置，路径和挂载关系先规划清楚，后续替换配置非常顺手。

3.2 使用 docker run 快速启动

如果你的宿主机是 Linux 服务器或基于 Linux 的 NAS，直接用 host 网络模式，启动命令如下：

docker run -d --name go2rtc \
  --restart unless-stopped \
  --network host \
  -v $PWD/data:/config \
  -v $PWD/media:/media \
  -e TZ=Asia/Shanghai \
  alexxit/go2rtc:latest

解释一下几个关键参数：

• -d 后台运行， --name go2rtc 给容器命名，方便之后查看日志和启动停止。
• --restart unless-stopped 设置开机自启，机器重启以后容器自动拉起来。
• --network host 使用宿主机网络栈，省去端口映射，也保证 WebRTC 的 UDP 包能在局域网内存活得好。
• -v $PWD/data:/config 把宿主机目录映射到容器配置目录，后续所有配置改动都写在这个文件里。
• -e TZ=Asia/Shanghai 设置时区，日志时间和后续录制文件命名才不会跑偏。

如果你是在 Windows / Mac 的 Docker Desktop 上跑，host 模式不友好，可以改用 bridge 模式并映射端口：

docker run -d --name go2rtc \
  --restart unless-stopped \
  -p 1984:1984 \
  -p 8554:8554 \
  -p 8555:8555 \
  -p 8555:8555/udp \
  -v $PWD/data:/config \
  -e TZ=Asia/Shanghai \
  alexxit/go2rtc:latest

这里 8555 是 WebRTC 较常见的默认监听端口，实际版本如果有差异，去容器日志或 Web UI 的 Server 页看监听地址就行。核心思路是把 WebRTC 用到的 TCP/UDP 端口都放进来，UDP 是重点，TCP 漏了反而问题不大。

3.3 用 docker-compose 管理长期运行

命令能跑，但长期维护我更喜欢用 Compose。配置全写在 YAML 里，后续加环境变量、加依赖服务都方便，团队协作时也更容易评审。 docker-compose.yml 可以参考：

services:
  go2rtc:
    image: alexxit/go2rtc:latest
    container_name: go2rtc
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./data:/config
      - ./media:/media
    environment:
      - TZ=Asia/Shanghai

然后一句 docker compose up -d 就能启动。以后改配置就在 ./data/config.yaml 里改，改动完成执行 docker restart go2rtc 即可。

3.4 首次启动与页面确认

启动完毕后，先看一眼容器状态：

docker ps | grep go2rtc
docker logs go2rtc

日志里如果出现了类似 api listening on :1984 的提示，说明服务已经正常起来了。这时打开浏览器，访问 http://你的主机IP:1984 ，应该能看到 go2rtc 的 Web 界面。第一次进的时候页面几乎是空的，因为还没有添加任何流。页面顶部有 Streams 和 Server 等入口，Server 页会列出当前各模块的监听信息，这也是我每次排查问题时第一个看的地方。

到这一步，Docker 层面的部署就完成了。不过别急着在 UI 里乱七八糟点，先把摄像头怎么接到 go2rtc 理解清楚，后面才不会迷惑。

4. 把摄像头接进来：配置文件写法和三种典型接入方案

4.1 config.yaml 的基础结构

go2rtc 的核心配置在 data/config.yaml 里。一个最小可用的配置大概长这样：

log:
  level: info

api:
  listen: ":1984"

webrtc:
  listen: ":8555"

rtsp:
  listen: ":8554"

streams:
  摄像头1: rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101

streams 部分就是摄像头流的定义，格式是“显示名称: 拉流地址”。显示名称你可以自己起中文，UI 和播放地址里都会用它作为识别符。除了手工编辑配置文件，还可以在 Web UI 的 Streams 页面直接添加，改动会同步写回配置文件，两者是互通的。

4.2 RTSP 摄像头直连接入

最常见的摄像头接入方式是 RTSP 直连。拿海康威视这样的设备举例，进入摄像头 Web 管理后台，确认已经开启 RTSP 服务，然后填上账号密码和通道地址就行了：

streams:
  门前摄像头: rtsp://admin:YourPassword@192.168.1.64:554/Streaming/Channels/101

这里有几个必须注意的地方：

• 海康的 RTSP 路径中 101 表示通道 1 主码流， 102 表示通道 1 子码流。预览用子码流更流畅，录像和回放用主码流更清晰。
• 如果密码里含有 @ : / # 这类特殊字符，直接写在 URL 里大概率解析失败，要用 URL 编码代替。比如密码是 Ab@123 ，就要写成 Ab%40123 ，这个坑我踩过不止一次。
• 建议到摄像头管理后台创建一个单独的子账号，只给 RTSP 查看权限，不要把管理员密码直接写进配置文件里，尤其是当配置文件要纳入版本管理的时候。

配置写好之后，保存文件，等 go2rtc 自动重载，或者在 UI 里刷新。能出画面就说明连通了。如果画面不出来，优先检查摄像头 IP 是否可达、RTSP 端口是否开放、账号权限是否足够。

4.3 ONVIF 自动发现接入

不是所有摄像头都能告诉你准确的 RTSP 地址，尤其是那些杂牌设备、工程机、或者换了固件的摄像头。这种时候 ONVIF 协议就派上用场了。ONVIF 是安防行业的标准互操作协议，摄像头只要支持，go2rtc 就能通过 ONVIF 探测到它的媒体服务地址，不需要你自己去翻文档找路径。

配置写法非常简单：

streams:
  角落摄像头: onvif://admin:YourPassword@192.168.1.80

go2rtc 会向摄像头发送 ONVIF 探测请求，自动解析出 RTSP 地址并拉流。这也是我接手不确定型号摄像头时的首选方式。需要注意一点，部分摄像头默认只开放 ONVIF 端口 80，有些走 HTTPS 的会开放 443，URL 里可以显式加端口：

streams:
  角落摄像头: onvif://admin:pass@192.168.1.80:80

如果设备不支持 ONVIF，或者账号权限没打开，你会看到连接失败的日志。去摄像头 Web 管理后台把 ONVIF 协议开关打开、勾选允许匿名或授权账号访问，再回来重试。

4.4 私有协议、MJPEG 和 RTMP 这类难缠源的接入

家用摄像头品牌里，小米、萤石、360 这类设备大多是私有云平台优先，未必开放 RTSP。如果你在摄像头的 Web 管理后台或新版官方 App 里找不到 RTSP 开关，就会被卡住。针对这种情况，我一般按下面的顺序尝试：

先去翻官方说明书或者社区资料，看有没有隐藏的“局域网 RTSP”开关。海康的萤石系列不少型号可以开启 RTSP/ONVIF，小米部分摄像头也能通过特定方式开启 RTSP，但不同固件之间差异巨大，只能实测。如果完全拿不到 RTSP 地址，但摄像头提供了一个 HTTP 的 MJPEG 预览地址，go2rtc 可以用内置的 ffmpeg 模块去拉这个 JPEG 流。举个例子：

streams:
  客厅摄像头:
    - "ffmpeg:http://admin:pass@192.168.1.100:80/video.mjpeg#video=copy"

如果摄像头能主动向某个地址推 RTMP 流，那更简单，用 go2rtc 的 RTMP 模块去监听就行了。go2rtc 容器一般自带 ffmpeg，所以这种拉流方式不用额外安装东西。但必须说明：并不是所有私有云摄像头都能靠这些技巧打通，有些摄像头连局域网 MJPEG 都不开放，非要走云端中转，这种硬骨头就不要再浪费时间了，要么接受官方 App，要么换设备。

4.5 验证多路接入与故障切换

在配置文件里可以同时写多个 stream，每个有一个独立名称。go2rtc 还支持同一个名称下配多个源，源之间作为后备关系，当第一个源失效时自动切换到下一个：

streams:
  门口摄像头:
    - rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101
    - rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/102

这样等于把主码流和子码流都配在后面，当主码流出现异常时，go2rtc 会自动调用备用源，不至于黑屏。多路验证时，打开 Web UI 的 Streams 页面，所有已配置的源会一行一行列出来，直接点开就能看到画面。如果某一路上方出现红色的连接状态，就说明这路源有问题，点开日志看具体原因。这个页面基本就是我日常排障的第一现场。

5. 低延迟播放链路：WebRTC 调优、浏览器打开与 ffplay 取流

5.1 go2rtc 输出侧协议到底怎么选

摄像头接入只是第一步，接下来要考虑的是“从哪儿看、看多快”。go2rtc 对外输出的核心协议有三种常用路径：WebRTC、HLS、MJPEG。它们的特性差异非常大，我用表格整理一下，方便你按场景选。

协议	延迟	浏览器兼容性	典型场景
WebRTC	几百毫秒以内	原生支持，无需插件	实时预览、巡检、PTZ 控制配合
HLS / LL-HLS	3 到 10 秒	原生支持	跨网段分享、第三方播放器兼容
MJPEG	单帧延迟，但无音频	原生 img 标签可用	简单嵌入网页、快照监控

如果你只是在局域网内临时看画面，WebRTC 几乎是最好的选择；如果你要分享给异地朋友看，HLS 对网络环境要求低一些；如果只是做个简单的网页看板，MJPEG 直接放到 <img> 标签里就能用。

5.2 浏览器里的 WebRTC 秒开技巧

直接在浏览器访问 go2rtc 的 Web UI，点开对应的 stream，内部走的就是 WebRTC 路径。如果你想在自定义页面上嵌入某一路画面，go2rtc 提供了一个很简洁的 URL 格式： http://你的主机IP:1984/#门口摄像头 ，打开就是这个 stream 的播放页。也可以借助它自带的 JS 播放器，把高延迟的 HLS 换成 WebRTC，这样网页里的画面基本是“秒开”的。

WebRTC 是建立在 UDP 和 NAT 穿透机制上的实时传输技术，它天然适合局域网这种网络路径短、没有强防火墙的环境。在家庭局域网里，WebRTC 的 ICE 协商一般能在几秒内完成，画面延迟体感上几乎没有。如果你的服务跑在跨越网段、跨运营商机房、甚至容器多级 NAT 的环境里，就可能出现“能出图但卡顿”或者“一直在连接中”的情况，这就是 NAT 穿透失败。此时需要在 webrtc 配置里手动声明候选地址。

webrtc:
  listen: ":8555"
  candidates:
    - 192.168.1.10:8555

candidates 里填的是宿主机在局域网内的 IP，或者你希望客户端去连接的对外地址。这个配置在 IP 摄像头跨子网访问时尤其关键，否则客户端拿不到有效的连接地址，握手就被卡在门外。

5.3 用 VLC / ffplay 通过 RTSP 拉流

很多人不只是想在浏览器里看，还想在本地播放器里打开，或者把画面喂给 ffmpeg 做的处理流程。go2rtc 同时也是一个 RTSP server，它把每条流重新以 RTSP 协议暴露出来，地址固定为：

rtsp://你的主机IP:8554/摄像头名称

例如：

ffplay -rtsp_transport tcp -i "rtsp://192.168.1.10:8554/门口摄像头"

VLC 里直接打开“网络串流”，填同样的地址也能播放。这个能力非常实用，因为很多第三方的视频分析工具、推流软件、录制脚本只认 RTSP，有了一层统一的 RTSP 出口之后，管你背后是海康还是萤石还是杂牌 ONVIF，对下游来说它都只是“一路 RTSP”。

5.4 同一路流多端复用与码流选择

go2rtc 对同一个源只向上游拉一次流，然后由它分发，不会因为多个客户端同时看就把摄像头压垮。实测同一路流同时用浏览器 WebRTC、VLC RTSP、ffmpeg 拉流三路并发，摄像头侧的压力基本没有变化，这对那些规格较低的家用摄像头非常友好。

码流选择上，建议在配置里把主码流和子码流拆成两个入口，比如：

streams:
  门前主码流: rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101
  门前子码流: rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/102

UI 预览界面和手机临时查看用子码流，带宽压力小；需要回放、录像、AI 分析时再切主码流。很多第一次做统一接入的人把所有画面都默认拉成主码流，结果局域网拥塞、树莓派解码吃紧，其实都是码流选择没做对。

6. 实战中的常见坑与生态联动：从摄像头兼容到 Home Assistant

6.1 接入失败的排查链路

遇到过最多的问题就是“配置写完了，UI 里就是不出画面”。这种时候不要急，按我的排查链路一步步走，通常能很快定位。

第一步，确认网络通不通。在宿主机上 ping 摄像头 IP，如果都 ping 不通，先解决 VLAN、Wi-Fi 隔离、网段不一致的问题。第二步，确认 RTSP 端口通不通，用 nc 命令测一下：

nc -zv 192.168.1.64 554

第三步，用 ffprobe 直接拉一下摄像头流，确认账号密码和流路径是否正确：

ffprobe -rtsp_transport tcp -i "rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101"

这一步如果能拉到流信息，说明问题在 go2rtc 侧；如果 ffprobe 也报错，那问题多半还是在摄像头地址或权限上。第四步，到 go2rtc 的容器日志里看具体错误：

docker logs go2rtc --tail 50

日志里会有 rtsp 连接失败、认证失败、超时等直接原因。绝大多数问题都集中在“网络不同”、“密码不对”、“路径不对”这三件事里，先把这三项排干净，再去看 WebRTC 和端口配置，否则很容易做无用功。

6.2 密码特殊字符导致的解析失败

这是我自己踩过最深的坑。之前给一个海康摄像头配密码，密码里恰好有一个 @ ，结果怎么配都连不上，UI 报认证失败，排查了半天才发现 URL 里的特殊字符被当成连接地址的分隔符了。正确的做法是把特殊字符做 URL 百分号编码。

原字符	URL 编码
@	%40
:	%3A
/	%2F
#	%23
空格	%20

配置里一律用编码后的密码串，就不会有歧义。比如 Ab@123:456 要写成 Ab%40123%3A456 。这条经验对任何带账号密码的 RTSP/ONVIF URL 都适用。

6.3 端口冲突和容器权限问题

host 网络模式下容器和宿主机共享端口，如果宿主机上已经跑了其他服务占用 8554 或 1984，启动就会失败。启动失败时用 docker logs go2rtc 看看是哪个端口冲突，然后在 config.yaml 里把这些监听端口改掉。比如：

rtsp:
  listen: ":9554"

另外，如果容器进程以非 root 用户运行，绑定 80、443 这类低端口可能会权限不足。go2rtc 默认的 Web 端口是 1984，不涉及特权端口，但如果你手动把 api 改成 80，就可能遇到权限问题，要么换端口，要么在 docker run 里加上 --user root 并明确了解安全权衡。我个人更推荐直接换高位端口，省心且安全。

6.4 与 Home Assistant 和 Frigate 的联动

go2rtc 最让我喜欢的一点是它和一众开源智能家居/NVR 项目无缝衔接。Home Assistant 原生支持 go2rtc 集成，只需要在 configuration.yaml 里声明连接地址：

go2rtc:
  url: http://192.168.1.10:1984/api

配置好之后，HA 那边就能直接引用 go2rtc 里的 stream 名，把实时画面添加到 Lovelace 仪表盘。我的实际体验是，接入后 HA 里的摄像头延迟比原来的 HLS 方案低了一大截，做自动化触发也跟手了很多。

Frigate 更是直接内置了 go2rtc，所以你在 Frigate 的配置里看到的 go2rtc 配置块，本质上就是让 Frigate 复用 go2rtc 的拉流和转码能力。我自己在 Frigate 里接海康摄像头时，就是先把源写到 go2rtc 配置里，Frigate 再从 go2rtc 的流地址取图做检测，整体稳稳当当。

6.5 那些实在接不进来的平台锁摄像头

最后说点不好听的实话。如果你手里的摄像头是纯云平台锁死的——没有局域网 RTSP、没有 ONVIF、MJPEG 也不开放——那么 go2rtc 救不了它，任何第三方工具都救不了。各家厂商的自有协议和云端中转机制不是逆向就能轻易打通的，强行硬破既不稳定也浪费时间。我的做法是：这类摄像头继续用官方 App 查看，同时把真正支持标准协议的摄像头统一接入 go2rtc，作为主力监控画面；等到需要统一联动时，优先采购支持 RTSP/ONVIF 的设备。这也是为什么我一直强调买摄像头之前先确认它有没有开放协议支持，这比参数堆料重要得多。

---

最后再补充一点实际体会。go2rtc 在树莓派 4B 上加 Docker host 模式，我连续跑了半个多月，三路 RTSP 源和一路 ffmpeg 拉流，容器内存稳定在 50MB 左右，预览页面秒开，基本没有出现卡死或崩溃的情况。最让我省心的是它的配置热加载，改完 config.yaml 后大部分版本会自己感知变化并刷新，如果不确定就直接 docker restart go2rtc ，整个过程也就几秒钟。所以我真心建议你把 data/config.yaml 用 git 管起来，每添加一个摄像头就提交一次，出问题随时回滚。这套方案看起来不起眼，但真正用起来之后，你会发现以后再也不用为“这个摄像头怎么接入那套系统”发愁了。