ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

使用Docker Compose部署WVP-PRO与ZLMediaKit实现GB28181国标视频接入

使用Docker Compose部署WVP-PRO与ZLMediaKit实现GB28181国标视频接入 做国标GB28181视频接入的人大概都有过这种体验平台装好了摄像头怎么也注册不上或者画面刚拉出来一刷新就断折腾半天发现是某个端口没放行。WVP-PRO和ZLMediaKit这套开源方案功能覆盖了SIP信令、设备管理、流媒体转发、录像回放基本能满足中小型视频监控项目的需求但裸装部署的链路很长——JDK、MySQL、Redis、ZLM编译依赖、前端打包每一步都能给你惊喜。这篇教程把我用Docker Compose部署WVP-PROZLM录像服务并配上Nginx反向代理的完整过程整理出来目录规划、配置文件、排坑经验都写在里面照着操作就能把平台跑起来。1. 先搞清楚这套架构在做什么1.1 WVP-PRO和ZLM的分工很多第一次接触国标接入的人会对这两个组件犯迷糊WVP-PRO和ZLMediaKit到底谁负责什么简单说WVP-PRO是Java写的GB28181平台负责所有“信令”层面的工作——摄像头通过SIP协议注册到WVPWVP管理通道、下发指令、做录像计划、给前端提供HTTP API。ZLMediaKit是C写的流媒体服务器负责“媒体”层面的工作——接收摄像头推过来的RTP流转封装成RTSP、RTMP、HTTP-FLV、HLS这些常见协议同时负责把流录制成文件。打个生活化的比方WVP是前台客服负责接电话、记工单、调度安排ZLM是仓库管理员负责收货、分拣、发货、留底。一个管指令一个管数据两边通过接口和密钥对接。只有把这一层关系理清楚后面配置的时候才知道哪些IP、端口、密钥该填在哪里。这套组合解决的核心问题是设备接入协议的标准化。市面上的摄像头、NVR品牌五花八门各自用的私有SDK不一样但大部分支持GB28181国标协议。通过WVPZLM可以用一套国标标准把海康、大华、宇视这些设备统一接进来还能做到录像回放、级联上报不需要逐个对接私有的厂商SDK。1.2 为什么用Docker Compose而不是裸装裸装WVP-PRO的流程大概是装JDK、装Maven、拉源码编译或者下载jar包、装MySQL、装Redis、编译ZLMediaKit、改各种配置文件、还要把前端打包进后端。这里面最容易出问题的是ZLMediaKit编译依赖的库不少编译一次十几分钟起步环境稍微不对就是各种报错。WVP-PRO自身因为是Spring Boot项目JDK版本、依赖版本、数据库初始化脚本哪一步忘了都会导致起不来。Docker Compose的本质是把整个运行环境固化下来。JDK版本、MySQL版本、Redis版本、ZLM的运行时依赖全部打包在镜像里项目组里任何一个人拿同一份docker-compose.yml都能起一套一样的环境。还有一点很实用配置可以版本化管理application.yml、config.ini、nginx.conf都挂在宿主机上改完重启容器即可换机器也简单。我见过不少团队在单机环境纠结是不是要上K8s我的建议是设备量在几百路以内、单机部署Compose完全够用运维成本也低。Compose虽然是单机编排但服务之间的依赖顺序、健康检查、自动重启都支持日常运维不需要额外写脚本。1.3 整体数据流与端口规划理解端口规划之前先看数据流。以一路摄像头为例完整链路是这样的摄像头启动后通过SIP协议注册到WVP的5060端口WVP验证设备ID和密码注册成功后在平台列表里看到设备在线。用户点击播放时WVP通过SIP INVITE指令通知摄像头推流摄像头把RTP流推到ZLM的10000-10010端口范围内ZLM转封装后通过8080端口的HTTP-FLV或者554端口的RTSP提供给播放端浏览器拿到播放地址后拉流播放。录像则是ZLM在推流过程中按规则写文件到挂载的record目录WVP通过ZLM的API查询录像文件列表前端回放时从ZLM拉取历史流。这里面端口规划特别重要我把部署中用到的端口整理成了表服务端口协议用途WVP-PRO18080TCP/HTTP平台页面、前端APIWVP-PRO18090TCP/HTTPSHTTPS入口可由Nginx替代WVP-PRO5060TCP/UDPSIP信令摄像头注册ZLMediaKit8080TCP/HTTPHTTP-FLV播放、REST APIZLMediaKit554TCPRTSP推拉流ZLMediaKit1935TCPRTMP推拉流ZLMediaKit10000-10010UDP国标RTP媒体接收ZLMediaKit8000-8001UDPWebRTC相关可选Nginx80/443TCP反向代理入口MySQL3306TCP容器内部通信Redis6379TCP容器内部通信实际部署时MySQL和Redis端口不用映射到宿主机只在Docker自定义网络内供WVP访问即可减少暴露面。对外必须放行的端口是WVP的18080和5060、ZLM的8080、554、1935、10000-10010以及Nginx的80/443。云服务器的话记得在安全组里同步放行这个坑我踩过不止一次服务器本地防火墙关了但云安全组没开照样连不上。2. 部署前的准备目录、镜像与版本选择2.1 环境要求与目录规划这套方案对服务器要求不算高最低2核4G内存能跑起来但录像IO和并发播放上来后会比较吃力建议生产环境至少4核8G磁盘根据录像保留周期来规划一路1080P全天录像大概需要30-50GB这个要提前估算。操作系统方面Ubuntu 22.04和CentOS 7.9我都试过没有本质区别。Docker建议20.10以上Compose使用v2版本docker compose命令而不是docker-compose。如果系统里是旧版本的docker-compose建议升级v2的语法和健康检查支持更完整。开始之前先规划目录结构。我的习惯是把所有相关文件放在一个统一的目录下方便备份和迁移mkdir -p /opt/wvp/mysql/data mkdir -p /opt/wvp/redis/data mkdir -p /opt/wvp/zlm/record mkdir -p /opt/wvp/zlm/config mkdir -p /opt/wvp/wvp/config mkdir -p /opt/wvp/nginx/conf.d mkdir -p /opt/wvp/nginx/ssl cd /opt/wvp录像目录zlm/record单独挂出来的目的很简单录像文件是核心资产必须用绑定挂载放到宿主机磁盘不能放在容器可写层里否则容器一删全没了也不方便直接查看和备份。ssl目录用来放证书后面Nginx反代要用。2.2 镜像版本怎么选镜像选择上我直接给一套我验证过的组合镜像版本说明mysql8.0用8.0不要用5.7WVP新版本对MySQL 8兼容更好redis7-alpineAlpine版体积小功能无差异zlmediakit/zlmediakitmaster官方持续构建版本功能最新648540858/wvp_prolatest社区常用镜像内置前端页面nginx1.24稳定版即可WVP-PRO的官方镜像是648540858/wvp_pro这个镜像是社区维护的把Java运行环境和内置前端都打包好了比从源码编译省事太多。ZLMediaKit的官方镜像是zlmediakit/zlmediakitmaster标签是持续构建的因为ZLM本身更新比较快用master能及时获得新功能和修复。国内拉取镜像之前建议配置好镜像加速器不然拉mysql:8.0这种大镜像可能会很慢甚至超时。配置完加速器后先手动拉一遍所有镜像确认能成功再往下走docker pull mysql:8.0 docker pull redis:7-alpine docker pull zlmediakit/zlmediakit:master docker pull 648540858/wvp_pro:latest docker pull nginx:1.242.3 防火墙与安全组端口放行这块我单独拿出来说是因为它太容易被忽略。配置好Compose文件后启动服务发现设备注册不上、播放黑屏大概率不是程序问题而是端口不通。需要在防火墙放行的端口包括TCP的18080WVP平台、5060SIP信令TCP、8080ZLM HTTP-FLV、554RTSP、1935RTMP、80和443NginxUDP的5060SIP信令UDP和10000-10010RTP媒体流。Ubuntu下可以这样操作sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 18080/tcp sudo ufw allow 5060/tcp sudo ufw allow 5060/udp sudo ufw allow 8080/tcp sudo ufw allow 554/tcp sudo ufw allow 1935/tcp sudo ufw allow 10000:10010/udp sudo ufw reload如果用的是云服务器安全组里也要同步配而且安全组和系统防火墙要同时放行才能通。验证端口是否通的简单方法是telnet 服务器IP 端口UDP端口不好直接测试但TCP端口可以用这个方式确认。3. 手写docker-compose.yml一步步搭起来3.1 基础服务MySQL和Redis先写MySQL和Redis这两个是WVP-PRO的依赖服务。基于我前面提到的健康检查机制让WVP等MySQL完全就绪后再启动避免第一次启动时连不上数据库导致初始化失败。MySQL部分的关键点是设置初始密码、创建wvp数据库、挂载数据目录、做健康检查。Redis部分用alpine镜像开启AOF持久化防止容器重启后缓存数据丢失。两个服务都加入到同一个自定义网络wvp-net里容器之间通过服务名互相访问这个网络后面所有服务共用。services: mysql: image: mysql:8.0 container_name: wvp-mysql restart: always environment: TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: wvp MYSQL_USER: wvp MYSQL_PASSWORD: wvp123 volumes: - ./mysql/data:/var/lib/mysql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -uroot, -proot] interval: 10s timeout: 5s retries: 10 networks: - wvp-net redis: image: redis:7-alpine container_name: wvp-redis restart: always environment: TZ: Asia/Shanghai command: [redis-server, --appendonly, yes] volumes: - ./redis/data:/data healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 5s retries: 10 networks: - wvp-netMySQL初始化数据目录的权限问题比较常见。如果./mysql/data目录权限不对MySQL容器会反复重启。遇到这种情况执行chown -R 1000:1000 ./mysql/data或者干脆删掉目录重新让容器初始化即可。另外MySQL 8默认的认证插件是caching_sha2_passwordWVP-PRO的JDBC驱动支持没问题不用特意改成mysql_native_password。3.2 流媒体服务ZLMediaKitZLM是媒体处理的核心端口映射多配置挂载也关键。需要把config.ini挂载到/opt/media/conf/config.ini把录像目录挂载到/opt/media/bin/record。注意ZLM容器内的默认工作目录是/opt/media/binMediaServer可执行文件在这个目录下录像路径默认也基于这个目录。zlm: image: zlmediakit/zlmediakit:master container_name: wvp-zlm restart: always environment: TZ: Asia/Shanghai volumes: - ./zlm/config/config.ini:/opt/media/conf/config.ini - ./zlm/record:/opt/media/bin/record ports: - 554:554 - 1935:1935 - 8080:8080 - 10000-10010:10000-10010/udp - 8000-8001:8000-8001/udp networks: - wvp-netZLM的RTP端口10000-10010必须用UDP映射这是摄像头推流进来的通道如果这个端口范围不通摄像头会注册成功但拉流黑屏。8000-8001是WebRTC用的UDP端口如果不使用WebRTC播放可以注释掉但留着也没什么负担。554和1935分别对应RTSP和RTMP8080是HTTP-FLV和REST API的端口。config.ini文件需要提前准备好放到宿主机这个文件可以直接从容器里复制出来修改也可以手动创建。我的做法是先启动一次ZLM容器生成默认config.ini然后停止容器复制出来改再启动。这样不会漏掉配置项。3.3 平台服务WVP-PROWVP-PRO的配置核心是application.yml它决定了WVP如何连接MySQL、Redis和ZLM。端口方面要映射三个18080是平台HTTP端口18090是HTTPS端口5060是SIP端口。注意5060端口TCP和UDP都要映射缺一个都会导致摄像头注册异常。wvp: image: 648540858/wvp_pro:latest container_name: wvp-pro restart: always environment: TZ: Asia/Shanghai JAVA_OPTS: -Xms512m -Xmx1024m volumes: - ./wvp/config/application.yml:/wvp/config/application.yml ports: - 18080:18080 - 18090:18090 - 5060:5060 - 5060:5060/udp depends_on: mysql: condition: service_healthy redis: condition: service_healthy zlm: condition: service_started networks: - wvp-netJAVA_OPTS这个环境变量是我在2G内存的服务器上验证过的把JVM初始堆和最大堆限制在512M-1024M避免Java默认最大堆占用过多内存导致整机卡死。如果你的服务器内存充足这步可以不配。WVP第一次启动时官方镜像会自动执行数据库初始化脚本在MySQL中建表并写入基础数据前提是MySQL中已有的wvp数据库是空的。3.4 反向代理NginxNginx在这里的作用是把WVP平台通过80端口暴露出去用户不用在浏览器里记18080这个端口号。同时把WVP的WebSocket连接也代理出去保证前端的实时播放和控制功能正常。如果以后配置了HTTPS证书443端口一并监听。nginx: image: nginx:1.24 container_name: wvp-nginx restart: always environment: TZ: Asia/Shanghai volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./nginx/ssl:/etc/nginx/ssl ports: - 80:80 - 443:443 depends_on: - wvp - zlm networks: - wvp-net networks: wvp-net: driver: bridge把以上几段合到同一个docker-compose.yml文件里就行了。Nginx的conf.d目录挂载的是整个配置目录里面放一个wvp.conf文件即可主配置文件nginx.conf不用改镜像自带的默认配置已经include了conf.d目录下的所有.conf文件。这种方式比直接改nginx.conf更干净后续加站点配置也方便。4. 核心配置文件逐行解析4.1 WVP-PRO的application.yml这是整套部署里最重要的配置文件WVP通过它知道怎么连数据库、怎么找ZLM、SIP信令怎么工作。以下是我在项目中实跑过的完整配置server: port: 18080 servlet: context-path: / spring: application: name: wvp-pro datasource: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://mysql:3306/wvp?useUnicodetruecharacterEncodingUTF8useSSLfalseserverTimezoneGMT%2B8 username: root password: root redis: host: redis port: 6379 password: database: 0 timeout: 5000 media: id: your-zlm-media-server-id ip: 你的公网IP或域名 port: 10000 secret: 035c73f7-bb6b-4889-a715-d9eb2d1925cc streamNoneReaderDelayMS: 30000 gb28181: sip: ip: 0.0.0.0 port: 5060 domain: 34020000002000000001 id: 34020000002000000001 password: 12345678 registerInterval: 3600 password: admin123逐项说明一下容易踩坑的地方。spring.datasource.url里的mysql是Docker Compose网络内的MySQL服务名不是IP容器间通过服务名解析。serverTimezoneGMT%2B8代表东八区时区这里的%2B是URL编码的加号不能直接写否则会报时区错误。media.ip这里必须填客户端能访问到的地址也就是服务器的公网IP或者域名不能填127.0.0.1也不能填zlm这个容器名。因为WVP生成播放地址时会用它拼接ZLM的地址前端浏览器拿到这个地址后需要能直接访问到ZLM。media.secret必须和ZLM的config.ini里api.secret保持一致这是WVP调用ZLM API的身份认证密钥。media.id是ZLM的mediaServerId可以不填WVP启动时会自动调用ZLM的API获取并维护。gb28181.sip.domain和gb28181.sip.id是国标里的SIP服务器编码默认的34020000002000000001可以用但生产环境建议改成自己的行政区划编码。gb28181.password是SIP服务器的密码摄像头注册时要用默认admin123记得改掉。4.2 ZLMediaKit的config.iniZLM的config.ini文件比较长大部分配置保持默认就行关键是api、rtp、record三段。先把默认配置从容器里复制出来再修改docker run -d --name zlm-tmp zlmediakit/zlmediakit:master docker cp zlm-tmp:/opt/media/conf/config.ini ./zlm/config/config.ini docker rm -f zlm-tmp然后把config.ini里的关键项改成这样[api] apiDebug1 secret035c73f7-bb6b-4889-a715-d9eb2d1925cc [rtp] port_range10000-10010 timeoutSec15 [record] record_mp41 record_ts0 record_hls1 mp4_max_second3600 [general] mediaServerIdyour-zlm-media-server-idapi.secret和WVP的media.secret保持一致这个不匹配的话WVP访问不了ZLM播放、录像全都会出问题。rtp.port_range是接收国标RTP流的端口范围和docker-compose.yml里映射的10000-10010对应。record.mp4_max_second是MP4分片时间我习惯设3600秒也就是1小时一个文件回放时定位比较方便。general.mediaServerId如果不设置ZLM会默认生成一个WVP会自动获取所以这行其实可以留空但保存一份固定的ID对排查问题有帮助。修改完config.ini后重启ZLM容器才会生效。4.3 Nginx反代配置在./nginx/conf.d目录下新建wvp.conf内容如下server { listen 80; server_name _; client_max_body_size 20m; location / { proxy_pass http://wvp:18080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /index/ws { proxy_pass http://wvp:18080/index/ws; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; } location /live/ { proxy_pass http://zlm:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_buffering off; } }location /是平台页面和API的代理location /index/ws是WVP的WebSocket代理必须设置Upgrade和Connection头同时把超时时间调到3600秒否则前端页面长时间挂机后WebSocket会断开。location /live/是ZLM的HTTP-FLV播放路径代理我习惯把它也走Nginx这样播放请求可以统一到80端口也方便以后在Nginx层加访问控制。proxy_buffering off关闭缓冲播放流延迟更低。如果以后要上HTTPS在443端口加一个server块把证书放到./nginx/ssl目录或者在80端口做一个301跳转到443Nginx的配置逻辑都是一样的加个listen 443 ssl和证书路径即可。4.4 录像目录与权限录像目录的权限问题很隐蔽。ZLM容器内运行MediaServer的用户是普通用户如果宿主机挂载的./zlm/record目录是root创建的ZLM在里面写文件时可能没有权限结果就是录像功能打开了但一直报错。为了避免这个问题启动之前先把目录权限放开chmod -R 777 ./zlm/record如果要做得更严谨可以指定UID但实际部署中777目录权限配合restart: always已经能覆盖绝大多数情况。录像文件落盘后ZLM会按流ID和日期自动建目录文件名格式类似2024-01-15_10-30-00.mp4可以直接在宿主机上查看到。我建议定期把zlm/record目录做一个软链到统一存储路径方便后续做备份和清理策略。5. 启动、接入设备与录像实测5.1 一键启动与日志观察所有配置文件就位后在/opt/wvp目录执行启动命令docker compose up -d首次启动时会拉取镜像并依次创建容器。因为WVP依赖MySQL和Redis的健康状态所以即使docker compose up -d命令返回了WVP容器可能还在等待依赖就绪。我习惯用下面几个命令观察状态docker compose ps docker compose logs -f wvp docker compose logs -f zlm日志里看到类似Started WvpApplication或Tomcat started on port 18080的输出说明WVP启动完成。ZLM启动成功的标志是日志里出现listening on 0.0.0.0:8080和rtp install相关的行。如果WVP启动报数据库连接错误多半是MySQL还没完全初始化完成或者application.yml里的数据库地址、密码不对。5.2 验证平台和流媒体服务WVP启动后浏览器访问http://服务器IP:18080能看到登录页面。默认账号admin密码admin123。第一次登录后强烈建议立即修改默认密码这个默认口令在生产环境里风险极高。ZLM的验证可以访问http://服务器IP:8080能看到ZLM自带的调试页面。如果没有页面也可以通过API方式验证curl http://127.0.0.1:8080/index/api/getServerConfig返回的JSON里如果包含code:0和ZLM的版本信息说明ZLM正常运行。这个API的访问方式也可以用来确认secret是否配置正确如果secret不匹配会返回鉴权失败。5.3 摄像头国标参数配置与录像验证平台起来以后要把真正的摄像头接进来。先登录WVP平台在设备管理里添加一个设备记录设备ID国标编码。然后到摄像头的配置页面把GB28181相关的参数填上。以海康摄像头为例需要在“网络→高级配置→平台接入”里配置参数配置值接入协议GB28181SIP服务器ID34020000002000000001与WVP配置一致SIP服务器地址WVP所在服务器公网IP或域名SIP服务器端口5060设备ID3402000000132000000120位国标编码通道ID3402000000132000000220位国标编码密码12345678与WVP的SIP密码一致保存配置后摄像头会主动发起SIP注册。回到WVP平台设备列表里能看到设备状态变为“在线”展开后能看到通道信息需要把通道添加到分组后才能播放。如果设备一直显示“离线”先排查5060端口是否通再检查设备ID和密码是否和WVP配置一致。录像验证是整个流程里最容易被忽视的一环。确保摄像头在线后在WVP平台的通道管理里开启“录像计划”或者在播放页面点一次“录像”触发录制。然后进到宿主机录像目录查看ls -lh /opt/wvp/zlm/record正常情况下能看到以流ID命名的MP4文件。用播放器直接打开这个文件确认能播放、时间戳正确。ZLM默认录制格式是MP4如果只有TS文件说明config.ini里record_ts和record_mp4的配置反了。录像回放在WVP的“录像回放”页面操作前端会从ZLM拉取录像文件列表选择时间段后通过HTTP-FLV播放历史流。6. 常见问题排查与避坑实录6.1 摄像头一直显示离线摄像头离线排在所有问题里的第一位我自己部署时也卡过。排查顺序是这样先确认摄像头平台接入页面里的SIP服务器端口配置的是不是5060再确认WVP的SIP监听是否正常用docker logs wvp-pro看有没有收到SIP报文最后确认设备ID和SIP服务器ID的编码规则是否正确。GB28181的设备编码是20位数字组成逻辑是“中央编码8位行业编码2位类型编码2位序号7位”很多摄像头配置页面默认提供一个编码和平台的domain不一致就注册不上。我踩过的坑是海康设备的SIP服务器ID填成34020000002000000001但平台domain配的是34020000002000001000两边的编码不一致设备一直显示“未注册”。6.2 播放黑屏或拉流失败设备显示在线但点播放黑屏大概率是媒体流链路的问题。第一检查media.ip配置如果填的是127.0.0.1或者容器名前端浏览器拿到的播放地址根本不可达就会一直转圈黑屏。第二检查10000-10010的UDP端口在云安全组里有没有放行国标设备推流用的是UDPTCP放行没用。第三确认ZLM的secret和WVP的media.secret一致不一致时WVP调用ZLM接口会报Invalid auth。还有一个容易忽略的点如果服务器有多个网卡ZLM默认绑定的IP可能不对。可以在ZLM的config.ini里把network.interface指定为实际对外通信的网卡或者把ip字段显式设置成服务器IP避免媒体流走了错误的网卡导致黑屏。6.3 录像文件没有生成或生成时间不对录像没生成的原因一般有三种录像计划没配置、目录权限不对、录制规则没开。WVP平台需要在通道管理里绑定录像计划只添加了通道不配置录像计划ZLM不会自动录制。目录权限问题按4.4节处理。录制规则没开的话检查config.ini的[record]段确保record_mp41。录像文件生成但时间不对多半是时区问题。ZLM容器默认是UTC时区需要设置环境变量TZAsia/Shanghai同时宿主机时区也要保证正确。如果时区不对录像文件名里的时间戳和实际时间会差8小时回放定位也会错乱。6.4 Nginx反代后WebSocket连接失败配置了Nginx后页面能打开但实时画面一直加载不出来浏览器控制台报WebSocket连接失败这是Nginx没有正确转发WebSocket请求。需要在location /index/ws里设置proxy_http_version 1.1、Upgrade和Connection头缺一不可。Connection upgrade必须用双引号包裹某些Nginx版本对大小写敏感写成upgrade才能识别。确认这些配置没问题后重启Nginx容器再试。另外一个细节是Nginx版本旧版Nginx对WebSocket的默认超时时间是60秒页面挂机超过60秒后WS就会断开需要把proxy_read_timeout调到足够大。6.5 其他高频问题我把剩余几个常见的小问题也列一下。MySQL容器反复重启检查数据目录权限按2.1节处理。WVP启动报内存不足检查JAVA_OPTS是否生效同时确认服务器内存是否够用。平台页面能打开但接口报404大概率是context-path配置错误应该保持/而不是/wvp。前端播放器报“流不存在”先在ZLM调试页面确认有没有收到推流再检查播放地址是否正确。这套方案里Nginx反代的主要作用是统一入口和未来扩展HTTPS如果你不需要统一端口ZLM的8080直接暴露也能用但生产环境我强烈建议至少加一层Nginx来做访问控制不要把ZLM的调试页面直接暴露在公网上。我在实际项目里还在Nginx层加了简单的IP白名单播放接口的日志也通过Nginx统一采集排查问题时比直接翻多个容器日志方便太多。还有就是Docker镜像和软件版本会持续变化尤其是WVP-PRO和ZLM的更新频率不算低新版本的配置项可能存在差异。如果你拉取的镜像是新版本配置文件和教程里对不上优先以镜像自带模板和官方文档为准我这份配置适用于当前主流的latest版本。生产环境部署前记得改掉所有默认密码包括MySQL的root密码、WVP的登录密码、SIP密码以及ZLM的API secret这些默认口令在网上早就被扫描器盯上了。
返回列表