企业官网建设流程全解析

装修监控这事，最花钱的往往不是摄像头。内存卡两三个月就被循环写入搞报废，厂商云套餐一个月十几二十块，一年下来又是小两百。我用手头一台乞丐版摄像头 + 一块闲置单板机 + 免费夸克网盘，把 24×7 监控存储与回放系统搭了起来：单板机用 ffmpeg 拉摄像头的 RTSP 流，切成一段段 mp4，再让 alist 把夸克网盘挂成 WebDAV，由 rclone 自动同步上去。整条链路跑下来，除了几块钱电费，一分钱订阅费没花，内存卡也不用再买了。

这套方案适合谁？家里有老摄像头但嫌厂商 App 难用的人，手里有树莓派、橙派这类吃灰板子的人，以及不想为云存储持续付费的人。哪怕你对 Linux 只懂个皮毛，照着后面的命令抄也能搭起来。下面我把思路、参数和踩过的坑一起写清楚。

1. 整体架构：为什么是“摄像头 → 单板机 → 夸克网盘”

1.1 先想清楚数据流

整套系统的数据流其实就是一个典型的分层存储模型：摄像头负责采集，单板机负责短期本地缓冲，夸克网盘负责长期异地备份。

摄像头 RTSP 流 → ffmpeg 分段录制 → 本地磁盘 ↓ rclone 增量同步 夸克网盘（通过 alist 挂载为 WebDAV）

这个架构的关键在于，摄像头本身不需要插内存卡，也不需要开厂商云。乞丐版摄像头开机后唯一的工作就是吐出一路 RTSP 码流，剩余所有脏活累活都交给我闲置的那块单板机。单板机既当录像机又当上传网关，本地硬盘留下的录像做热数据，网盘里的录像做冷备，两不耽误。

为什么不在摄像头里插卡？我在很多机器上试过，内存卡方案有几个绕不开的死穴：一是闪存颗粒有写入寿命，1080p 每秒写 250KB 左右，一张普通卡连续写入两三个月就开始掉速，一年内大概率报错；二是循环覆盖时文件系统碎片化严重，突然断电极易丢文件甚至直接提示格式化；三是一旦卡坏了，录像就断了，而你往往几天后才想起来去看。用单板机本地盘做缓冲，这些问题都能绕开，至少坏了也只是坏一块便宜硬盘，换掉不影响摄像头本体。

1.2 为什么必须分段录制，而不是录成一个整文件

最初的版本我图省事，直接一条 ffmpeg 命令录一天，生成一个 18GB 的 mp4。问题很快就来了：网盘上传失败就得整个文件重新传；想回看某个时间点要拖进度条拖半天；文件损坏的话一整天全废。

改成按 10 分钟一段之后，体验完全不同。上传失败最多丢 10 分钟，回放定位精确到文件名里的时分秒，rclone 增量同步也更高效。分段导致的碎片化问题，ffmpeg 的 segment muxer 本身处理得很好，文件名自带时间戳，配合-segment_atclocktime对齐自然时间，找一段录像就像翻日历一样简单。

1.3 先算一笔容量账

不花一分钱的前提是你得知道自己有多少免费空间。夸克网盘新用户免费容量大概在 10GB 上下，偶尔参加官方活动还能扩容，但咱们先按 10GB 算。不同码率下每天的录像体积是这样的：

算清楚这笔账之后，我的处理方式是：本地留 3 到 7 天完整录像，网盘作为滚动备份，只存最近几天的关键内容。如果实在想全量存云端，就老老实实把摄像头码率降到 720P 1Mbps，或者只录有人的时段。容量有限这件事不是 bug，而是免费方案的天然约束，接受它、设计好策略，反而比硬撑着全量上传稳定得多。

另外，单板机的本地存储建议用 USB 硬盘或者换了大容量 SD 卡的机器。我最初把录像写进系统 SD 卡，一边跑 alist 一边写录像，结果 SD 卡温度高得吓人，后来换了一块闲置的 256GB 移动硬盘，整个世界清静了。

2. 硬件选型：乞丐版摄像头和单板机怎么配

2.1 乞丐版摄像头怎么选：必须支持 RTSP

市面上的垃圾摄像头鱼龙混杂，但我只认一条死线：必须支持 RTSP 或者 ONVIF 协议。不符合的直接排除，哪怕它 App 做得再炫。因为我们的整条链路都建立在“能从摄像头拉流”这个前提上。

