大华摄像头WEB播放方案：从RTSP到HTTP-FLV的低延迟实践

1. 先搞明白摄像头出流方式：设备侧的协议底牌

做WEB播放，第一个绕不开的问题就是：摄像头到底能给你什么流。很多新手上来就拿着播放器去拉RTSP地址，一拉一个不吱声，然后跑来问为什么黑屏。其实大华的摄像头出货时，默认是通过RTSP、ONVIF、私有SDK这几条路子对外输出视频的，而WEB页面能直接消费的，并不是RTSP，这里面的鸿沟就是整套方案的起点。

1.1 大华摄像头常见的取流协议

先看一张我整理的协议对比，这是你选型前必须想清楚的底牌：

大华摄像头通常只说自己是支持RTSP和ONVIF的。ONVIF是用来做设备发现、参数配置、云台控制的，虽然它也定义了媒体流传输，但在实际项目中我基本只用它拿RTSP地址，不会直接拿ONVIF流去喂浏览器。真正干活的，就是RTSP。

大华RTSP地址格式长这样：

rtsp://用户名:密码@IP地址:554/cam/realmonitor?channel=1&subtype=0

这里面有四个关键参数：channel是通道号，默认1；subtype是码流类型，0表示主码流，1表示子码流。主码流分辨率高、码率高，适合录像和放大查看；子码流分辨率低、码率低，适合多画面预览和网络受限的场景。我第一次做大屏项目时直接用了主码流，结果页面开了8路以后CPU直接飙到90%，后来全部切到子码流才压下来。

1.2 大华摄像头的鉴权机制：为什么总是弹“dsh web authentication required”

不少人在开发中遇到过这个提示：dsh web authentication required; reopen the url printed by dsh web.我先解释一下它的来历。这是大华设备HTTP管理页面的一套认证逻辑，当你在浏览器里直接访问摄像头IP的80端口、或者通过某些方式内嵌了设备页面时，设备会校验一个凭证。如果你跳过了登录、或者认证上下文丢失，它就会给你弹出这句话。

很多人看到这个提示，以为是自己代码写错了，其实不是。这个提示一般出现在你直接用浏览器打开了摄像头管理页，或者用iframe把设备主页嵌进了自己的系统里。大华设备的管理页面本身有自己的一套会话机制，而且它没打算让你随便嵌到别的系统里。

这里就要说到一个核心开发原则了：永远不要在WEB页面里直接内嵌摄像头的管理界面，也不要直接让浏览器去访问设备的RTSP地址。浏览器的播放器组件，无论是video标签还是mpegts.js，都没法在请求里附加RTSP的鉴权头。就算你通过改URL塞用户名密码，也会碰到跨域、兼容性等问题，而且等于把设备密码明文暴露在页面上，安全上完全不合格。

正确的思路是：让后端去跟摄像头握手、取流、做鉴权，然后把已经处理好的、浏览器能消费的流地址分发给前端。这就是整个方案设计的核心原则：前端不碰设备，只碰流媒体服务。

2. 主流WEB播放方案横向对比：没有银弹，只有取舍

搞清楚了摄像头这边的出流方式，下一步就是选播放方案。我在项目里见过的方案大致可以分成四类，每一类都有它存在的理由，但也都有自己的坑。

2.1 大华官方插件方案：老项目最后的倔强

最早做WEB播放大华摄像头，基本都是走官方插件路线。大华提供了WebPlugin、DHPlayer一类的ActiveX/NPAPI插件，直接嵌在浏览器页面里，通过私有协议从设备拉流渲染。那个年代浏览器还是IE的天下，插件方案确实能用。

但现在我基本不推荐新项目选这条路。原因有三个：第一，Chrome从45版本开始彻底移除了NPAPI支持，Edge、Firefox也都不再支持这种插件，你只能在IE模式或者老版本浏览器里跑，体验非常糟糕；第二，插件本身有安全漏洞，很容易被扫描工具盯上，这跟你做WEB安全的方向是背道而驰的；第三，插件是厂商私有协议，后续一旦浏览器更新或者系统升级，兼容性问题会让你疲于奔命。

