要让HTTPS大文件上传不卡在Nginx层，需协同配置client_max_body_size（设为32m并置于server块）、client_body_buffer_size（512k）、client_body_temp_path（指定可写内存路径）和client_body_timeout（600s），同时同步调整后端与TLS限制。
要让 HTTPS 大文件上传不卡在 Nginx 层，client_max_body_size 必须设对位置、给足空间，但光调它远远不够——真正影响加密上传是否“顺畅”的，是它和 client_body_buffer_size、client_body_temp_path、client_body_timeout 的协同关系。HTTPS 本身不增加缓冲需求，但加密传输更耗时，容易触发超时或落盘失败，所以配置必须兼顾准入、暂存、超时、权限四方面。
明确 client_max_body_size 的作用和设置位置
它只是请求的“准入门槛”，不是缓冲区大小。值设小了，大文件直接被拦，返回 413；设对了，才进入后续内存暂存或磁盘落盘流程。
- 大宗商品图、高清质检图、带标注 PDF 等典型场景，P95 文件体积多在 10–30 MB，建议设为 32m（注意单位是小写 m，非 M）
- 必须写在 server 块内（HTTPS 服务对应的 listen 443 ssl 块），不能只放在 http 或 location 里——Nginx 在解析请求头阶段就校验该值，location 匹配发生在之后
- 示例配置：
server { listen 443 ssl; server_name upload.goods-platform.com; client_max_body_size 32m; client_body_timeout 600s; }
匹配 HTTPS 上传节奏，调优内存缓冲与落盘策略
HTTPS 下上传变慢，若缓冲区太小，数据会频繁刷到磁盘；若磁盘路径不可写或空间不足，就会报 500 而非 413，排查困难。
- client_body_buffer_size 推荐设为 512k：覆盖多数 ≤32MB 的商品图全程驻留内存，避免刷盘开销
-
client_body_temp_path 必须指定且可写：例如
client_body_temp_path /dev/shm/nginx_client_body 1 2;，用内存盘（/dev/shm）提速并规避磁盘 I/O 和权限问题 - 确保 Nginx 运行用户（如 www-data）对 temp_path 有读写权限，可用
sudo -u www-data touch /dev/shm/nginx_client_body/test验证
防止 HTTPS 慢速上传中断，收紧超时与日志验证
加密传输下，客户端上传速率波动大，超时配置不当会导致连接被主动断开，用户看到“网络错误”而非具体原因。
- client_body_timeout 设为 600s（10 分钟），比默认 60s 更合理；避免因网络抖动或客户端限速误判为死连接
- 临时开启 debug 日志确认是否真走内存：
error_log /var/log/nginx/debug.log debug;，上传一个略大于 512k 但小于 32m 的文件，查日志中是否出现client request body is buffered in memory - 搭配 access_log 记录
$request_length，跑 3–5 天真实流量，用 P95 值反向校验配置合理性
同步放开后端与协议层限制，避免隐性拦截
Nginx 放行只是第一步。HTTPS 请求穿过 Nginx 后，仍需后端服务（如 Spring Boot、Node.js）和 TLS 协议栈共同支持。
- Spring Boot 中补全两项：
spring.servlet.multipart.max-file-size=32MB和spring.servlet.multipart.max-request-size=32MB - Node.js（Express + Multer）需设：
app.use(express.json({ limit: '32mb' })); app.use(express.urlencoded({ limit: '32mb', extended: true })); - 确认 TLS 握手未启用过严的 ALPN 或早期数据（Early Data）限制，尤其在使用自定义 OpenSSL 参数时
