关键在于差异化缓存：.m3u8设3秒短缓存，.ts设1小时长缓存；启用proxy_cache_lock防穿透；用$request_uri hash保证同一场直播路由一致性；透传Host头并关闭自动重试。
要让 Nginx 真正撑起 HLS 视频流的分发任务，关键不是简单加个 proxy_pass，而是把反向代理、缓存策略、路径路由和协议特性串起来——尤其是针对 .m3u8 清单的短时效性与 .ts 分片的高复用性做差异化处理。
明确 HLS 请求的代理边界
HLS 是基于 HTTP 的分片协议，所有请求都是标准 GET：客户端拉取 /live/abc.m3u8，再按清单顺序请求 /live/seg-123.ts 等。Nginx 不参与推流或切片，只负责把这些请求精准转发或就地响应。
- 不代理 RTMP 推流（那是
nginx-rtmp-module或 SRS 的事），只代理 HTTP 拉流路径 - 区分动静路径：比如
/live/下全是 HLS 资源，/api/走管理接口，/static/直接本地服务 - 避免用通配 location 匹配全部，否则容易误伤健康检查或后台接口
配置两级缓存策略：m3u8 短 TTL，ts 长缓存
HLS 清单持续更新，但每个 ts 分片内容固定。缓存配置必须反映这个差异，否则要么清单过期导致播放卡顿，要么分片不命中增加源站压力。
- 为
.m3u8设置 1–3 秒缓存：proxy_cache_valid 200 302 3s; - 为
.ts设置 1 小时以上缓存：proxy_cache_valid 200 302 3600s; - 缓存 key 去掉 query 参数（如 token）：
proxy_cache_key "$scheme$proxy_host$uri";，避免带参 URL 打散缓存 - 启用
proxy_cache_lock防止缓存穿透时大量回源请求并发打垮上游
保证同一场直播的请求路由一致性
一个 m3u8 及其关联的所有 ts 必须始终由同一个上游节点生成或提供，否则可能出现序号跳变、分片缺失或 EXT-X-DISCONTINUITY 异常。
- 用
hash $request_uri consistent;（推荐）或ip_hash;实现会话粘性 - 不要用
least_conn或round_robin，它们无法保障 URI 关联性 - upstream 中每个 server 后可加
max_fails=2 fail_timeout=30s，自动剔除故障节点
透传与控制关键行为
HLS 客户端频繁中断、重试、快速切片，Nginx 需主动适应，而非默认阻塞或丢弃。
- 加
proxy_ignore_client_abort on;，防止用户拖进度条或切清晰度时连接中断引发后端堆积 - 开启
proxy_buffering on;并调大缓冲区（如proxy_buffers 8 128k;），提升吞吐稳定性 - 透传 Host 头：
proxy_set_header Host $host;，确保上游日志和鉴权逻辑正常 - 禁用 upstream 自动重试：
proxy_next_upstream off;，避免跨节点请求造成清单错乱
