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，影响错误识别