这个方案唯一还残留的场景，就是某些老旧的智能制造、电力配电房里，客户的内网环境还是Windows 7 + IE，改造周期又很长，只能先用插件顶着。如果你是新项目，可以直接跳过它。

2.2 后端转码/转封装方案：最稳妥的常规解

这是目前的主流方案，核心思路是：在后端部署一个流媒体服务，由它去拉摄像头的RTSP流，再转换成浏览器能播放的格式分发给前端。根据输出格式的不同，主要有三条分支：

1. HTTP-FLV分支：延迟1~3秒，配合mpegts.js或flv.js可以在所有现代浏览器播放，缺点是iOS Safari原生不支持FLV，但在移动端你通常可以用HLS兜底。
2. HLS分支：兼容性最好，iOS/Android/PC通吃，但是延迟高，切片+播放器缓冲通常要5~15秒，不适合需要实时操控的场景。
3. WebRTC分支：延迟最低，200~500毫秒级别，但工程复杂度高，服务端要部署媒体协商和UDP转发能力，前端也要处理ICE、SDP这些概念。

对于大多数监控、安防、智慧园区大屏这类场景，HTTP-FLV是性价比最高的选择。延迟控制在1~3秒，普通人看监控完全感觉不到卡顿，工程难度又比WebRTC低一个数量级。HLS更适合做回放、录像片段播放，或者面向iOS的兼容兜底。

2.3 纯前端硬解方案：看着美，做起来累

有些同学会问：能不能后端只转发裸数据，前端用WebAssembly解码？理论上可以，社区里也有jsmpeg、Broadway这类项目，它们能把H.264裸流在浏览器里用WASM解码播放。实际做起来你会发现坑很多：性能开销大、多路时CPU直接爆掉、H.265解码支持不完整、音频处理更麻烦。

还有一条路是WebRTC原生播放，让流媒体服务直接把RTSP转成WebRTC流。这个方向延迟很诱人，ZLMediaKit等开源项目也已经支持了WebRTC输出，但部署和调优门槛确实高一些。如果项目对延迟极其敏感，比如无人机图传、远程操控场景，可以考虑；如果只是安防监控，我个人建议先走HTTP-FLV把业务跑通再说。

2.4 云端P2P方案：公网场景的特效药

如果摄像头在公网环境，或者没有固定IP，又不想自己折腾流媒体服务器，可以考虑大华乐橙云（Lechange）这类云平台方案。摄像头连上云端，云端提供P2P或者转发通道，前端接入SDK或者开放接口就能播放。

这个方案的好处是省去了自己部署和维护流媒体服务的成本，适合中小型项目快速上线。代价也很明显：流量费、通道费是持续成本，视频数据要过第三方平台，对数据敏感的项目可能过不了合规这关。所以我的判断是：内网项目优先自己部署流媒体服务，公网、快速交付项目才考虑云P2P。

3. 推荐架构：ZLMediaKit + FFmpeg + mpegts.js 的低延迟实践

如果你决定自己搭一套，我最推荐的开源组合是：ZLMediaKit做流媒体服务，FFmpeg做必要的转码，前端用mpegts.js拉HTTP-FLV播放。这套方案不依赖商业SDK，部署简单，社区活跃，踩坑资料也容易搜。

3.1 整体架构与原理解释

整个链路是这样的：

大华摄像头(RTSP) ↓ 后端拉流 ZLMediaKit(流媒体网关) ↓ 输出HTTP-FLV 前端mpegts.js播放

ZLMediaKit在这条链路里做了三件关键的事：一是把RTSP源通过流代理（StreamProxy）拉进来，二是把原始流重新封装成浏览器能消费的格式，三是提供了HTTP/WebSocket协议的访问入口给前端。它内部处理了RTSP的鉴权、时间戳、音视频同步这些脏活累活，这是我们从零写代码很难做到的。

