企业官网建设流程全解析

MediaMTX 部署踩坑记录：一个二进制接管 RTSP、RTMP、HLS 与 WebRTC

【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx

当你需要一个能把 RTSP、RTMP、SRT、WebRTC、LL-HLS 互相转换的中转服务器时，MediaMTX 部署通常是最短路径：它是一个开箱即用的 Go 单二进制流媒体服务器，核心价值在协议互转——摄像头用 RTSP 推流进来，浏览器用 HLS 或 WebRTC 看出去，全程一个进程。它不做转码，只负责 remux、转发、录像和回放。本文按“最小可跑 → 生产加固 → 并发扩展”的顺序，把 MediaMTX 部署走一遍。

你将带走：

• 一条可直接执行的容器化启动命令，以及验证推流链路的方法
• 生产环境必须处理的端口、证书与认证清单
• 一种不碰源站、直接扩容并发观看的只读副本方案

能力速览：一个二进制能接住哪些协议

MediaMTX 同时内置了多组服务器：入流可以是 RTSP（8554/8322）、RTMP（1935/1936）、SRT（8890）、WebRTC（8889 加 UDP 8189）、MoQ/QUIC（8892-8893）、MPEG-TS 或裸 RTP；出流则是这些协议的任意组合。它不转码，因此几乎不吃 CPU；需要改分辨率或改编码格式的场景，请自己外挂 FFmpeg，不要指望它。和 SRS、ZLMediaKit 这类同类产品的一句话差异：MediaMTX 把控制 API（9997）、Prometheus 指标（9998）、录像回放服务（9996）全部收进同一个进程，运维面小，配置就一个文件。

跑起来只需要一条命令，官方镜像内已带默认配置：

docker run --rm -it --network=host bluenviron/mediamtx:1

看到server is running日志即代表服务起来了，默认行为以仓库里的 mediamtx.yml 为准，所有媒体协议默认开启。如果你需要自己构建镜像，docker/standard.Dockerfile 展示了官方的 scratch 最小镜像方案，支持 amd64/arm64/armv6/armv7 四个架构。

分阶实操：MediaMTX 部署的容器化配置与高可用

最小可跑：两条命令验证推流链路

这一阶段的目标只有一个：确认你的环境能推能拉。容器建议用 host 网络模式启动，原因是 RTSP/SRT/WebRTC 涉及大量 UDP 端口，走 bridge 网络时端口映射容易漏配，排查成本很高。同时顺手打开控制 API，后面所有验证都靠它：

docker run -d --name mediamtx --restart always --network host \ -v "$PWD/mediamtx.yml:/mediamtx.yml" \ -e MTX_API=yes \ bluenviron/mediamtx:1

然后用 ffmpeg 把一段本地视频循环推成 RTSP 流，并用 API 确认路径上线：

# 推流：-c copy 不转码，只 remux 成 RTSP ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp -rtsp_transport tcp \ rtsp://127.0.0.1:8554/test # 验证：路径 online 即全链路打通 curl -s http://127.0.0.1:9997/v3/paths | jq '.items[] | .name'

响应里出现test，日志同时打印path [test] is now available，就说明跑通了。这时还可以用 VLC 拉rtsp://<主机IP>:8554/test，或在浏览器打开http://<主机IP>:8888/test/index.m3u8，一次看全两种出流协议。

生产加固：认证、加密与录像持久化

只要服务暴露到局域网之外，三件事必须做：管理端口收紧、媒体流加密、录像落盘且自动清理。默认配置里“本机可免密访问 API”这条规则要保留，但匿名推流拉流必须在生产环境改掉——把authInternalUsers的user: any换成具体用户名密码，并用ips字段圈定可信网段。

先生成自签名证书，正式环境换成内部 CA 签发的：

openssl genrsa -out server.key 2048 openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 \ -subj "/CN=mediamtx.example.com"

然后修改配置文件，只保留和当前场景相关的行。这里有个实用特性：该文件支持热加载，改完写回即生效，不需要重启，在线客户端也不会断：

