Frigate 用 Docker 跑起来不难，真正容易出问题的是摄像头流、解码、检测器和事件链路。这个记录适合云上 ECS 做接入、边缘小主机做识别，或者办公室里用 Docker Compose 跑一套本地 NVR 的场景。
目标环境
部署方式：Docker Compose
摄像头：RTSP
识别：Frigate detector
联动：MQTT / Home Assistant
存储：本地盘或挂载目录
目标不是把服务勉强跑起来，而是确认有人经过时能稳定生成事件、能联动、能回放。
1. 镜像和版本预检
先固定版本和容器状态。
docker compose pull frigate
docker compose up -d frigate
docker compose ps
docker logs --tail=120 frigate
如果 GHCR 镜像拉取不稳定，先做一次入口验证：
docker pull ghcr.1ms.run/blakeblackshear/frigate:stable
这一层只负责确认镜像能到位。容器正常后，再进入视频链路。
2. RTSP 流检查
ffprobe rtsp://user:pass@camera-host:554/stream1
ffprobe rtsp://user:pass@camera-host:554/stream2
建议把录像和检测拆开：
- 录像使用主码流。
- 检测使用低分辨率子码流。
- 摄像头网络和账号先单独验证。
如果 ffprobe 都不稳定，先处理摄像头、网络和编码，不要急着改 Frigate 配置。
3. 解码设备检查
小主机或边缘节点上，解码压力会直接影响识别稳定性。
ls -lah /dev/dri
docker exec -it frigate ls -lah /dev/dri
Intel iGPU 场景可以在 Compose 里挂载：
services:
frigate:
image: ghcr.io/blakeblackshear/frigate:stable
devices:
- /dev/dri:/dev/dri
如果 CPU 长期高位，先把硬件解码和码流分配处理好，再看检测阈值。
4. detector 检查
docker logs --tail=200 frigate | grep -i detector
docker logs --tail=200 frigate | grep -i model
这里重点看：
- detector 是否正常启动。
- 模型缓存目录是否可写。
- 设备是否挂载到容器。
- 对象配置里是否有
person、car等目标。 - zone、mask 是否把有效区域挡掉。
5. 事件、MQTT 和存储
识别成功后，还要确认事件能出去、录像能保存。
docker logs --tail=160 frigate | grep -i mqtt
ls -lah /path/to/frigate/storage
df -h
如果 Home Assistant 没联动，先看 MQTT。若回放失败，先看存储目录权限和磁盘空间。
检查顺序
| 层级 | 命令或动作 | 目的 |
|---|---|---|
| 镜像 | docker compose pull frigate |
确认版本和容器启动 |
| RTSP | ffprobe rtsp://... |
确认视频输入稳定 |
| 解码 | 检查 /dev/dri 或 GPU 设备 |
降低 CPU 解码压力 |
| 检测器 | 看 detector 日志和模型缓存 | 确认识别链路在工作 |
| 事件 | 查 MQTT 和存储目录 | 确认联动和回放 |
小结
Frigate 摄像头有人经过却没事件，通常不是单点问题。先按五层排查，再决定是否调阈值、换码流或改硬件解码。镜像入口解决的是部署和更新第一层，RTSP、FFmpeg、detector、MQTT 和存储仍要分别验证。