这里有一个很重要的设计决策：为什么不让FFmpeg直接转推，而是用ZLMediaKit做网关？因为ZLMediaKit本身就是为流媒体场景设计的，它知道怎么处理连接断开、重连、多路并发、GOP缓存这些问题，而FFmpeg是个一次性的转码工具，丢给它是真的会丢流。我的习惯是：ZLMediaKit负责拉流和转发，FFmpeg只在需要转码的时候才介入。

3.2 部署ZLMediaKit：从下载到跑通拉流

ZLMediaKit的部署有两种常用方式，一是官方Release包直接跑，二是Docker。如果你只是想快速验证，我建议直接下Release包，因为Docker里有时候网络映射端口没配好会绕弯路。这里以Linux环境为例。

下载解压后，目录里有一个config.ini，这是所有配置的入口。关键要确认这几个配置项：

[general] enable_https=0 enable_vhost=1 [rtsp] port=554 sslport=0 [http] port=8080 sslport=0

[rtsp]里的端口是ZLMediaKit作为流媒体服务对外提供RTSP拉流的端口，[http]里的端口是对外提供HTTP-FLV/API访问的端口。注意如果摄像头本身也在用554端口，两个服务在同一台机器上会冲突，建议把ZLMediaKit的RTSP端口改成10554或者别的未占用端口。

配置好以后，在命令行启动服务：

./MediaServer -d -c config.ini

-d表示后台运行，-c指定配置文件。启动日志里看到start server successfully就说明起来了。

接下来要通过RESTful API添加一个流代理，让ZLMediaKit去拉摄像头的RTSP流。ZLMediaKit提供了一套HTTP API，端口默认是http_port/index/api/。调用addStreamProxy接口：

curl -X POST 'http://127.0.0.1:8080/index/api/addStreamProxy' \ -H 'Content-Type: application/json' \ -d '{ "vhost": "__defaultVhost__", "app": "live", "stream": "cam01", "url": "rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=1" }'

参数含义：app相当于一个分组名，你可以按项目或者区域来分；stream是流ID，前端访问时就是靠这个名字定位的；url是摄像头原始RTSP地址。调用成功后会返回一个key，随后ZLMediaKit就会自动去连接摄像头并拉流。

拉流成功后，你就可以直接用播放器验证一下这条流能不能出画面。在浏览器里用VLC的“打开网络串流”访问下面这个地址：

http://服务器IP:8080/live/cam01.live.flv

能出画面，说明整条链路已经通了。这个FLV地址就是前端播放器要消费的地址。

3.3 FFmpeg转码：什么情况下才需要

ZLMediaKit默认是直接把摄像头流转发出来的，它不做格式转换。如果摄像头输出的是H.265编码，而你的前端播放器或者浏览器环境不支持硬解，页面就会黑屏或者花屏。这时候就需要FFmpeg介入做转码。

最常见的情况是：大华的摄像头主码流默认可能输出H.265，子码流是H.264。对WEB播放来说，优先让摄像头输出H.264，能不改编码就不改编码。只有当你必须使用主码流、且摄像头不支持改成H.264输出时，才考虑转码。

如果确实需要转码，可以用FFmpeg把RTSP转RTMP推到ZLMediaKit：

ffmpeg -rtsp_transport tcp \ -i "rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0" \ -c:v libx264 -preset ultrafast -tune zerolatency \ -c:a aac -f flv rtmp://127.0.0.1:1935/live/cam01_h264

解释一下几个关键参数：

• -rtsp_transport tcp：强制走TCP拉流，避免UDP方式在复杂网络环境下丢包花屏。这个参数非常重要，我几乎每次都会加。
• -preset ultrafast -tune zerolatency：这两个参数都是为了保证低延迟。ultrafast牺牲一部分压缩率换取编码速度，zerolatency避免编码器为了压缩率引入额外缓冲。
• -f flv rtmp://...：转成FLV封装推到ZLMediaKit的RTMP端口（默认1935）。ZLMediaKit收到以后，前端访问http://服务器IP:8080/live/cam01_h264.live.flv就能拿到H.264的流。

