POST请求体损坏主因是client_body_temp目录权限不足、磁盘满或inodes耗尽，导致Nginx无法完整写入临时文件；需检查目录归属、权限、空间，并调优client_body_buffer_size等参数。
POST 请求体损坏通常和 least_conn 本身无关——这个算法只决定把请求发给哪个后端节点，不处理请求体的读取、缓存或转发逻辑。真正导致 POST 数据损坏的，是 Nginx 在代理过程中对请求体的临时存储与传递机制出了问题。
检查 client_body_temp 目录权限与空间
Nginx 在收到大 POST 请求（如文件上传）时，若请求体超出 client_body_buffer_size（默认 8KB），会将剩余部分写入磁盘临时文件，路径由 client_body_temp_path 指定。若该目录：
- 所属用户/组不是运行 Nginx worker 进程的用户（如
www-data或nginx） - 缺少写权限（
chmod不足） - 所在分区磁盘已满或 inodes 耗尽
就会静默截断或丢弃请求体，后端收不到完整数据，表现为“空 body”“JSON parse error”“form data 缺失字段”等现象。
排查命令：
确认 temp 目录位置：
在 nginx.conf 中查找 client_body_temp_path；未配置则用默认路径（如 /var/lib/nginx/body 或 /usr/local/nginx/client_body_temp）
检查权限与空间：
ls -ld /var/lib/nginx/body
df -h /var/lib/nginx
df -i /var/lib/nginx
修复示例：
sudo chown nginx:nginx /var/lib/nginx/body
sudo chmod 750 /var/lib/nginx/body
sudo find /var/lib/nginx/body -type f -mmin +60 -delete # 清理陈旧临时文件
验证请求体缓冲与超限配置
小请求本应全程走内存，但若配置不当，仍可能误入磁盘流程，增加出错概率：
-
client_max_body_size过小 → 触发 413 错误（非损坏，但易被误判） -
client_body_buffer_size过小（如设为 1K）→ 即使 10KB 的 JSON 也会落盘，放大权限/IO 风险 -
client_body_in_file_only off（默认）是安全的；若误设为on，所有 POST 都强制写磁盘，极不推荐
建议配置（根据业务调整）：
client_max_body_size 100M;
client_body_buffer_size 128k;
client_body_in_file_only off;
排除 keepalive 与 HTTP 版本干扰
虽然 least_conn 依赖连接复用才能稳定生效，但错误的 HTTP 头设置可能间接影响请求体传输：
- 未显式设置
proxy_http_version 1.1且未清除Connection头 → 后端可能关闭连接过早，导致分块传输中断 - 后端服务（如 Tomcat、Spring Boot）未启用 keepalive 或连接池耗尽 → Nginx 复用失败，频繁重建连接，增大 body 读取异常概率
确保代理配置含：
proxy_http_version 1.1;
proxy_set_header Connection '';
快速定位是否真由 least_conn 引发
换一种负载策略测试，可快速排除算法干扰：
- 临时将
upstream改为ip_hash或单台server，复现相同 POST 请求 - 若问题消失 → 检查是否某台后端节点自身有缺陷（如仅该节点磁盘满、进程 OOM、反向代理链路多一层）
- 若问题依旧 → 说明根因在 Nginx 全局配置或客户端/网络层，与
least_conn无关
注意：least_conn 只改变目标选择，不改变请求构造与转发行为。只要后端列表中各节点环境一致，它不会单独导致数据损坏。
