chunked_transfer_encoding 是 Nginx 控制自身作为服务器时是否允许对无 Content-Length 响应启用分块编码的指令，默认 on，仅影响静态/错误页等非代理场景，对 proxy_pass 等 upstream 行为无作用。
配置 chunked_transfer_encoding 本身不是 NGINX 的显式指令，而是 HTTP/1.1 协议在特定条件下自动启用的传输机制。它不直接用于静态资源服务的稳定性优化——真正起作用的是 Range 请求 + 206 响应 和配套的缓存、零拷贝策略。强行依赖 chunked encoding 反而可能削弱大文件传输的可控性与恢复能力。
为什么 chunked encoding 不适合大静态资源稳定传输
chunked encoding 是服务器在无法预知响应体总长度时（如动态生成内容、流式响应）使用的分块编码方式。它的特点包括：
- 每个数据块带独立长度头，无全局校验，客户端难以判断某一块是否损坏
- 不支持断点续传：客户端无法跳过已接收部分重新请求后续块
- NGINX 对静态文件默认禁用 chunked（除非关闭
Content-Length且未启用sendfile），因为静态文件大小已知，直接发Content-Length更高效可靠
真正提升大静态资源分片传输稳定性的配置项
应聚焦于 HTTP 范围请求（Range）和底层传输优化，而非 chunked：
-
开启 Range 支持：NGINX 默认开启，无需额外配置；确保不出现
disable_symlinks或权限限制导致206响应失败 -
启用 sendfile 零拷贝：
sendfile on;+tcp_nopush on;，减少内核拷贝，提升 GB 级文件分片读取效率 -
合理设置缓存头：对不变资源用
expires 1y;或Cache-Control: public, max-age=31536000，避免重复请求整文件 -
配合协商缓存：为需更新的资源添加
ETag（NGINX 默认开启）或Last-Modified，使客户端能用If-Range头精准续传
客户端侧需配合的关键行为
服务端配置只是基础，客户端必须正确使用 Range 才能实现稳定分片：
- 按固定偏移切分（如每片 5MB）：
Range: bytes=0-5242879、bytes=5242880-10485759 - 并发请求多个 Range，但控制并发数（建议 4–8 路），避免连接耗尽
- 每片收到 206 响应后校验
Content-Range头与实际字节数，不匹配则重试 - 网络中断后，从
Content-Range中解析已接收终点，继续请求后续区间
需要避免的常见误配
以下配置会无意破坏分片稳定性：
-
add_header Transfer-Encoding chunked;—— 手动添加该头会导致响应异常，NGINX 会拒绝或降级处理 -
gzip on;与大静态文件共用 —— 压缩过程阻塞 sendfile，且压缩后无法支持 Range（除非用gzip_vary on;并配合 ETag，但不推荐） -
underscores_in_headers on;开启后若客户端误传非法 Range 头，可能触发 400 而非 416，影响错误识别