要注意，转码是CPU大户。一台8核的服务器，转码1080P视频大概能撑8~15路，转码720P大概能撑30路左右。在做并发规划时，一定要把转码路数算进去，不然上线之后就是一场灾难。

3.4 前端播放：mpegts.js接入代码

前端部分，我推荐用mpegts.js来播放HTTP-FLV流。它比flv.js维护更积极，对现代浏览器的支持也更好。通过npm安装：

npm install mpegts.js

然后是一个最简的播放器初始化代码：

import mpegts from 'mpegts.js' const videoElement = document.getElementById('video') if (mpegts.isSupported()) { const player = mpegts.createPlayer( { type: 'flv', isLive: true, url: 'http://服务器IP:8080/live/cam01.live.flv', }, { enableStashBuffer: false, liveBufferLatencyChasing: true, } ) player.attachMediaElement(videoElement) player.load() player.play() }

两个配置项值得说明一下。enableStashBuffer: false会禁用播放器的缓冲池，让数据尽量及时吐给渲染器，对降低延迟很有帮助。liveBufferLatencyChasing: true表示当延迟累积时主动追赶，避免长时间播放后画面越来越慢。

如果你用的是Vue，需要特别注意一个坑：在mounted或者onMounted阶段再初始化播放器，确保video元素已经挂载到DOM上。否则attachMediaElement会报错。组件卸载时记得调用player.destroy()，否则会一直占用资源和连接，多路播放时尤其明显。

另外一个很影响体验的细节是：默认的subtype=0主码流在1080P甚至4K情况下，前端解压渲染的压力非常大。如果页面是九宫格预览或者大屏展示，我建议默认取subtype=1子码流，需要查看细节时再切换到主码流。子码流看起来有点糊，但九宫格场景下完全够用，CPU占用率能下降一半以上。

3.5 鉴权与服务化设计：别把密码写在页面里

有人图省事，直接把带用户名密码的RTSP地址嵌在前端代码里，让播放器去拉流，这在生产环境是大忌。一方面，浏览器播放器根本无法正确处理RTSP协议和鉴权，另一方面，等于是把设备密码明文送给了所有能打开页面的人。

我的做法是：摄像头IP、用户名、密码这些敏感信息只存在于后端配置里。前端拿到的播放地址是ZLMediaKit的HTTP-FLV地址，而且这个地址尽量不要固定不变。可以在后端做一个地址签发接口，每次返回一个带签名参数的临时地址，设置过期时间，这样即使地址泄露了，也很快失效。

ZLMediaKit本身也支持播放鉴权回调。在config.ini里开启enable_play_auth，并配置回调地址，当播放器请求播放时，ZLMediaKit会用HTTP POST的方式回调你的后端接口，由后端判断这个会话是否合法、是否过期、有没有权限。这套机制一定要用上，它比你自己在后端写拦截可靠得多。

4. 实操过程：5分钟拉通一条摄像头画面

光讲理论容易飘，我带你走一遍完整的实操过程。假设你手上有一台大华摄像头，IP是192.168.1.100，用户名admin，密码你自己设的，现在要在一台CentOS服务器上把画面拉到WEB页面里。

4.1 前置准备与网络排查

动手之前，先把以下三件事确认了，能省掉后面90%的排障时间：

第一，摄像头和服务器之间网络是否互通。最简单的方法，在服务器上ping一下摄像头IP。ping不通的话，大概率是网段隔离或者防火墙拦了，先去查网络。

第二，确认摄像头的RTSP服务是否开启。用VLC软件，打开“网络串流”，输入rtsp://admin:密码@192.168.1.100:554/cam/realmonitor?channel=1&subtype=1，如果能出画面，说明RTSP正常。这一步非常关键，它把问题范围限定在了“摄像头侧”还是“你自己搭的服务侧”。

第三，检查端口。摄像头侧要通TCP 554（RTSP），服务器侧要通8080（HTTP-FLV）和1935（RTMP，如需转码）。用telnet 192.168.1.100 554这种方式挨个确认。