海康、大华、宇视这些正经安防品牌不用说，几十块的小厂 ANC、中维世纪、睿视之类，只要参数页写了 RTSP 支持就基本能干活。反而是一些智能家居摄像头（比如某些只能通过自家 App 看的云台机），固件封闭、不开放 RTSP，这种就不行，买了没法进本方案。

丐版摄像头绝大多数是 WiFi 连接，回传 1 到 2Mbps 的码流，WiFi 完全扛得住。但注意摄像头和单板机尽量放同一个交换机或同一面墙，隔一堵厚墙后 2.4GHz 丢包率会飙升，我现在遇到的所有断流事故，一半以上都源自 WiFi 信号不稳。

2.2 单板机的底线配置与系统准备

单板机选哪块不重要，重要的是一句大实话：我们采用的是流复制（-c copy），不做转码，所以 CPU 负载很低。树莓派 3B、橙派 Zero 2、香橙派 Zero 3，甚至电视盒子刷 Armbian 都能跑。我自己用的是几年前买的橙派 Zero 2，1GB 内存，跑 ffmpeg 录制一路 1080p + alist + rclone 同步，CPU 占用常年不到 10%。

底线配置大概是：

• 能跑 Linux（Debian/Ubuntu arm64 都行）
• 内存 512MB 以上
• 有至少一个空闲 USB 口接移动硬盘
• 供电稳定，别省那一口电源钱，单板机电压不稳轻则掉盘重则烧卡

如果你选的是树莓派，请直接装官方 Raspberry Pi OS Lite 64 位，装完先别折腾桌面，省下来的资源全给码流。另外记得把单板机设置成固定 IP，否则路由器重启后找不到机器很烦。

2.3 先把 RTSP 地址拿到手

不同品牌的摄像头的 RTSP 路径格式差异很大，常见的有：

海康威视：rtsp://admin:密码@IP:554/Streaming/Channels/101 宇视（Uniview）：rtsp://admin:密码@IP:554/unicast/c10/s0/live 大华：rtsp://admin:密码@IP:554/cam/realmonitor?channel=1&subtype=0

记不住路径没关系，先装一个 ONVIF Device Manager（Windows）或者直接在电脑上用 VLC 打开“网络串流”测试。很多乞丐版摄像头还支持在厂商 App 的“设备信息”页面直接看到拉流地址。拿到地址后，先在本机用 ffprobe 验证一下流是否正常：

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

能输出视频流信息就说明这条路通了。这一步务必在本机做，不要在单板机上遇到问题了再回来看，排查线索会被锯齿化。

注意：改掉摄像头的默认密码。丐版摄像头是最容易被扫描攻击的设备之一，初始密码 admin/admin 一旦暴露在局域网，等于把家门钥匙放在门口地垫下面。后面我还会专门说安全。

3. 核心实现：用 ffmpeg 分段录制

3.1 录制的完整命令

这是整个系统的核心一环，直接给能用的命令：

ffmpeg -y \ -rtsp_transport tcp \ -use_wallclock_as_timestamps 1 \ -i "rtsp://admin:PASSWORD@192.168.1.64:554/Streaming/Channels/101" \ -map 0:v -c copy \ -f segment \ -segment_time 600 \ -segment_atclocktime 1 \ -segment_time_delta 3 \ -reset_timestamps 1 \ -avoid_negative_ts make_zero \ -strftime 1 \ "/mnt/record/%Y%m%d/%Y%m%d_%H%M%S.mp4"

先别急着跑，把rtsp://...换成你自己的地址，把/mnt/record指到你挂载的移动硬盘目录，然后放后台。跑一天回来翻翻目录，正常的话按小时均匀地躺着 6 个 mp4，每个文件大小接近但不超过预期值。

3.2 每个参数为什么要这么设

-rtsp_transport tcp：强制走 TCP 拉流。默认是 UDP，UDP 在丢包时画面会花屏、卡顿，且码流一抖就断。TCP 虽然多一点点延迟，但稳定性和完整性完全不在一个等级。

-use_wallclock_as_timestamps 1：让 ffmpeg 使用单板机的系统时间作为时间戳基准，而不是信摄像头给的时间戳。丐版摄像头的时钟常年跑偏，有的甚至会随机跳变，这个参数能避免你切出来的文件时间轴错乱。

