XML上传报413大概率是Nginx拦截，需在http/server/location块中正确配置client_max_body_size并重载服务，注意单位小写、多层代理同步设置及合理设定上限。
XML 文件上传报 413，大概率是 Nginx 拦下来的，不是后端代码问题，优先调 client_max_body_size。
为什么改了 Nginx 配置还是 413？
常见错因是改错了配置层级或没重载服务。Nginx 的 client_max_body_size 必须出现在 http、server 或 location 块里，且子块会覆盖父块值；如果只写在 http 里但你的上传请求走的是某个 location /api/，而该 location 又没显式继承或重设，就可能无效。
- 检查你改的是不是实际生效的配置文件（比如
/etc/nginx/nginx.conf还是/etc/nginx/sites-enabled/default） - 确认修改位置：上传接口对应的那个
location块里最好直接加一句client_max_body_size 20M; - 改完必须执行
sudo nginx -t验证语法，再sudo systemctl reload nginx（不是 restart） - 浏览器开发者工具 Network 标签页看响应头，确认
Server是 nginx，且状态码确实是 nginx 返回的 413（而非后端透传）
XML 文件特别容易触发 413 吗？
不是 XML 本身特殊，而是它常被用于传输大批量结构化数据（比如导出报表、系统间同步），体积动辄几 MB 起。HTTP 请求体（request body）大小超限，Nginx 就会在读取阶段直接拒绝，连后端进程都不会触达。
- 纯文本 XML 压缩率低，比同内容 JSON 或二进制协议更占体积
- 某些客户端（如 Java 的
HttpURLConnection）默认不发Content-Length，Nginx 在 chunked 编码下也可能提前截断 - 如果用了反向代理链（比如 Nginx → Traefik → 应用），每一层都得单独调
client_max_body_size或等效配置
client_max_body_size 设多大才安全？
不能无脑设成 0（表示不限），生产环境必须设合理上限。设太大可能被用来耗尽服务器内存或触发慢速攻击；设太小又拦住合法上传。
- 先查业务侧最大预期 XML 体积（比如历史最大文件是 8.2MB），再上浮 20%～50%，例如设为
12M - 避免用
G单位（如1G），Nginx 解析时对大数值更敏感，易因空格或单位误写失效 - 单位只认
k、m、g（小写），20M可以，20MB会报配置错误 - 注意：这个值只控制请求体，不影响响应体大小，也不影响磁盘临时文件（
client_body_temp_path）配额
真正麻烦的是多层代理或容器化部署——K8s Ingress、云厂商 LB、Nginx Pod 里的配置可能各管一段，漏掉任意一层都会卡在 413。别只盯着最外层。
