网页里传文件、传图片，走的都是 multipart/form-data 这种表单编码，文件被切成一段段塞进请求体再整体发出去。平时小文件没感觉，一旦上传几十上百兆的文件又恰好走了代理，就开始出现各种”传一半断掉””明明传完却报失败”的怪问题。
大文件上传走代理，问题常出在这几个环节
multipart 上传的请求体是一整包数据，它要完整到达代理、再由代理完整转发到目标服务，任何一环超时或中断，整次上传就废了。和普通浏览不同，上传是”单次大包”，对链路稳定性、超时设置、中间环节的缓冲能力都更敏感。
| 现象 | 常见原因 | 排查方向 |
|---|---|---|
| 传一半卡住不动 | 链路某段超时或丢包 | 查代理与目标之间延迟、换线路试 |
| 传完显示失败 | 服务端等待超时先断开 | 确认目标上传接口的超时上限 |
| 小文件能传大文件不行 | 代理缓冲或中间设备限制单包大小 | 检查代理侧请求体上限配置 |
| 上传占用内存异常高 | 代理整包缓冲后转发 | 改用支持流式转发的通道 |
multipart 本身有什么特性
multipart 请求体用 boundary 字符串把文件数据和其他字段分隔开，服务端靠它拆回文件。这意味着请求体是”一次性完整提交”的语义，不像分段请求那样可以续传；请求头里的 Content-Length 也必须和实际数据一致，否则服务端会直接判失败。所以任何一层对请求体做改写、截断、超时，都会让整个上传作废。
让上传走代理更稳的几个做法
一是给上传这类大请求单独放行，走延迟更低的线路，避免和高并发业务挤同一条通道；二是客户端超时时间放宽到服务端上限以上，别让本地先掐断；三是大文件优先考虑压缩或拆分，把单次包体降到链路能稳定扛住的量级；四是避开业务高峰时段，减少链路拥塞导致的半途中断。这些都不复杂，但能显著降低”传一半失败”的概率。
- 先直连测一次：确认是链路问题还是目标接口本身限制
- 放宽超时：客户端和服务端两侧的上传超时都要大于正常耗时
- 选稳线路：大文件上传走低延迟、少拥塞的出口
- 控制包体：超大文件压缩、分段或错峰上传
上传是”一次成型”的请求，经不起中途任何一环的闪失——链路、超时、包体大小三样对齐，大文件也能稳稳传完。
与 IP 代理的关系：代理IP提供出口与中转能力，而 multipart 上传这类大包请求对链路的稳定性要求更高；选对出口、管好超时与包体，上传才能充分发挥代理链路的价值。所有使用都应遵循平台规则与法律法规，用于正当业务目的。