-map 0:v：只保留视频流。很多摄像头带有 G.711 音频，这种编码在网页端和网盘播放器里兼容性差，云端回放很容易有声无画或有画无声。只要画面，直接丢掉音频最省心。

-c copy：流复制，不重新编码。这是整套方案能跑在乞丐版单板机上的根本原因。CPU 占用可以忽略，缺点是没法调整分辨率帧率，所以录制质量完全取决于摄像头输出的码流。

-f segment -segment_time 600：切成 10 分钟一段。10 分钟的文件大小约 100-200MB，对网盘上传大小限制友好，回放定位也不累。太短会文件碎片太多，太长则失去了分段的优势。

-segment_atclocktime 1：让切割点对齐自然时间，也就是每天 00:00、00:10、00:20……一刀切下去。这样你看到文件名里的时间，就知道它的起止边界，回放定位极其顺畅。

-segment_time_delta 3：允许在目标切割点前最多 3 秒内找关键帧。这能缓解复制模式下“段尾长出一截”的毛病，后面会细说。

-strftime 1：让文件名模板里的%Y%m%d_%H%M%S按实际开始时间填充。如果不用这个，文件名只能按递增数字排，回放定位就废了。

3.3 开机自启与断线自动重连

ffmpeg 偶尔会因网络抖动退出，所以不能指望手动拉起。我把它做成 systemd 服务，负责开机自启和失败自动重启。

先建工作脚本/usr/local/bin/record.sh：

#!/bin/bash CAMERA_URL="rtsp://admin:PASSWORD@192.168.1.64:554/Streaming/Channels/101" OUT_DIR="/mnt/record" while true; do ffmpeg -y \ -rtsp_transport tcp \ -use_wallclock_as_timestamps 1 \ -i "$CAMERA_URL" \ -map 0:v -c copy \ -f segment -segment_time 600 -segment_atclocktime 1 \ -segment_time_delta 3 -reset_timestamps 1 -avoid_negative_ts make_zero \ -strftime 1 \ "$OUT_DIR/%Y%m%d/%Y%m%d_%H%M%S.mp4" \ >> /var/log/record.log 2>&1 echo "$(date '+%F %T') ffmpeg exited, restarting..." >> /var/log/record.log sleep 10 done

再写 systemd unit，放在/etc/systemd/system/record.service：

[Unit] Description=RTSP segment recorder After=network-online.target Wants=network-online.target [Service] ExecStart=/usr/local/bin/record.sh Restart=always RestartSec=15 StartLimitIntervalSec=0 [Install] WantedBy=multi-user.target

然后systemctl daemon-reload && systemctl enable --now record。这个写法比单纯让 systemd 重启 ffmpeg 更稳，因为循环里加了一层 network-online 等待，开机网络没起来不会立刻空转。

3.4 关键帧与切片的坑

用-c copy切流有个绕不开的物理现象：如果摄像头输出的 GOP（关键帧间隔）太长，那么切割点很可能落在非关键帧上，播放器从这段开头播放时得先等下一帧关键帧，于是出现 1 到 3 秒的黑屏或花屏。

ffmpeg 的 segment muxer 在复制模式下会尽量寻找关键帧作为切点，但摄像头默认 GOP 如果是 4 到 8 秒，你就会经常发现“这段 10 分钟，实际时长 10 分 07 秒，开头两秒黑屏”。解决思路有两个：

• 去摄像头管理页把 I 帧间隔调小到 1 秒或 2 秒，大部分专业摄像头都有这个选项
• 实在没法调（乞丐版固件藏得深），就接受-c copy的轻微瑕疵，或者只对非关键帧问题严重的机位改用轻量级转码：

ffmpeg -rtsp_transport tcp -i "rtsp://..." \ -map 0:v -c:v libx264 -preset veryfast -crf 28 \ -force_key_frames "expr:gte(t,n_forced*2)" \ -f segment -segment_time 600 -segment_atclocktime 1 -strftime 1 \ "/mnt/record/%Y%m%d/%Y%m%d_%H%M%S.mp4"

注意这里-crf 28画质会损失不少，只建议作为最后的兜底手段。能用原编码就是最省算力的方案。

4. 云端同步：把夸克网盘变成自动备份盘

4.1 安装 alist 并添加夸克网盘

alist 是一个开源的文件列表程序，支持把夸克网盘这类存储挂载成 WebDAV 接口。对咱们的方案来说，alist 就是把“夸克网盘”和“单板机上的 rclone”之间的桥。

