轮询模式下文件上传中断本质是配置断层与链路不一致，需从请求接入、传输中断、后端接收三层面排查，重点对齐超时、大小限制及会话保持策略。
轮询模式下文件上传中断，本质不是轮询本身的问题，而是轮询在长耗时、大体积请求场景中暴露了配置断层和链路不一致。排查要从“请求进不来”“传到一半断”“后端收不到”三个层面切入，重点看是否所有环节的限制都对齐。
先确认是不是轮询导致的路由漂移
轮询本身不保证同一文件的多次请求落到同一台后端。如果上传是分段进行（如带 upload_id 或 chunk 参数），而你又没做会话保持，不同分片可能被分到不同机器，后端无法合并——表现就是“传了一半失败”“最后返回 404 或 500”。
检查点：
- 查看 access log 中 $upstream_addr 字段，对比同一 upload_id 的多个请求是否始终打到同一个后端地址
- 若出现跳变，说明轮询在“均匀分发”，但业务需要“粘性”。应改用 hash $arg_upload_id consistent 或 ip_hash（仅限客户端 IP 稳定场景）
- 禁用纯轮询：upstream 块里不要只写 server 列表，必须显式声明策略，避免隐式 fallback
查超时与大小限制是否全线对齐
上传中断常无明确错误码，前端只报“网络错误”或“连接已重置”，实际是某一层提前关闭连接。轮询不会加重这个问题，但会让问题更难定位——因为失败可能随机出现在任意一台后端。
必须同步检查并统一以下五项（建议全部设为 300～3600 秒，按业务最大上传时长倒推）：
- client_max_body_size：配在具体上传 location 里，不能只写在 http 或 server 块（会被覆盖）
- client_body_timeout 和 client_header_timeout：防止上传过程空闲超时断连
- proxy_send_timeout：Nginx 向后端发送整个文件体的最大等待时间
- proxy_read_timeout：Nginx 等待后端响应（如合并完成）的最长时间
- 后端自身限制（如 PHP 的 post_max_size、upload_max_filesize，或 Spring Boot 的 max-file-size）：必须 ≥ Nginx 设置，且三者数值逻辑自洽
看连接状态与临时资源是否异常
轮询下多台后端共用同一套 Nginx 配置，一旦某台后端处理慢或假死，Nginx 可能持续向其转发上传请求，造成积压、超时、临时磁盘爆满。
排查动作：
- 检查 client_body_temp_path 所在磁盘使用率（默认 /tmp），上传中文件会暂存于此，空间不足直接中断
- 确认 proxy_buffering off 已启用：避免 Nginx 缓存整个文件体导致内存/磁盘压力过大
- 在 upstream 中为每台 server 加 max_conns=100 和 slow_start=30s，防止单节点过载拖垮整体
- 开启健康检查：proxy_next_upstream error timeout http_500 http_502 http_503 + max_fails=2 fail_timeout=30s，让故障节点快速摘除
验证日志与真实路径是否匹配
很多中断问题源于 location 匹配错位。例如上传接口是 /api/v1/upload，但配置写在了 /upload 或根 location 下，导致 client_max_body_size 等参数未生效。
操作建议：
- 用 nginx -T 输出完整生效配置，搜索你的上传路径，确认最终生效的 location 块包含所有必要指令
- 在对应 location 中加 access_log /var/log/nginx/upload.log main;，单独记录上传行为，比混在主日志里更容易分析失败时间点
- 检查是否有 rewrite、auth_basic、limit_req 等指令意外拦截了上传请求（尤其注意 Range 请求或 multipart boundary 被误判）