这里有个我踩过的坑：大华摄像头默认的RTSP端口不一定是554，有些型号或者被改过配置后可能用的是其他端口。如果VLC连不上，去摄像头管理页面里翻一下网络设置，看看RTSP端口到底是什么。

4.2 部署ZLMediaKit并拉流

按照3.2节的方法下载ZLMediaKit并启动，然后调用addStreamProxy接口添加流代理。这里补充一个实际操作细节：大华摄像头密码里如果包含特殊字符，比如@、:、/，在RTSP地址里必须做URL编码，否则解析会出错。比如密码是abc@123，地址里的密码要写成abc%40123。

添加成功后，最直接的验证方式是用FFplay或者VLC拉取ZLMediaKit输出的FLV地址：

ffplay "http://服务器IP:8080/live/cam01.live.flv"

这里要注意，FFplay拉FLV地址时，如果ZLMediaKit的HTTP端口没有对外开放，或者有防火墙拦着，就会失败。如果这一步失败了，优先检查508端口（ZLMediaKit默认的RTSP端口）和8080端口是否通了。

4.3 前端页面接入（附代码示例）

前端最简单的接入方式是直接用原生JS写一个HTML文件，本地打开就能看，不用引入庞大框架。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>摄像头实时预览</title> <style> video { width: 640px; height: 360px; background: #000; } </style> </head> <body> <video id="video" controls muted autoplay></video> <script src="https://cdn.jsdelivr.net/npm/mpegts.js@1.7.3/dist/mpegts.js"></script> <script> const videoElement = document.getElementById('video') if (mpegts.isSupported()) { const player = mpegts.createPlayer( { type: 'flv', isLive: true, url: 'http://服务器IP:8080/live/cam01.live.flv', }, { enableStashBuffer: false, liveBufferLatencyChasing: true, } ) player.attachMediaElement(videoElement) player.load() player.play() // 断线重连处理 player.on(mpegts.Events.ERROR, () => { setTimeout(() => { player.unload() player.load() player.play() }, 3000) }) } </script> </body> </html>

muted autoplay是必须的，现代浏览器不允许带声音自动播放，这是浏览器的自动播放策略，不是你的代码问题。如果是多路画面，你可以写一个循环来为每一个video元素创建独立的Player实例。

多路播放时还有一个容易被人忽视的问题：同一页面里同时创建太多Player实例，内存会涨得很快。我在一个项目里试过同时开16路，单页内存直冲2GB，后来通过“只有可见画面才创建实例，切到后台就销毁”的方式优化，内存降到了原来的四分之一。如果你的项目是大屏监控墙，一定要做类似的资源管理。

4.4 实测效果与性能数据

基于我多次实战的统计，给一个普遍参考值：一台8核16G的服务器，跑ZLMediaKit不转码，纯做HTTP-FLV转发，稳定支撑50路以内的并发播放没什么压力；如果需要FFmpeg转码，1080P转720P大概能扛10路左右，720P转480P大概能扛30路左右。这个数据受CPU型号、码流大小、播放端解码能力影响，但可以作为前期容量规划的起点。

延迟方面，局域网内跑HTTP-FLV，摄像头的编码延迟加网络延迟加播放器缓冲，实测一般在1~2秒。这个数据对安防监控、工厂巡检这类场景完全够用。如果你要更低延迟，就得走WebRTC，但工程复杂度上去了，建议先评估业务是否真的需要。

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

做这类项目，你一定会遇到各种报错。我把自己踩过的坑和排查思路整理出来，遇到问题按这个顺序查，能省掉很多无头苍蝇式的时间。

5.1 报错“could not register service worker: invalidstatee”怎么处理

这个报错我在项目里遇到过几次。它一般出现在两个方面：一是浏览器在访问某些页面时尝试注册Service Worker但失败了，二是你在内网用IP地址访问部署的页面，而Service Worker要求必须是安全上下文。处理方式分两层：

第一，如果这个报错来自你自己项目引入的第三方库，比如PWA相关代码，可以检查一下是不是在localhost之外的环境注册了Service Worker。生产环境如果要上Service Worker，必须配置HTTPS证书，用IP访问是不行的。

第二，如果这个报错来自流媒体服务的Web播放页面，比如ZLMediaKit或者大华设备自身的Web页面，不一定影响主流程，可以先忽略，重点看视频能不能正常出画。

还有一个相关的问题是：FLV地址用IP访问时，浏览器会认为它不是安全上下文，某些API（比如Web Crypto、Service Worker）会被限制。但是播放HTTP-FLV本身不依赖安全上下文，所以通常不影响。不过如果你后续需要把Camera页面和内网系统整合，最好还是统一走HTTPS域名，能少踩很多浏览器的怪问题。

5.2 大华摄像头连接RTSP超时或频繁掉线

这个问题的排查顺序是这样的：先用VLC在服务器本机拉RTSP，确认摄像头能正常出流。如果VLC也拉不出，说明问题在摄像头侧，去管理页面检查RTSP服务是否启动、账号密码是否正确、连接数是否已满。

大华摄像头对并发RTSP连接数有上限，一般是主码流和子码流各有限制，通常在10~20路之间。如果你的系统很多人在看，超过了连接数限制，摄像头就会拒绝新的连接。解决方法是加上流媒体服务器，所有前端都从ZLMediaKit拉流，而不是直接连摄像头。ZLMediaKit对同一个源会做多路复用，它能同时给很多前端提供播放，但到摄像头的RTSP连接只有一条。

还有一种RTSP频繁掉线的情况，是因为网络不稳定，UDP方式丢包严重。我的建议是在所有涉及RTSP拉流的环节都强制走TCP。FFmpeg加-rtsp_transport tcp，ZLMediaKit的流代理里也建议把RTSP的传输方式配置为TCP。

5.3 页面弹“dsh web authentication required”怎么破

回到开头那个报错。如果你在开发时用iframe把大华摄像头的管理页面嵌进了自己的系统，就会出现这个提示。它本质上是大华设备的Web认证跳转逻辑，不是流媒体服务的问题。

我的建议是彻底放弃“iframe嵌入设备页面”这个想法。你需要的是播放视频流，不是把整个摄像头管理后台搬进你的系统。正确的做法是：用流媒体服务拉RTSP转HTTP-FLV，前端用mpegts.js播放，摄像头管理页面的功能（比如云台控制、参数配置）通过大华的ONVIF协议或者HTTP API在后端封装，不要试图在前端直接操作设备页面。

如果你确实需要跳转到摄像头自己的配置页面，那就让用户在新标签页打开，不要用iframe嵌套。这样既避开了认证问题，也避免了设备的Cookie跟你的系统互相污染。

5.4 前端播放黑屏/花屏/卡顿

黑屏花屏是WEB播放里最常见的现象，原因往往集中在以下几点：

第一，编码格式不兼容。前面说过，H.265在浏览器上的支持比较有限，如果摄像头输出H.265，而你没有做转码，播放器就会拿不到可解码的数据。解决办法：优先在摄像头侧把编码改成H.264，改不了的加FFmpeg转码。

第二，FLV时间戳异常。有些摄像头或者转码环节产生的FLV流时间戳是跳跃的，播放器会以此为依据做音视频同步，时间戳乱了就会出现花屏或者画面卡住不动。ZLMediaKit有自动修正时间戳的机制，但如果你绕过了ZLMediaKit直接给播放器喂流，就可能遇到这个问题。

第三，主码流过大。4K、800万像素的主码流，前端解压渲染扛不住，表现就是卡成PPT。优先切子码流，或者在后端做降分辨率转码。

第四，前端跨域被拦截。如果你的页面部署在http://page.example.com，FLV流地址在http://stream.example.com，就存在跨域请求。ZLMediaKit配置文件里有enable_cors=1，确保开启。如果你自己用Nginx转发，记得在Nginx配置里加CORS头。

5.5 多路播放资源爆炸怎么办

页面上同时播放多路画面，最怕的就是内存和CPU一起爆。除了在4.3节里提到的“按需创建播放实例”，还有几个小技巧：

把video元素设置成固定宽高，不要交给浏览器自动缩放；对每路画面做preload='none'或者autoplay策略；播放结束后调用player.destroy()释放资源。九宫格预览时，我习惯的做法是默认全部显示子码流，点击某一路需要放大时，再动态切换到主码流的FLV地址。这样浏览器的压力会小很多。

6. 安全加固与上线避坑经验

功能跑通只是第一步，上线之前的安全加固绝对不能省。尤其是摄像头这类设备，天生就是网络扫描器的重点目标，如果因为配置不当被攻击者利用，后果会很严重。

6.1 摄像头的安全风险与基线加固

大华摄像头的默认密码、初始密码这些事情，在交付时一定要作为强制项：确认所有摄像头都改了强密码，最好关闭不需要的端口和服务，尤其是公网环境。

部署架构上，摄像头、流媒体服务器、WEB服务应该放在不同的安全域里。摄像头和流媒体服务器放在内网VPC或者专网里，WEB服务可以放在DMZ区，但不要直接把摄像头的管理端口暴露到公网。所有流向摄像头的请求，都应该先经过流媒体服务器的代理，而不是让前端直接访问设备IP。

如果你用的是云服务器，安全组规则务必只放行必要的端口：8080（HTTP-FLV）、554或自定义RTSP端口（仅允许内网流量访问）、80/443（WEB服务）。不要图省事开“全部端口”，那样基本等于把设备裸奔在公网里。

6.2 播放地址防盗链与临时授权

前面提到过，play地址不能是固定的，一定要做防盗链。具体做法有两层：

第一层，后端签发短期有效的播放地址。可以是带过期时间的token参数，ZLMediaKit支持在流地址上附加签名参数，后端负责校验。地址过期后自动失效，即使被转发出去也没用。

第二层，开启ZLMediaKit的播放鉴权回调。在config.ini里配置：

[hook] enable=1 on_play=http://你的后端地址/api/zlm/on_play

当播放请求进来时，ZLMediaKit会POST一个事件到你的后端，后端通过校验Cookie、token或者业务逻辑，决定是否放行这次播放。这套回调机制非常关键，是生产环境必须开启的功能。

6.3 HTTPS与内网证书问题

现在浏览器对非HTTPS环境的限制越来越多。如果你把WEB页面部署在公网，直接上HTTPS，这是标配。如果你部署在内网，也建议用自建CA或者内网域名证书，否则Service Worker、麦克风、摄像头这些浏览器能力都会受限。

具体到播放场景，HTTPS页面去请求HTTP的FLV地址，属于混合内容，也会被浏览器拦截。所以要么页面和流媒体服务都走HTTPS，要么流媒体服务也对外提供HTTPS的FLV访问。ZLMediaKit的开源版支持SSL配置，可以加载你的证书文件；如果你用Nginx做反向代理，也可以在Nginx层终结SSL，再把请求转发给后端的8080端口。

实际操作中，我更倾向于用Nginx做一层统一入口：所有请求都走https://你的域名/，Nginx把/live/路径下的请求反向代理到ZLMediaKit的8080端口。这样证书、跨域、日志、限流都集中在Nginx这一层处理，ZLMediaKit只需要专心做流媒体转发就行。

最后分享一点个人体会

项目做多了以后，我对这类WEB播放方案最大的体会是：能不用插件就不用插件，能不改编码就不改编码，越是简单直接的链路，线上越稳定。我见过太多项目为了追求极低延迟或者极强功能，把架构搞得很复杂，最后反而被各种环境差异拖垮。

如果你要快速落地一个安防大屏或者监控对接项目，直接从“RTSP拉流 + ZLMediaKit转发HTTP-FLV + mpegts.js播放”这条链路开始，基本不会跑偏。等你把这条链路跑明白了，再根据业务需求去升级WebRTC、扩展录像回放、接入AI分析，都是水到渠成的事。