安装方式很简单：到 alist 的 GitHub Releases 页面下载对应架构的二进制文件（单板机一般是 arm64），上传到机器里解压，然后执行：

./alist server

首次启动会打印一段随机密码，记下来。浏览器打开http://单板机IP:5244，用 admin 和随机密码登录。为了让 alist 开机自启，建议也做成 systemd 服务，或者直接丢进 rc.local，这步不展开，官网文档很详细。

登录之后，在管理后台左侧找到“存储 → 添加存储”，驱动类型选“Quark”（夸克），填一个存储名称，然后把夸克网盘的 Cookie 粘进去，保存。完成后回到“文件”页面刷新，如果能看到你网盘里的目录列表，说明挂载成功。

4.2 获取夸克 Cookie 的几个注意点

夸克网盘没有开放官方 API，alist 驱动是通过网页端接口工作的，所以需要你在浏览器登录后抓取 Cookie。操作其实很简单：

1. 用电脑浏览器打开https://pan.quark.cn并登录
2. 按 F12 打开开发者工具，切到 Network（网络）标签
3. 刷新页面，随便点一个pan.quark.cn开头的请求
4. 在请求头（Request Headers）里复制整个 Cookie 字段
5. 粘贴到 alist 的存储配置里

这里有几个血泪教训：首先，Cookie 会过期，通常一两个月，过期后 rclone 同步会开始报错，表现是文件列表能打开但上传一直 401。解法就是重新登录、重新复制 Cookie、在 alist 里更新保存。其次，Cookie 相当于半个登录态，手里有 Cookie 的人能直接操作你的网盘文件。所以 alist 管理面板千万不要暴露到公网，更不要为了省事开个默认密码问题不断的旧版本。

注意：夸克账号建议开启异地登录验证。网盘里存的是自家监控录像，这个保险必须买。

4.3 rclone + WebDAV 自动上传

alist 挂载成功后，它会在http://127.0.0.1:5244/dav提供 WebDAV 接口。我们用 rclone 把这个接口配置成一个远程盘：

rclone config

按提示新配置一个 WebDAV remote：

• type 选webdav
• url 填http://127.0.0.1:5244/dav
• vendor 选other
• user 填 alist 的管理员账号
• pass 填 alist 的管理员密码

配置完成后，写一个同步脚本/usr/local/bin/sync_quark.sh：

#!/bin/bash rclone copy /mnt/record quarkdav:监控录像 \ --transfers 1 \ --checkers 2 \ --log-file /var/log/rclone_quark.log \ --log-level NOTICE find /mnt/record -type f -name "*.mp4" -mtime +3 -delete find /mnt/record -type d -empty -delete

然后用 cron 每 15 分钟跑一次：

crontab -e */15 * * * * /usr/local/bin/sync_quark.sh

--transfers 1是故意限速为一个并发。夸克网盘对免费账号的请求频率比较敏感，并发一多容易触发风控，全任务直接失败。单路上传 10 分钟一个 150MB 的片段，100M 上行带宽下大概一两分钟就传完，稳定性和速度都能接受。

4.4 本地清理与容量策略

本地盘的清理逻辑就在上面那个脚本里：上传完成后，只保留 3 天内的录像，更早的直接删掉。这样本地磁盘永远只留最近 72 小时的数据，不会撑爆移动硬盘，也不影响回放（更早的去网盘翻就行）。

云端的清理策略要自己想清楚。免费空间有限，我目前的做法是：

• 网盘目录按日期建，例如监控录像/20250610/
• 每天用手机往网盘里翻一眼，确认前一天录像能播放，然后手工删掉更早的

如果你嫌手工麻烦，也可以用 alist 的 API 写定时清理脚本，但说实话不太建议在自己机器上跑太多常驻任务。丐版单板机每多一个进程，就多一个出问题的点。手工清理还有个额外好处：你会顺势检查一遍系统是否在正常工作，比等出问题再后悔强多了。

5. 回放体验：怎样快速翻到想看的那一段

5.1 三种回放方式

回放路径其实已经不需要自己搭服务了，有三条现成的路。

第一条，手机装夸克网盘 App，登录账号后进入“监控录像”目录，按日期翻目录，在线播放对应 mp4。夸克对 H.264 + AAC 视频的播放兼容性很好，重点是不限速下载，想看哪段可以直接下到手机里慢慢看。

