简介面向需要快速部署GB28181视频监控平台的技术人员这套wvp-GB28181-pro与ZLMediaKit集成安装脚本包将直装版程序与依赖环境打包在一起解决从零编译、环境配置繁琐的问题。压缩包共包含六个文件其中四个为脚本、一个为组件压缩包、一个为说明文档整体大小约为七百六十五兆字节。脚本分别负责数据库、缓存、运行环境及主程序的一键安装组件包内为媒体服务相关依赖文档则提供清晰的操作指引。正常使用场景下只需在平台配置文件中修改对接地址即可接入国标摄像头并启用全部功能极大降低部署门槛。目前已有两千五百五十三人学习下载适合安防监控集成商、运维工程师及视频平台二次开发人员作为开箱即用的搭建参考。1. wvp-GB28181-pro和ZLMediaKit的打包安装脚本把一套国标视频接入环境从一夜压缩到一刻钟接到一个园区视频接入需求现场几十台支持GB28181协议的摄像头要统一接入一个平台做实时预览和录像回放。新上的服务器啥都没有按老办法装先装JDK、MySQL、Redis再编译ZLMediaKit最后把wvp-GB28181-pro的jar包和SQL跑起来中间还得把SIP端口、媒体端口段、hook回调一条条对上。顺利的话一个晚上不顺利的话第二天继续。打包好的安装脚本解决的问题就是把wvp-GB28181-pro国标信令平台和ZLMediaKit流媒体服务连同它们各自的依赖一次部署到位。有一说一脚本解决的是“装好”不是“调好”设备侧的SIP参数和平台侧的ID、密码、媒体端口最终还是要你对齐。这篇文章适合做安防集成、视频上云、国标设备接入的交付和运维同学它能让你从手工搭环境里腾出手把精力放到更费设备的对接和排障上。2. 先分清信令和媒体wvp-GB28181-pro和ZLMediaKit在链路里各管哪一段2.1 GB28181的三件事决定了wvp的定位GB28181是一个基于SIP的国标协议。摄像头、NVR、平台在协议里都是SIP UA。wvp-GB28181-pro在Java里实现了一个SIP服务器并在此基础上做了三件核心事注册、目录、点播。注册是第一步。设备端配置一个SIP服务器地址、端口和ID启动后向平台发REGISTER平台回200 OK设备就“在线”了。目录是第二步平台下发查询目录的指令设备把它下挂的通道列表回传平台入库。点播是第三步用户在页面点一个通道wvp通过SIP INVITE通知设备“把流推到某某地址的某某端口”这个地址和端口不是wvp自己的而是ZLMediaKit提前占好的收流端口。理解这一点很重要。很多人部署完发现设备在线但不出流上来就查ZLMediaKit其实方向错了先查SIP INVITE有没有被回200再查设备有没有真的往目标地址推流。wvp管的是“说”ZLMediaKit管的是“收”和“转”链条必须先对。2.2 ZLMediaKit把“流到了之后”的所有事接管下来摄像头按INVITE里的地址推流过来后ZLMediaKit开始干活。它做的事情分几层先把RTP/RTSP流接住然后按需转封装成RTMP、HLS、HTTP-FLV、WebRTC等给前端播放同时可以按计划做录像也可以做多路分发一路进来几十路出去。ZLMediaKit经常被单独拿来当“拉流转推”的工具用但在GB28181这条链路里它的角色是“被动收流主动分发”。被动收流指的是设备主动往它的某个端口推主动分发指的是它把流用各种协议吐给播放端。你排查时如果发现播放端拉不到流先分清是哪一段断了设备有没有推上来ZLMediaKit有没有接住分发端口有没有监听。这三个问题用的命令完全不同。这个“接住”的动作在ZLMediaKit里叫RTP代理它会为每一路点播动态分配一个本地端口来接收媒体流端口从一个预设范围内取。这也是为什么部署脚本里不是开一个端口而是开一整段端口。2.3 三个接头SIP端口、媒体端口段、hook回调wvp和ZLMediaKit之间有三个“接头”接线没对齐平台就是半残的。接头所在服务常见默认配错后的表现SIP注册端口wvpUDP 5060设备注册不上页面一直离线媒体收流端口段ZLMediaKit10000-20000设备推流被丢播放黑屏hook回调ZLMediaKit 到 wvpHTTP接口需配secret流状态不更新录像上报丢失先说SIP端口它走UDP而且必须和设备端的配置一字不差。设备端填的SIP服务器ID、密码、端口和wvp里配置的要一致否则注册包到了也回不了200。第二个接头是媒体端口段。ZLMediaKit的RTP代理每接一路流就占一个端口所以脚本里要预留一个连续的UDP端口段。如果只放行一个端口第一路能看第二路必黑。第三个接头是hook。ZLMediaKit收到流、流断开、录像文件生成完之后会向wvp的一个HTTP接口发POST事件。这里有两样东西要对一是回调地址二是secret。地址错wvp收不到事件secret不一致wvp直接回401拒绝。提示wvp里配置的媒体服务地址填的是ZLMediaKit对外的地址千万别填127.0.0.1除非两个服务确实在同一台机器的同一个网络命名空间里。3. 安装脚本做了什么从检查环境到拉起服务一次手工部署被拆成几步3.1 第一步探测发行版和基础依赖常见安装脚本不会上来就装先做环境判断把系统版本、架构、可用内存打出来没通过就直接退出避免装到一半发现缺编译器。ZLMediaKit是C写的即使下release包也可能需要在本地编一部分动态库wvp是Java包要跑在JDK17这类环境上。依赖这一层脚本把gcc、g、cmake、openssl-devel、MySQL、Redis、Nginx一次性装齐。#!/bin/bash # 简单识别发行版并安装基础依赖 source /etc/os-release if [[ $ID centos || $ID rhel ]]; then yum install -y gcc gcc-c make cmake openssl-devel libstdc-static yum install -y mysql-server redis nginx elif [[ $ID ubuntu || $ID debian ]]; then apt-get update apt-get install -y build-essential cmake libssl-dev apt-get install -y mysql-server redis-server nginx else echo 不支持的系统: $ID exit 1 fi逻辑说明先读 /etc/os-release 拿发行版ID再走对应包管理器。CentOS系装的是 libstdc-staticUbuntu系装的是 libssl-dev两者名字不一样这是ZLMediaKit编译时最常见的两个依赖差异。这套脚本适合在全新机器上跑如果内网不能访问外网源就要给脚本加一个“离线模式”把rpm/deb包提前下好放进本地目录安装时直接指向本地源很多现场服务器其实是不通外网的这一步不是可选项。3.2 第二步端口规划和防火墙放行装完依赖不等于能跑端口才是第一个翻车点。部署脚本里会把端口定义成变量集中在脚本头部便于一次改完也便于交付时让客户一眼看到整个平台要开放哪些端口。# 端口规划统一放头部改一处生效 SIP_PORT5060 # GB28181 SIP 注册端口UDP WEB_PORT8080 # wvp 管理页面/API/WebSocket MEDIA_START10000 # ZLMediaKit RTP收流起始端口 MEDIA_END20000 # ZLMediaKit RTP收流结束端口 ZLM_API_PORT80 # ZLMediaKit RESTful API 端口 ZLM_RTSP_PORT554 # RTSP 分发端口放行策略建议写成函数避免在脚本里散落一地的firewall命令open_ports() { if command -v firewall-cmd /dev/null 21; then firewall-cmd --permanent --add-port${SIP_PORT}/udp firewall-cmd --permanent --add-port${ZLM_API_PORT}/tcp firewall-cmd --permanent --add-port${ZLM_RTSP_PORT}/tcp # 媒体端口段统一放行否则并发点播必炸 firewall-cmd --permanent --add-port${MEDIA_START}-${MEDIA_END}/udp firewall-cmd --reload fi }为什么媒体端口要一段而不是几个因为ZLMediaKit为每路流动态分配端口不是固定用某一个。把10000-20000整段放行看起来开销大实际上这些端口不是常开的监听端口是收到RTP包才占用不必担心安全面扩大太多。生产环境如果隔离要求高可以在防火墙里加源IP白名单只允许摄像头网段的IP访问媒体端口段。3.3 第三步初始化数据库和配置文件占位wvp的jar包里不直接带配置部署时把 application.yml 和 SQL脚本放到指定目录启动时加载。脚本常用做法是把配置里的IP、密码写成占位符再用sed替换成实际值这样模板文件和脚本逻辑可以分开维护。# 从模板生成真实配置 sed -e s|{{DB_HOST}}|127.0.0.1|g \ -e s|{{DB_PASSWORD}}|${DB_PASSWORD}|g \ -e s|{{SIP_ID}}|${SIP_ID}|g \ -e s|{{SIP_PASSWORD}}|${SIP_PASSWORD}|g \ -e s|{{ZLM_ADDR}}|${ZLM_ADDR}|g \ -e s|{{ZLM_SECRET}}|${ZLM_SECRET}|g \ application.tpl.yml application.yml # 灌初始化SQL mysql -uroot -p${DB_PASSWORD} init.sql这一步的几个参数要解释清楚DB_PASSWORD是初始化时给MySQL root设的密码脚本里应该先生成随机值再显示给用户SIP_ID是SIP域标识和设备端填的SIP服务器ID完全一致才能注册ZLM_SECRET是wvp和ZLMediaKit共享的密钥两边必须一样。模板文件的好处是版本升级时只改模板不用改脚本逻辑。SQL初始化注意wvp的初始化SQL是按MySQL 5.7/8.0的常见语法写的。如果你的MySQL是8.0以上默认认证插件是caching_sha2_password老版本依赖会有兼容问题。脚本里通常补一句ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY ${DB_PASSWORD};把认证方式兜底成原生密码避免Java连接池报认证错误。3.4 第四步用systemd托管两个服务启动顺序有讲究手工部署的另一个问题是没有守护进程一断平台就没了。脚本到这一步会为两个服务写systemd unit对运维来说后面开机自启、看日志都方便。一个典型的wvp服务文件长这样cat /etc/systemd/system/wvp.service EOF [Unit] Descriptionwvp-GB28181-pro Afternetwork.target mysql.service [Service] WorkingDirectory/opt/wvp ExecStart/usr/bin/java -jar /opt/wvp/wvp.jar --spring.config.location/opt/wvp/application.yml Restarton-failure RestartSec5 Userwvp [Install] WantedBymulti-user.target EOFZLMediaKit的服务文件类似ExecStart换成它的启动程序。启动顺序上脚本统一先起ZLMediaKit再起wvp。原因不是wvp依赖ZLMediaKit才能启动而是设备点播放是随时可能发生的你希望媒体服务先就位。两者都起来后脚本做一次端口探测systemctl daemon-reload systemctl enable --now zlm.service systemctl enable --now wvp.service sleep 5 ss -lunp | grep -E (:5060|:10000) || echo 端口未监听请检查失败原因这里的ss命令是验证脚本有没有真的把端口拉起来比用网页登录靠谱得多。wvp启动慢Java进程要JVM预热注册信令要等它打印“server started”之类日志才算真起来页面打不开不一定代表进程没启动别急着反复重启先看日志。3.5 第五步升级与回滚脚本里必须留的后悔药部署脚本只解决首次安装但交付现场迟早要升级。我建议脚本里直接带一个升级函数。动作很简单停服务、备份旧版本、覆盖新版本、起服务。关键是备份这一步别省而且备份的除了程序包还有当前配置文件。upgrade() { local app$1 local pkg$2 systemctl stop ${app} cp -r /opt/${app}/conf /opt/${app}/conf.bak.$(date %s) cp /opt/${app}/${app}.jar /opt/${app}/${app}.jar.bak.$(date %s) cp ${pkg} /opt/${app}/${app}.jar systemctl start ${app} }版本升级最容易翻车的地方是ZLMediaKit的config.ini跨大版本改格式。旧配置直接覆盖到新版本上启动时报“unknown option”所以升级脚本里ZLMediaKit的配置不自动合并而是保留旧配置新版本起来后按提示逐项确认。这个逻辑用三行注释写死在脚本里防止三个月后你自己也忘了当初为什么要这么写。4. 部署中最常见的五个坑现象、原因、解决4.1 设备注册不上SIP端口是UDP的防火墙只放行了TCP现象wvp页面设备列表一直空SIP日志里没有任何REGISTER请求。原因现场防火墙默认只放TCP端口而GB28181的SIP注册走的是UDP 5060。另一个常见原因是设备端填的SIP服务器ID和wvp配置的SIP域不一致注册包到了被wvp判定为非法来源不回应。解决先给防火墙加UDP 5060放行再登录摄像头核对SIP服务器ID、密码、端口三项。判断依据用tcpdump抓包最直接tcpdump -i any udp port 5060 -n抓到的包里要能看到设备IP发REGISTER。如果包出去了没回应查wvp日志里有没有鉴权失败的记录如果压根没包过来问题在设备配置或网络和平台无关。4.2 设备在线但拉流报401ZLMediaKit的secret和wvp不一致现象设备注册正常列表也看得到点播放时前端返回401wvp日志里出现secret错误。原因wvp配置里的媒体服务密钥和ZLMediaKit config.ini里的secret不一致ZLMediaKit的hook回调或鉴权被拒绝。解决把两边改成同一个随机字符串。改完先重启ZLMediaKit再重启wvp顺序反了会看到wvp还在用旧连接。这个secret默认值在生产环境一定要换掉——ZLMediaKit没有内置的访问控制secret就相当于它的钥匙默认值等于把钥匙挂门上。还有一层要留意ZLMediaKit的API端口反向代理到公网时secret会在请求头里明文传递务必给API端口做访问控制。4.3 播放黑屏媒体端口段没有放行设备推流被丢现象SIP的INVITE流程已经走完设备也回了200 OK但播放端一直黑屏或转圈ZLMediaKit看不到流。原因设备按INVITE里的地址往某个媒体端口推UDP流但那段端口没放行或者中间路由丢包。wvp没收到hook所以页面状态也刷不出来。解决把10000-20000的UDP段加入放行列表。判断时注意telnet测端口只能测TCPUDP要用nc -u测或者直接在ZLMediaKit日志里看有没有收到RTP包。这个翻车点最容易伪装成“设备不支持”或者“编码不对”实际只是端口被挡。4.4 播放结束后流状态不恢复hook回调地址写错现象录像文件其实已经生成但平台的录像列表拿不到播放挂断后页面上的状态不恢复成空闲。原因ZLMediaKit把“流变化”“录像文件生成”等事件POST到了错误的地址wvp压根没收到通知。最常见的是部署时把hook地址写成了127.0.0.1而wvp在另一台机器上。解决在ZLMediaKit配置里找hook相关设置把地址改成wvp的HTTP访问地址。ZLMediaKit日志里搜“hook”或“notify”能看到POST失败的记录。这个坑我踩过一整晚纯属玄学信令和媒体都正常就是业务状态对不上最后发现是回调地址少写了一个端口。4.5 Nginx反代后页面能开、播放器起不来WebSocket握手失败现象用Nginx反代wvp的8080端口后页面正常打开但播放器反复重连。原因wvp的播放器通过WebSocket拉取流状态和播放地址Nginx反代默认不转发Upgrade头握手直接失败。解决在Nginx的location里补两个头proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;加上之后重载Nginx再刷新页面。反代方案里还容易漏掉超时配置播放长走后端没有读操作默认60秒超时就把连接断了长连接场景要把proxy_read_timeout调大。5. 装完怎么证明它能用从注册到出流的验证5.1 信令在线看日志和抓包别只看页面页面显示“在线”有可能是假象。设备掉线后SIP的超时机制要等几个周期才判离线页面在这段时间里还显示绿色。可靠的判断是看wvp日志设备每注册一次都会打一条记录再严格一点就抓包。看注册状态用一条命令journalctl -u wvp -f | grep -iE register|REGISTER抓包看完整握手tcpdump -i any udp port 5060 -n -v正常的注册交互是设备发REGISTERwvp回401带挑战设备重新带鉴权信息再发REGISTERwvp回200 OK。如果你看到的交互停在401说明密码不对或SIP域不匹配这比看页面直观得多。5.2 媒体链路用ffplay绕过页面直连ZLMediaKit页面播放涉及wvp鉴权、WebSocket、浏览器解码等多层出错时不好定位。验证媒体链路最直接的办法是绕过wvp直连ZLMediaKit拉流。在wvp的播放接口返回里能找到流地址通常形如rtsp://IP:554/live/streamId直接用ffplay拉ffplay -i rtsp://127.0.0.1:554/live/your_stream_id如果ffplay能出画面问题不在ZLMediaKit往上查wvp到ZLMediaKit之间的地址配置如果ffplay黑屏再看设备有没有把流推到ZLMediaKit。登录ZLMediaKit的API调用getMediaList接口能列出当前所有存活流有流说明ZLMediaKit收到了没流说明设备根本没推上来问题又回到了SIP INVITE。5.3 录像和回放验证的是设备能力和平台调度的配合录像分两段。设备端录像由设备自己存平台通过SIP INVITE带回放参数时间范围、流ID去调平台录像由ZLMediaKit按计划录制落盘在ZLMediaKit的录像目录。验证时先做一轮平台录像配一个计划任务等约5分钟去ZLMediaKit的rec目录确认文件增长。再验证回放页面上选一个时间点发起回放看是否出画面和进度条是否可拖。录像文件时间戳对不上是时区坑。wvp的JVM、MySQL、ZLMediaKit如果用了不同时区录出来的文件名和检索时间会整体偏移。脚本里应该在三个服务启动前统一TZAsia/Shanghai减少这种查不明白的时间问题。6. 把安装脚本改造成运维基线版本锁定、健康检查和升级纪律脚本跑通了只是个起点我更推荐把它当运维基线来维护。血泪经验是版本锁定脚本里所有下载的包都要锁版本号或SHA别用latest。有一次部署时ZLMediaKit用了最新release配置格式变了老脚本生成的config直接不识别排查了一个下午。原因不复杂自动拉新版本配置格式向前不兼容。锁版本后每次升级走单独流程问题就好控制了。再补一个健康检查函数。运维不是装完就跑要能随时知道两个服务活着health_check() { curl -sf http://127.0.0.1:80/index/api/getServerConfig -H secret: ${ZLM_SECRET} /dev/null echo zlm ok curl -sf http://127.0.0.1:8080/ /dev/null echo wvp http ok }如果后面还要扩展比如把AI识别yolo那类事件检测接进平台ZLMediaKit的流事件hook和wvp的录像回调都能作为事件源把视频帧交给算法容器做异步分析。但那是后话前提是当前这套部署基线够稳、升级可复现。我曾经图省事跳过版本锁定后来在线环境出问题想回滚才发现旧包没留。从那以后我每次改脚本都先写一行备份注释。这套安装脚本现在给我的价值不是省那一次安装的时间而是让每次交付都长一个样。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要快速部署GB28181视频监控平台的技术人员这套wvp-GB28181-pro与ZLMediaKit集成安装脚本包将直装版程序与依赖环境打包在一起解决从零编译、环境配置繁琐的问题。压缩包共包含六个文件其中四个为脚本、一个为组件压缩包、一个为说明文档整体大小约为七百六十五兆字节。脚本分别负责数据库、缓存、运行环境及主程序的一键安装组件包内为媒体服务相关依赖文档则提供清晰的操作指引。正常使用场景下只需在平台配置文件中修改对接地址即可接入国标摄像头并启用全部功能极大降低部署门槛。目前已有两千五百五十三人学习下载适合安防监控集成商、运维工程师及视频平台二次开发人员作为开箱即用的搭建参考。1. wvp-GB28181-pro和ZLMediaKit的打包安装脚本把一套国标视频接入环境从一夜压缩到一刻钟接到一个园区视频接入需求现场几十台支持GB28181协议的摄像头要统一接入一个平台做实时预览和录像回放。新上的服务器啥都没有按老办法装先装JDK、MySQL、Redis再编译ZLMediaKit最后把wvp-GB28181-pro的jar包和SQL跑起来中间还得把SIP端口、媒体端口段、hook回调一条条对上。顺利的话一个晚上不顺利的话第二天继续。打包好的安装脚本解决的问题就是把wvp-GB28181-pro国标信令平台和ZLMediaKit流媒体服务连同它们各自的依赖一次部署到位。有一说一脚本解决的是“装好”不是“调好”设备侧的SIP参数和平台侧的ID、密码、媒体端口最终还是要你对齐。这篇文章适合做安防集成、视频上云、国标设备接入的交付和运维同学它能让你从手工搭环境里腾出手把精力放到更费设备的对接和排障上。2. 先分清信令和媒体wvp-GB28181-pro和ZLMediaKit在链路里各管哪一段2.1 GB28181的三件事决定了wvp的定位GB28181是一个基于SIP的国标协议。摄像头、NVR、平台在协议里都是SIP UA。wvp-GB28181-pro在Java里实现了一个SIP服务器并在此基础上做了三件核心事注册、目录、点播。注册是第一步。设备端配置一个SIP服务器地址、端口和ID启动后向平台发REGISTER平台回200 OK设备就“在线”了。目录是第二步平台下发查询目录的指令设备把它下挂的通道列表回传平台入库。点播是第三步用户在页面点一个通道wvp通过SIP INVITE通知设备“把流推到某某地址的某某端口”这个地址和端口不是wvp自己的而是ZLMediaKit提前占好的收流端口。理解这一点很重要。很多人部署完发现设备在线但不出流上来就查ZLMediaKit其实方向错了先查SIP INVITE有没有被回200再查设备有没有真的往目标地址推流。wvp管的是“说”ZLMediaKit管的是“收”和“转”链条必须先对。2.2 ZLMediaKit把“流到了之后”的所有事接管下来摄像头按INVITE里的地址推流过来后ZLMediaKit开始干活。它做的事情分几层先把RTP/RTSP流接住然后按需转封装成RTMP、HLS、HTTP-FLV、WebRTC等给前端播放同时可以按计划做录像也可以做多路分发一路进来几十路出去。ZLMediaKit经常被单独拿来当“拉流转推”的工具用但在GB28181这条链路里它的角色是“被动收流主动分发”。被动收流指的是设备主动往它的某个端口推主动分发指的是它把流用各种协议吐给播放端。你排查时如果发现播放端拉不到流先分清是哪一段断了设备有没有推上来ZLMediaKit有没有接住分发端口有没有监听。这三个问题用的命令完全不同。这个“接住”的动作在ZLMediaKit里叫RTP代理它会为每一路点播动态分配一个本地端口来接收媒体流端口从一个预设范围内取。这也是为什么部署脚本里不是开一个端口而是开一整段端口。2.3 三个接头SIP端口、媒体端口段、hook回调wvp和ZLMediaKit之间有三个“接头”接线没对齐平台就是半残的。接头所在服务常见默认配错后的表现SIP注册端口wvpUDP 5060设备注册不上页面一直离线媒体收流端口段ZLMediaKit10000-20000设备推流被丢播放黑屏hook回调ZLMediaKit 到 wvpHTTP接口需配secret流状态不更新录像上报丢失先说SIP端口它走UDP而且必须和设备端的配置一字不差。设备端填的SIP服务器ID、密码、端口和wvp里配置的要一致否则注册包到了也回不了200。第二个接头是媒体端口段。ZLMediaKit的RTP代理每接一路流就占一个端口所以脚本里要预留一个连续的UDP端口段。如果只放行一个端口第一路能看第二路必黑。第三个接头是hook。ZLMediaKit收到流、流断开、录像文件生成完之后会向wvp的一个HTTP接口发POST事件。这里有两样东西要对一是回调地址二是secret。地址错wvp收不到事件secret不一致wvp直接回401拒绝。提示wvp里配置的媒体服务地址填的是ZLMediaKit对外的地址千万别填127.0.0.1除非两个服务确实在同一台机器的同一个网络命名空间里。3. 安装脚本做了什么从检查环境到拉起服务一次手工部署被拆成几步3.1 第一步探测发行版和基础依赖常见安装脚本不会上来就装先做环境判断把系统版本、架构、可用内存打出来没通过就直接退出避免装到一半发现缺编译器。ZLMediaKit是C写的即使下release包也可能需要在本地编一部分动态库wvp是Java包要跑在JDK17这类环境上。依赖这一层脚本把gcc、g、cmake、openssl-devel、MySQL、Redis、Nginx一次性装齐。#!/bin/bash # 简单识别发行版并安装基础依赖 source /etc/os-release if [[ $ID centos || $ID rhel ]]; then yum install -y gcc gcc-c make cmake openssl-devel libstdc-static yum install -y mysql-server redis nginx elif [[ $ID ubuntu || $ID debian ]]; then apt-get update apt-get install -y build-essential cmake libssl-dev apt-get install -y mysql-server redis-server nginx else echo 不支持的系统: $ID exit 1 fi逻辑说明先读 /etc/os-release 拿发行版ID再走对应包管理器。CentOS系装的是 libstdc-staticUbuntu系装的是 libssl-dev两者名字不一样这是ZLMediaKit编译时最常见的两个依赖差异。这套脚本适合在全新机器上跑如果内网不能访问外网源就要给脚本加一个“离线模式”把rpm/deb包提前下好放进本地目录安装时直接指向本地源很多现场服务器其实是不通外网的这一步不是可选项。3.2 第二步端口规划和防火墙放行装完依赖不等于能跑端口才是第一个翻车点。部署脚本里会把端口定义成变量集中在脚本头部便于一次改完也便于交付时让客户一眼看到整个平台要开放哪些端口。# 端口规划统一放头部改一处生效 SIP_PORT5060 # GB28181 SIP 注册端口UDP WEB_PORT8080 # wvp 管理页面/API/WebSocket MEDIA_START10000 # ZLMediaKit RTP收流起始端口 MEDIA_END20000 # ZLMediaKit RTP收流结束端口 ZLM_API_PORT80 # ZLMediaKit RESTful API 端口 ZLM_RTSP_PORT554 # RTSP 分发端口放行策略建议写成函数避免在脚本里散落一地的firewall命令open_ports() { if command -v firewall-cmd /dev/null 21; then firewall-cmd --permanent --add-port${SIP_PORT}/udp firewall-cmd --permanent --add-port${ZLM_API_PORT}/tcp firewall-cmd --permanent --add-port${ZLM_RTSP_PORT}/tcp # 媒体端口段统一放行否则并发点播必炸 firewall-cmd --permanent --add-port${MEDIA_START}-${MEDIA_END}/udp firewall-cmd --reload fi }为什么媒体端口要一段而不是几个因为ZLMediaKit为每路流动态分配端口不是固定用某一个。把10000-20000整段放行看起来开销大实际上这些端口不是常开的监听端口是收到RTP包才占用不必担心安全面扩大太多。生产环境如果隔离要求高可以在防火墙里加源IP白名单只允许摄像头网段的IP访问媒体端口段。3.3 第三步初始化数据库和配置文件占位wvp的jar包里不直接带配置部署时把 application.yml 和 SQL脚本放到指定目录启动时加载。脚本常用做法是把配置里的IP、密码写成占位符再用sed替换成实际值这样模板文件和脚本逻辑可以分开维护。# 从模板生成真实配置 sed -e s|{{DB_HOST}}|127.0.0.1|g \ -e s|{{DB_PASSWORD}}|${DB_PASSWORD}|g \ -e s|{{SIP_ID}}|${SIP_ID}|g \ -e s|{{SIP_PASSWORD}}|${SIP_PASSWORD}|g \ -e s|{{ZLM_ADDR}}|${ZLM_ADDR}|g \ -e s|{{ZLM_SECRET}}|${ZLM_SECRET}|g \ application.tpl.yml application.yml # 灌初始化SQL mysql -uroot -p${DB_PASSWORD} init.sql这一步的几个参数要解释清楚DB_PASSWORD是初始化时给MySQL root设的密码脚本里应该先生成随机值再显示给用户SIP_ID是SIP域标识和设备端填的SIP服务器ID完全一致才能注册ZLM_SECRET是wvp和ZLMediaKit共享的密钥两边必须一样。模板文件的好处是版本升级时只改模板不用改脚本逻辑。SQL初始化注意wvp的初始化SQL是按MySQL 5.7/8.0的常见语法写的。如果你的MySQL是8.0以上默认认证插件是caching_sha2_password老版本依赖会有兼容问题。脚本里通常补一句ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY ${DB_PASSWORD};把认证方式兜底成原生密码避免Java连接池报认证错误。3.4 第四步用systemd托管两个服务启动顺序有讲究手工部署的另一个问题是没有守护进程一断平台就没了。脚本到这一步会为两个服务写systemd unit对运维来说后面开机自启、看日志都方便。一个典型的wvp服务文件长这样cat /etc/systemd/system/wvp.service EOF [Unit] Descriptionwvp-GB28181-pro Afternetwork.target mysql.service [Service] WorkingDirectory/opt/wvp ExecStart/usr/bin/java -jar /opt/wvp/wvp.jar --spring.config.location/opt/wvp/application.yml Restarton-failure RestartSec5 Userwvp [Install] WantedBymulti-user.target EOFZLMediaKit的服务文件类似ExecStart换成它的启动程序。启动顺序上脚本统一先起ZLMediaKit再起wvp。原因不是wvp依赖ZLMediaKit才能启动而是设备点播放是随时可能发生的你希望媒体服务先就位。两者都起来后脚本做一次端口探测systemctl daemon-reload systemctl enable --now zlm.service systemctl enable --now wvp.service sleep 5 ss -lunp | grep -E (:5060|:10000) || echo 端口未监听请检查失败原因这里的ss命令是验证脚本有没有真的把端口拉起来比用网页登录靠谱得多。wvp启动慢Java进程要JVM预热注册信令要等它打印“server started”之类日志才算真起来页面打不开不一定代表进程没启动别急着反复重启先看日志。3.5 第五步升级与回滚脚本里必须留的后悔药部署脚本只解决首次安装但交付现场迟早要升级。我建议脚本里直接带一个升级函数。动作很简单停服务、备份旧版本、覆盖新版本、起服务。关键是备份这一步别省而且备份的除了程序包还有当前配置文件。upgrade() { local app$1 local pkg$2 systemctl stop ${app} cp -r /opt/${app}/conf /opt/${app}/conf.bak.$(date %s) cp /opt/${app}/${app}.jar /opt/${app}/${app}.jar.bak.$(date %s) cp ${pkg} /opt/${app}/${app}.jar systemctl start ${app} }版本升级最容易翻车的地方是ZLMediaKit的config.ini跨大版本改格式。旧配置直接覆盖到新版本上启动时报“unknown option”所以升级脚本里ZLMediaKit的配置不自动合并而是保留旧配置新版本起来后按提示逐项确认。这个逻辑用三行注释写死在脚本里防止三个月后你自己也忘了当初为什么要这么写。4. 部署中最常见的五个坑现象、原因、解决4.1 设备注册不上SIP端口是UDP的防火墙只放行了TCP现象wvp页面设备列表一直空SIP日志里没有任何REGISTER请求。原因现场防火墙默认只放TCP端口而GB28181的SIP注册走的是UDP 5060。另一个常见原因是设备端填的SIP服务器ID和wvp配置的SIP域不一致注册包到了被wvp判定为非法来源不回应。解决先给防火墙加UDP 5060放行再登录摄像头核对SIP服务器ID、密码、端口三项。判断依据用tcpdump抓包最直接tcpdump -i any udp port 5060 -n抓到的包里要能看到设备IP发REGISTER。如果包出去了没回应查wvp日志里有没有鉴权失败的记录如果压根没包过来问题在设备配置或网络和平台无关。4.2 设备在线但拉流报401ZLMediaKit的secret和wvp不一致现象设备注册正常列表也看得到点播放时前端返回401wvp日志里出现secret错误。原因wvp配置里的媒体服务密钥和ZLMediaKit config.ini里的secret不一致ZLMediaKit的hook回调或鉴权被拒绝。解决把两边改成同一个随机字符串。改完先重启ZLMediaKit再重启wvp顺序反了会看到wvp还在用旧连接。这个secret默认值在生产环境一定要换掉——ZLMediaKit没有内置的访问控制secret就相当于它的钥匙默认值等于把钥匙挂门上。还有一层要留意ZLMediaKit的API端口反向代理到公网时secret会在请求头里明文传递务必给API端口做访问控制。4.3 播放黑屏媒体端口段没有放行设备推流被丢现象SIP的INVITE流程已经走完设备也回了200 OK但播放端一直黑屏或转圈ZLMediaKit看不到流。原因设备按INVITE里的地址往某个媒体端口推UDP流但那段端口没放行或者中间路由丢包。wvp没收到hook所以页面状态也刷不出来。解决把10000-20000的UDP段加入放行列表。判断时注意telnet测端口只能测TCPUDP要用nc -u测或者直接在ZLMediaKit日志里看有没有收到RTP包。这个翻车点最容易伪装成“设备不支持”或者“编码不对”实际只是端口被挡。4.4 播放结束后流状态不恢复hook回调地址写错现象录像文件其实已经生成但平台的录像列表拿不到播放挂断后页面上的状态不恢复成空闲。原因ZLMediaKit把“流变化”“录像文件生成”等事件POST到了错误的地址wvp压根没收到通知。最常见的是部署时把hook地址写成了127.0.0.1而wvp在另一台机器上。解决在ZLMediaKit配置里找hook相关设置把地址改成wvp的HTTP访问地址。ZLMediaKit日志里搜“hook”或“notify”能看到POST失败的记录。这个坑我踩过一整晚纯属玄学信令和媒体都正常就是业务状态对不上最后发现是回调地址少写了一个端口。4.5 Nginx反代后页面能开、播放器起不来WebSocket握手失败现象用Nginx反代wvp的8080端口后页面正常打开但播放器反复重连。原因wvp的播放器通过WebSocket拉取流状态和播放地址Nginx反代默认不转发Upgrade头握手直接失败。解决在Nginx的location里补两个头proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;加上之后重载Nginx再刷新页面。反代方案里还容易漏掉超时配置播放长走后端没有读操作默认60秒超时就把连接断了长连接场景要把proxy_read_timeout调大。5. 装完怎么证明它能用从注册到出流的验证5.1 信令在线看日志和抓包别只看页面页面显示“在线”有可能是假象。设备掉线后SIP的超时机制要等几个周期才判离线页面在这段时间里还显示绿色。可靠的判断是看wvp日志设备每注册一次都会打一条记录再严格一点就抓包。看注册状态用一条命令journalctl -u wvp -f | grep -iE register|REGISTER抓包看完整握手tcpdump -i any udp port 5060 -n -v正常的注册交互是设备发REGISTERwvp回401带挑战设备重新带鉴权信息再发REGISTERwvp回200 OK。如果你看到的交互停在401说明密码不对或SIP域不匹配这比看页面直观得多。5.2 媒体链路用ffplay绕过页面直连ZLMediaKit页面播放涉及wvp鉴权、WebSocket、浏览器解码等多层出错时不好定位。验证媒体链路最直接的办法是绕过wvp直连ZLMediaKit拉流。在wvp的播放接口返回里能找到流地址通常形如rtsp://IP:554/live/streamId直接用ffplay拉ffplay -i rtsp://127.0.0.1:554/live/your_stream_id如果ffplay能出画面问题不在ZLMediaKit往上查wvp到ZLMediaKit之间的地址配置如果ffplay黑屏再看设备有没有把流推到ZLMediaKit。登录ZLMediaKit的API调用getMediaList接口能列出当前所有存活流有流说明ZLMediaKit收到了没流说明设备根本没推上来问题又回到了SIP INVITE。5.3 录像和回放验证的是设备能力和平台调度的配合录像分两段。设备端录像由设备自己存平台通过SIP INVITE带回放参数时间范围、流ID去调平台录像由ZLMediaKit按计划录制落盘在ZLMediaKit的录像目录。验证时先做一轮平台录像配一个计划任务等约5分钟去ZLMediaKit的rec目录确认文件增长。再验证回放页面上选一个时间点发起回放看是否出画面和进度条是否可拖。录像文件时间戳对不上是时区坑。wvp的JVM、MySQL、ZLMediaKit如果用了不同时区录出来的文件名和检索时间会整体偏移。脚本里应该在三个服务启动前统一TZAsia/Shanghai减少这种查不明白的时间问题。6. 把安装脚本改造成运维基线版本锁定、健康检查和升级纪律脚本跑通了只是个起点我更推荐把它当运维基线来维护。血泪经验是版本锁定脚本里所有下载的包都要锁版本号或SHA别用latest。有一次部署时ZLMediaKit用了最新release配置格式变了老脚本生成的config直接不识别排查了一个下午。原因不复杂自动拉新版本配置格式向前不兼容。锁版本后每次升级走单独流程问题就好控制了。再补一个健康检查函数。运维不是装完就跑要能随时知道两个服务活着health_check() { curl -sf http://127.0.0.1:80/index/api/getServerConfig -H secret: ${ZLM_SECRET} /dev/null echo zlm ok curl -sf http://127.0.0.1:8080/ /dev/null echo wvp http ok }如果后面还要扩展比如把AI识别yolo那类事件检测接进平台ZLMediaKit的流事件hook和wvp的录像回调都能作为事件源把视频帧交给算法容器做异步分析。但那是后话前提是当前这套部署基线够稳、升级可复现。我曾经图省事跳过版本锁定后来在线环境出问题想回滚才发现旧包没留。从那以后我每次改脚本都先写一行备份注释。这套安装脚本现在给我的价值不是省那一次安装的时间而是让每次交付都长一个样。希望帮到你。本文还有配套的精品资源点击获取