# 管理端口只对本机开放 apiAddress: 127.0.0.1:9997 metricsAddress: 127.0.0.1:9998 # RTSPS(:8322) 与 RTSP 并存，"optional" 表示老客户端不受影响 rtspEncryption: "optional" rtspServerKey: /certs/server.key rtspServerCert: /certs/server.crt rtmpEncryption: "optional" # RTMPS 监听 1936 pathDefaults: record: true recordPath: /recordings/%path/%Y-%m-%d recordDeleteAfter: 7d # 录像自动清理，防止磁盘写满

compose 里把/certs和/recordings挂成卷即可。验证很简单：curl -k https://127.0.0.1:8322返回 4xx 而不是 connection refused，说明加密端口已起；推一段流之后/recordings/test/下出现文件，录像链路就绪。

规模化：用只读副本扩展并发观看

单实例的天花板是出口带宽——不做转码时，瓶颈几乎总在“一个源分发 N 个读者”的吞吐上。官方推荐的做法是只读副本（read replica）：源站只接推流，副本从源站拉流再服务观众，前面挂一层负载均衡。这里有个容易忽略的点：RTSP/RTMP/SRT 观众走四层 LB 就行，HLS 和 WebRTC 观众必须走七层 LB 并开启 sticky session，因为一个观看会话由多个连续 HTTP 请求组成，中途换副本会话直接断。

副本侧的配置只需改这几行，用正则把源站的所有路径按需代理过来：

webrtcLocalUDPAddress: "" # 禁用本地 UDP，改由 STUN 拿公网地址 webrtcICEServers2: - url: stun:stun.l.google.com:19302 paths: "~^(.+)$": # 正则匹配全部路径 source: rtsp://origin:8554/$G1 # $G1 为正则捕获的流名 sourceOnDemand: true # 有人看才拉流，没人看自动断开

完整的部署拓扑和 LB 行为约束可以参考 docs/2-features/19-scalability.md。验证：向副本连接某一路流，再查源站的 9997 API，对应路径下出现一个 RTSP 读者，链路即通。

高频坑：端口、WebRTC 与配置覆盖

端口冲突：日志报 address already in use，容器反复重启。8554 很容易被摄像头服务、VLC 服务器或另一个 mediamtx 实例占用。先ss -ltnup | grep 8554确认占用者，然后改环境变量即可，不用动配置文件：docker run -e MTX_RTSPADDRESS=:18554 ...。注意改完端口后，所有客户端的 RTSP URL 要同步更新。

WebRTC 浏览器拉不动：握手成功但黑屏或一直转圈。原因是服务器把内网 IP 作为 ICE 候选发给了客户端，客户端拨不回来。两条修复路径：把公网 IP 或域名加进webrtcAdditionalHosts，并确保 UDP 8189 对客户端可达；如果服务器在 NAT 后面，还要在webrtcICEServers2里加 STUN/TURN。

环境变量覆盖不生效，参数还是默认值。环境变量必须全大写、下划线连接，格式是MTX_参数名；嵌套结构按MTX_+外层key_+内层key拼接，比如给路径设 source 要写MTX_PATHS_CAM1_SOURCE=rtsp://...，写成小写MTX_path_cam1_source会被静默忽略。排查手段：启动后curl -s localhost:9997/v3/config，返回的是实际生效配置，和预期值逐项对比即可定位。

收尾：这套部署路径回顾

本文的路径是：一条容器命令起服务并用 ffmpeg 验证推拉流；再做认证、加密、录像三项生产加固；并发观看顶到带宽上限时，加只读副本横向扩容。MediaMTX 本身是无状态单二进制，部署难度集中在端口和证书上，而不是服务本身。下一步值得深挖的是配置里的forward（把一路流自动转发到多个外部服务器）和runOnDemand（有观众时自动拉起推流命令），两者的完整参数都在 配置文档 中，是生产环境里最实用的两个高级特性。

【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx