Nginx 的 try_files 不直接支持断点续传，因其仅负责路径匹配与文件存在性判断，而 Range 处理发生在响应阶段；只要最终命中真实静态文件，Nginx 便自动支持断点续传，关键在于启用 sendfile、保持 tcp_nopush、透传 Range 头及正确设置 MIME 类型。
在 Nginx 中，try_files 本身**不直接支持断点续传（Range 请求）的优化**，它只是一个按顺序检查文件/路径是否存在并尝试返回的指令。断点续传依赖的是 HTTP Range 头和 Nginx 对静态文件的原生支持（如 sendfile、tcp_nopush 等），而非 try_files 的逻辑分支。
为什么 try_files 不处理 Range 请求？
try_files 在请求进入时就完成路径匹配和文件存在性判断，而 Range 处理发生在响应阶段——Nginx 只有在确定要返回某个具体文件后，才会读取请求头中的 Range 并切片响应。只要最终落到了一个真实存在的静态文件（比如通过 try_files $uri =404 匹配到磁盘上的大文件），Nginx 就会自动支持标准的断点续传，无需额外配置。
确保断点续传生效的关键配置
要让大文件下载真正支持断点续传，重点不在 try_files 写法，而在以下基础设置：
-
启用
sendfile：必须开启（默认通常已开），它让内核直接传输文件，对大文件高效且天然兼容 Range；关闭它（如用sendfile off）会导致 Range 失效 -
不要禁用
tcp_nopush：保持tcp_nopush on（默认），有助于合并 TCP 包，提升大文件传输效率 -
避免代理层干扰：如果 Nginx 前面有 CDN 或负载均衡器，确认它们透传
Range和If-Range头，且不缓存部分响应 -
确保 MIME 类型正确：用
types或default_type application/octet-stream明确大文件类型，避免浏览器因类型不明拒绝续传
try_files 的合理用法（配合断点续传）
你可以用 try_files 实现「先找带版本号的文件，再找原始文件，最后回源」的逻辑，只要最终指向的是真实静态文件，断点续传就依然有效。例如：
location /download/ {
alias /data/files/;
try_files $uri $uri/ /fallback.php?$args;
}当请求 /download/big-video.mp4 时，Nginx 先检查 /data/files/big-video.mp4 是否存在；存在则直接由 Nginx 返回，自动支持 Range；不存在才交给 PHP 处理。这个过程对客户端完全透明，续传不受影响。
需要绕过 try_files 的场景（慎用）
极少数情况下，你可能想用 X-Accel-Redirect 或 proxy_pass 动态控制下载（如鉴权后返回内部路径），这时 try_files 不适用，需改用：
-
内部重定向 + 静态服务：用
internal;保护真实路径，配合alias或root提供 Range 支持 - proxy_buffering off：若必须反向代理到后端，需关缓冲并确保后端也支持 Range，否则续传会中断
