一次救援任务引发的服务器架构思考
2026年6月，北京的夏天热得让人烦躁。我接到一个紧急任务：一家做车载监控的创业公司，核心的“救援汽车服务器”连续三天在凌晨3点自动宕机，客户车队几十辆救援车的数据全部中断。老板急得跳脚，因为他们的业务就靠这个——车辆实时定位、车内视频回传、救援指令下发，全绑在这台服务器上。
我到了现场，发现他们的服务器配置看着挺唬人：双路 Xeon、128GB 内存、NVMe 阵列。但一问才知道，他们用的流媒体服务器是海康威视的 ISAPI 方案，而且是自己对照着网上教程瞎配的。老板觉得“搭建云服务器配置”这事，不就是买个腾讯云轻量机，装个系统，完事。结果真到生产环境，全崩了。
海康流媒体服务器的错误用法：不是装了就能跑
先说他们最头疼的“海康流媒体服务器用法”。很多人以为把海康的 SDK 装好，URL 填上去就能推流。但他们犯了一个致命错误：没有做流媒体分发层。
海康摄像头本身是 RTSP 流，但直接让客户端去拉摄像头的流，带宽和连接数瞬间爆炸。他们车队有 200 辆救援车，每辆车 4 路摄像头，高峰期同时有 50 辆车在线。等于同时要处理 200 路 RTSP 流——这台单机服务器根本扛不住。
正确的做法是：用海康流媒体服务器做“转码+分发”。在上层部署一个负载均衡，把 RTSP 流转成 HLS 或 FLV，然后通过 CDN 或者边缘节点推给客户端。但他们直接让海康服务当网关用，结果就是内存泄漏、CPU 打满、最终崩溃。
更坑的是，他们居然把海康流媒体服务装到了系统盘上。日志文件一天能写 20GB，三天就把 120GB 的 C 盘撑爆了。救援汽车服务器就这么活活被日志塞死的。
搭建云服务器配置的三大坑：IOPS、网络和监控
聊到“搭建云服务器配置”，这家公司选的是某云厂商的通用型实例。但车载业务是典型的 I/O 密集型 + 网络突发型。他们买了 8 核 16G，结果磁盘是云硬盘，IOPS 上限只有 2600。多路视频同时写入时，磁盘队列深度直接飙到 100+，系统响应延迟从 5ms 跳到 5 秒。
第二个坑是网络带宽。他们买的云服务器是 50Mbps 峰值。200 路 1080p 视频流，码率 2Mbps 打底，理论上需要 400Mbps。但他们的业务是“救援汽车服务器”——救援任务不常有，平时只有少量车辆在线。所以他们的算盘是赌“峰值不会同时发生”。但实际情况是，凌晨所有车辆返回停车场后，自动上传全天录像，200 辆车同时上传，50Mbps 瞬间被打满，再次宕机。
我的建议：要么用竞价实例做弹性伸缩，要么直接上裸金属。对于这种有突发存储需求的业务，云服务器的“共享型”配置就是定时炸弹。
FTP 与服务器连接配置：不要忽视 passive 模式
他们另一个痛点：摄像头抓拍的照片通过 FTP 上传到服务器，但总是超时失败。我检查了一下 FTP 配置，很简单的问题——但很多人都会掉坑。
他们的海康 NVR 用的是 FTP 主动模式，但云服务器在 NAT 后面，防火墙只开放了 21 端口。主动模式下，数据连接是从服务器 20 端口连回客户端的随机端口，但云服务器根本没有暴露 20 端口。
正确的“ftp与服务器连接配置”做法：用被动模式（PASV），并且把云服务器的被动端口范围（例如 50000-50050）开放，同时在 FTP 服务端指定公网 IP。这样客户端才能通过云服务器的被动端口建立数据连接。
另外，他们用的 FTP 服务器软件是 vsftpd，但配置里没有设置 chroot 限制。客户端一旦连接，就能遍历整个文件系统——这次是同事发现了，否则敏感的车载录像就全裸奔了。
CF 动不动就断开服务器：不是 Cloudflare 的锅
最后聊聊“cf动不动就断开服务器”。这家公司用了 Cloudflare 做 CDN 和 DDoS 防护。但频繁出现连接断开，用户端报 521、522 错误。
排查后发现，问题出在 SSL 和源站超时配置上。他们开启了 Cloudflare 的“全严格”SSL 模式，但源站服务器的 Nginx 配置的 SSL 证书是自签名的，且 TLS 版本只支持 1.2。Cloudflare 边缘节点在回源时，尝试使用 TLS 1.3 握手，发现不支持就直接断连了。
根本原因还是“搭建云服务器配置”时没配好 SSL。我让他们改成了“灵活”SSL 模式（Cloudflare 到用户加密，到源站不加密），先验证业务是否正常。然后才重新配置了 Let‘s Encrypt 的合法证书，并且让 Nginx 支持 TLS 1.2 和 1.3。之后 CF 就再也没断过。
另一个发现是他们的 cloudflare 配置里设了 100 秒的超时，这远远超过了默认值。很多反向代理无法维持那么长的连接，中间某个节点超时，客户端就收到断连。正确的做法是用 WebSocket 或者 SSE 来维持长连接，而不是无限拉长 HTTP 超时。
这次救火给我的三点教训
经过三天两夜的调试，我们最终把整套“救援汽车服务器”架构重写了。核心改动包括：
- 海康流媒体服务器只做转码，不做分发；上层加了一层 WebRTC 转推服务，用 Go 写的，压测 500 路流无压力。
- 云服务器配置从通用型换成了计算增强型，磁盘换成了 ESSD PL2，IOPS 提到 10000+；并且搭建了 NFS 共享存储，防止单点扩容问题。
- FTP 全部切换到 SFTP，配合被动模式，并做了白名单 IP 限制。
- Cloudflare 那边我们用了 Argo Tunnel，完全避免了公网 IP 暴露和端口冲突问题，SSL 断连问题也迎刃而解。
说实话，这类问题在中小团队里太常见了。大家总觉得“组装零件-插上电-就能跑”，但实际上一台服务器的稳定性取决于你对每一项配置的理解深度。特别是像“救援汽车服务器”这种涉及多个技术栈（流媒体、云、FTP、CDN）的业务，任何一个环节的短板都会导致连锁灾难。希望我的这次经历，能让正在踩同样坑的人少走一次弯路。