Nginx实现音视频流媒体分段分发的核心是协同HLS/DASH等HTTP自适应流协议，通过upstream负载分发、proxy_cache分级缓存及URI/健康状态智能路由，提升并发与可用性，不适用于RTMP或WebRTC。
利用 Nginx 实现音视频流媒体的分段分发，核心不在于“负载均衡”本身，而在于它如何与流媒体协议（如 HLS、DASH）协同工作，将客户端请求按需路由到合适的源节点或缓存节点，从而提升并发能力、降低单点压力、增强可用性。Nginx 本身不生成或转码音视频，但可高效代理、缓存、分流和控制 HTTP-based 流媒体请求（尤其是基于分片的 .ts/.mp4/.m3u8/.mpd 文件）。
明确适用场景：HLS/DASH 等 HTTP 自适应流
Nginx 负载均衡适用于以下典型流媒体架构：
- 后端部署多个流媒体服务节点（如 SRS、Nginx-rtmp-module、Bilibili bfe + blived、或自建 FFmpeg 推流转发集群），统一由 Nginx 做七层（HTTP）反向代理和负载分发；
- 客户端直接请求 /live/xxx.m3u8 或 /dash/xxx.mpd 及其分片（/live/xxx_0001.ts），Nginx 根据策略将这些 GET 请求分发到不同上游；
- 不适用于 RTMP/TCP 直连推拉流（需用 stream 模块做四层转发，且无法感知分片逻辑）；也不适合 WebRTC（信令和数据通道需专用网关）。
配置关键：upstream + proxy_pass + 缓存协同
以 HLS 分发为例，需在 Nginx 配置中组合以下要素：
- 定义 upstream 组：使用 ip_hash 或 hash $request_uri consistent 保证同一 m3u8 及其关联 ts 分片始终落在同一后端（避免跨节点缓存不一致或 404）；
- 启用 proxy_cache：对 .m3u8（TTL 短，如 3s）、.ts（TTL 长，如 1h）分别设置缓存策略，减少回源压力；
- 透传关键头 & 控制行为：设置 proxy_set_header Host $host;、proxy_ignore_client_abort on;（防止客户端切片中断导致连接堆积）、proxy_buffering on;（提升吞吐）；
- 区分动静态路径：例如 /live/*.m3u8 和 /live/*.ts 走流媒体 upstream；/api/health 走管理 upstream；/static/ 走本地文件服务。
进阶优化：按频道/负载/地域智能分发
单纯轮询或 ip_hash 不足以应对真实业务需求，可叠加以下策略：
- 基于 URI 参数分流：如 /live/abc.m3u8?region=sh → 用 map 指定 sh 节点组；
- 结合健康检查与慢启动：使用 check（需 lua-resty-upstream-healthcheck）或商业版 Nginx Plus 的主动探测，自动剔除卡顿或超时的流节点；
- 动态权重调整：通过 Lua 脚本读取后端 CPU/连接数指标（如 Prometheus API），实时修改 upstream 权重；
- 边缘缓存分级：Nginx 作为边缘节点缓存热分片；中心 Nginx 作为中间层聚合多个边缘节点，再对接源站集群。
注意事项与避坑点
实际部署中容易忽略但影响显著的细节：
- m3u8 中的分片 URL 必须为相对路径（如 chunk_0001.ts）或同域绝对路径（/live/chunk_0001.ts），避免写死后端 IP/端口，否则客户端无法正确请求；
- 务必关闭 m3u8 响应的 ETag 和 Last-Modified（或统一设为固定值），否则 Nginx 默认缓存策略可能因校验头不一致导致重复回源；
- TS 分片建议统一命名+固定时长（如 2s/片），便于 Nginx 缓存命中；避免使用时间戳随机名（如 xxx_1712345678.ts）；
- 开启 sendfile on; 和 tcp_nopush on; 提升大文件传输效率；
- 日志中记录 $upstream_addr 和 $request_time，便于分析分发是否均匀、是否存在慢节点。
