去年给一哥们儿的院子做监控整合时我差点被一堆摄像头协议搞到崩溃。一台海康 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 的根源很多人一开始都纳闷摄像头明明支持 RTSPVLC 也能打开为什么浏览器不行这里涉及一个最基本的现实浏览器只实现了 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流媒体汇聚与低延迟分发不内置很好多协议原生支持作为一个独立的流接入层FrigateNVR 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.265go2rtc 默认只做流拷贝不做重编码所以树莓派 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 模式让容器直接共享宿主机网络栈所有端口自动暴露也避免了一层 NATWebRTC 的连通性会好很多。这在实际部署中能省掉一大半问题。当然 Windows / macOS 上的 Docker Desktop 对 host 网络支持并不完美这类环境可以用 bridge 模式手动映射常见端口后面我会给出具体做法。2.4 部署前需要认识的几个端口端口协议用途1984TCPWeb 管理界面、REST API、WebRTC 信号入口8554TCPgo2rtc 以 RTSP Server 形态对外输出流时使用8555UDP/TCPWebRTC 音视频数据传输常用端口具体以启动日志为准50000-50100UDP部分版本 WebRTC 端口范围按实际版本确认端口号并不是拍脑袋定的都是 go2rtc 默认配置里的监听项。刚开始不熟悉没关系用 host 模式跑起来后打开 Web UI 的 Server 页面能看到实际的监听地址和端口按需调整即可。3. 一条命令跑起来目录规划、端口映射与页面验证3.1 先规划目录结构我在启动容器之前习惯先建一个项目目录把配置和数据分离。原因不复杂config.yaml 是核心配置要经常改单独放出来方便维护和备份录像、转码临时文件放另一个目录避免把日志和缓存混到配置目录里。下面是我的目录结构~/go2rtc/ ├── data/ │ └── config.yaml └── media/data目录挂载到容器内的/configmedia目录用来放临时文件或者后续接录制脚本的导出目录。首次启动时如果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 TZAsia/Shanghai \ alexxit/go2rtc:latest解释一下几个关键参数-d后台运行--name go2rtc给容器命名方便之后查看日志和启动停止。--restart unless-stopped设置开机自启机器重启以后容器自动拉起来。--network host使用宿主机网络栈省去端口映射也保证 WebRTC 的 UDP 包能在局域网内存活得好。-v $PWD/data:/config把宿主机目录映射到容器配置目录后续所有配置改动都写在这个文件里。-e TZAsia/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 TZAsia/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: - TZAsia/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:pass192.168.1.64:554/Streaming/Channels/101streams部分就是摄像头流的定义格式是“显示名称: 拉流地址”。显示名称你可以自己起中文UI 和播放地址里都会用它作为识别符。除了手工编辑配置文件还可以在 Web UI 的 Streams 页面直接添加改动会同步写回配置文件两者是互通的。4.2 RTSP 摄像头直连接入最常见的摄像头接入方式是 RTSP 直连。拿海康威视这样的设备举例进入摄像头 Web 管理后台确认已经开启 RTSP 服务然后填上账号密码和通道地址就行了streams: 门前摄像头: rtsp://admin:YourPassword192.168.1.64:554/Streaming/Channels/101这里有几个必须注意的地方海康的 RTSP 路径中101表示通道 1 主码流102表示通道 1 子码流。预览用子码流更流畅录像和回放用主码流更清晰。如果密码里含有:/#这类特殊字符直接写在 URL 里大概率解析失败要用 URL 编码代替。比如密码是Ab123就要写成Ab%40123这个坑我踩过不止一次。建议到摄像头管理后台创建一个单独的子账号只给 RTSP 查看权限不要把管理员密码直接写进配置文件里尤其是当配置文件要纳入版本管理的时候。配置写好之后保存文件等 go2rtc 自动重载或者在 UI 里刷新。能出画面就说明连通了。如果画面不出来优先检查摄像头 IP 是否可达、RTSP 端口是否开放、账号权限是否足够。4.3 ONVIF 自动发现接入不是所有摄像头都能告诉你准确的 RTSP 地址尤其是那些杂牌设备、工程机、或者换了固件的摄像头。这种时候 ONVIF 协议就派上用场了。ONVIF 是安防行业的标准互操作协议摄像头只要支持go2rtc 就能通过 ONVIF 探测到它的媒体服务地址不需要你自己去翻文档找路径。配置写法非常简单streams: 角落摄像头: onvif://admin:YourPassword192.168.1.80go2rtc 会向摄像头发送 ONVIF 探测请求自动解析出 RTSP 地址并拉流。这也是我接手不确定型号摄像头时的首选方式。需要注意一点部分摄像头默认只开放 ONVIF 端口 80有些走 HTTPS 的会开放 443URL 里可以显式加端口streams: 角落摄像头: onvif://admin:pass192.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:pass192.168.1.100:80/video.mjpeg#videocopy如果摄像头能主动向某个地址推 RTMP 流那更简单用 go2rtc 的 RTMP 模块去监听就行了。go2rtc 容器一般自带 ffmpeg所以这种拉流方式不用额外安装东西。但必须说明并不是所有私有云摄像头都能靠这些技巧打通有些摄像头连局域网 MJPEG 都不开放非要走云端中转这种硬骨头就不要再浪费时间了要么接受官方 App要么换设备。4.5 验证多路接入与故障切换在配置文件里可以同时写多个 stream每个有一个独立名称。go2rtc 还支持同一个名称下配多个源源之间作为后备关系当第一个源失效时自动切换到下一个streams: 门口摄像头: - rtsp://admin:pass192.168.1.64:554/Streaming/Channels/101 - rtsp://admin:pass192.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-HLS3 到 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:8555candidates里填的是宿主机在局域网内的 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:pass192.168.1.64:554/Streaming/Channels/101 门前子码流: rtsp://admin:pass192.168.1.64:554/Streaming/Channels/102UI 预览界面和手机临时查看用子码流带宽压力小需要回放、录像、AI 分析时再切主码流。很多第一次做统一接入的人把所有画面都默认拉成主码流结果局域网拥塞、树莓派解码吃紧其实都是码流选择没做对。6. 实战中的常见坑与生态联动从摄像头兼容到 Home Assistant6.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:pass192.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配置里一律用编码后的密码串就不会有歧义。比如Ab123: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 管起来每添加一个摄像头就提交一次出问题随时回滚。这套方案看起来不起眼但真正用起来之后你会发现以后再也不用为“这个摄像头怎么接入那套系统”发愁了。