上传失败主因是Nginx多环节配置缺失或不匹配，而非轮询算法；需在处理上传的location块中显式设置client_max_body_size，并同步调大client_body_buffer_size、client_body_temp_path、proxy_read_timeout等配套参数，且单位须规范（如2G），同时检查后端及CDN限制。
轮询算法本身不参与请求体大小控制，client_max_body_size 是 Nginx 的请求准入参数，和负载均衡方式无关。上传失败不是轮询导致的，而是 Nginx 在接收、缓冲、转发大文件时，多个环节配置缺失或不匹配造成的。
必须在 proxy 转发的 location 块里设 client_max_body_size
轮询通常用在 upstream 块中，但 client_max_body_size 不在 upstream 里配——它要落在实际处理上传请求的 location 中。比如前端 POST 到 /api/upload，就必须写：
location /api/upload {client_max_body_size 2G;proxy_pass http://backend_pool;}
只在 http 或 server 块设，容易被 location 继承默认值（1M），尤其当该 location 没显式声明时，413 就会照常出现。
配套参数必须同步调大，否则转发中途断连
client_max_body_size 只决定“让不让进”，真正影响转发稳定的是这三项：
-
client_body_buffer_size：建议设为
1m。太小（如默认 8k）会频繁写临时文件；太大（如设成 2G）直接吃光内存 -
client_body_temp_path：确认路径（如
/var/tmp/nginx/client_body）磁盘空间充足，且 nginx 运行用户（如www-data）有读写权限，否则日志报Permission denied -
proxy_read_timeout 和 proxy_send_timeout：都建议设为
3600。Nginx 需等完整收完文件再转发，超时就直接断开，前端看到的是连接中断，不是 413
单位写法要规范，避免解析失效
常见错误不是数值不够，而是单位拼错：
- ✅ 正确：
2g、2G、2048m、0.5g - ❌ 无效：
2GB、2Gb、2 MB（带空格）、2e9（科学计数法） - ⚠️ 特别注意：
m小写是兆字节，ms才是毫秒——写成100m没问题，但100ms就变成 100 毫秒，配置完全失效
后端和中间链路也要检查，不能只盯 Nginx
即使 Nginx 全部配对，上传仍可能卡在下游：
- PHP：检查
upload_max_filesize和post_max_size（php.ini），需 ≥ Nginx 的 client_max_body_size - Python（Flask/Django）：确认框架层 body 解析 limit（如 Flask 的
max_content_length） - Java（Spring Boot）：核对
spring.servlet.multipart.max-file-size和max-request-size - CDN 或网关（如 Cloudflare）：它们自带默认 100MB 限制，需单独放开