第二条，局域网内直接打开 alist 的网页端，在文件列表里点 mp4 文件，新版 alist 自带在线预览。这个适合你在电脑上快速翻看，不用经过网盘服务器。

第三条，直接到单板机本地目录/mnt/record/拷文件。适合单板机就在手边、或者通过移动硬盘挂载访问的场景，省去一切中间环节。

5.2 目录命名让回放不迷路

分段录制最舒服的地方就是回放定位。我的结构是：

/mnt/record/ 20250610/ 20250610_000000.mp4 20250610_001000.mp4 20250610_002000.mp4 ...

文件名里的_001000就是这段录像的开始时间。想回看 2025 年 6 月 10 日早上 8 点 35 分发生的事，直接打开20250610_083000.mp4就行，最多往后拖 10 分钟。这种定位方式不需要任何数据库，比很多商业监控 App 里的时间轴还直观。

5.3 免费空间的压缩取舍

前面容量账算过了，免费空间撑不住无限全量。在预算为零的前提下，我的取舍建议是：

• 摄像头编码固定成 H.264，码率上限设为 1Mbps（720P），画质能看清人形和车牌就够用
• 如果只关心夜间，可以在 record.sh 里加个时间判断，21 点到次日 6 点用更高码率录主码流，其他时间只录低码流
• 如果摄像头有移动侦测报警功能（大部分丐版都有），可以只在报警时录一小段，但这需要摄像头配置 FTP 推送或 ONVIF 事件，折腾成本略高，新手可以暂时跳过

我自己试过一段时间的“全时段 1Mbps + 事件高码率”组合，体验还不错。录像体积降了 60%，回放需求一点没减。

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

6.1 问题速查表

6.2 两个真实翻车现场

第一次翻车发生在设备装好后的第二天。我用的 WiFi 摄像头放在客厅角落，单板机在书房，中间隔了两堵墙。录像文件在本地能生成，但经常出现 20 到 40 分钟的断档，ffmpeg 日志里全是Could not demux和重连记录。查了一圈，根本不是软件问题，是 2.4GHz 信号在墙之间反复失联。最后把摄像头挪到了路由器直连网线附近，插上 PoE 供电的转接头，断档问题直接消失。所以：能上有线就上有线，实在不行的，至少把摄像头和单板机放在同一个 AP 下。

第二次翻车在网盘端。跑了一个多月，某天突然发现 rclone 日志里全是HTTP 401。我一度以为是 alist 挂了，后来才想起夸克的 Cookie 过期了。重新抓 Cookie、更新、保存，系统恢复。这之后我养成了两个习惯：每两周手动登录一次夸克网页端，顺便看眼目录里有没有新文件；在 sync 脚本里加了文件缺失告警，连续两轮同步无新文件就往日志里打 ERROR。

6.3 安全上的几条死线

整套系统隐私浓度很高，摄像头对着家里，录像进了网盘，这里有三条规定我必须强调：

第一，摄像头的默认密码必须改，出厂 admin/admin 等于没设密码。同时关闭乞丐版摄像头自带的 P2P 云通道，也就是厂商 App 里那个“远程访问”开关，只要你这套系统能自己回放，就不需要厂商服务器当二道贩子。

第二，不要把摄像头的 RTSP 端口、alist 管理面板端口映射到公网。我见过很多人图方便在路由器里做端口转发，结果就是把自己的监控流裸奔给全网扫描器看。你要远程回放，用夸克 App 就够，根本不需要直接访问摄像头。

第三，夸克 Cookie 要当密码一样对待。alist 后台里存着完整 Cookie，谁拿到它谁就能操作你的网盘。别在公网面板里留默认密码，别用同一个账号在不可信设备上登录，有条件就开两步验证。

7. 写在最后：这套系统还能往哪走

这套自建系统我已经稳定跑了三个多月，中间只换过两次夸克 Cookie、重刷过一次系统。最大的感受不是省了多少钱，而是录像终于不看厂商脸色了：本地盘和网盘双保险，任何一端挂了另一端还能兜底，回放再也不用拔卡。

最后分享一个小技巧：第一次跑通之后，别急着把所有参数调到位。先让系统裸跑两天，观察录像文件大小、上传耗时、网盘剩余空间，再根据实际情况决定是不是要降码率、改切段时间。监控系统最怕的不是配置低，而是调得太满没有余量。留一点带宽和空间余量，这台吃灰的单板机才能一直稳定跑下去。