点上传之后进度条一动不动，或者文件刚发出去服务端就回一个”内容太长”——这类问题在走代理IP 上传大文件时反复出现，很多人以为是带宽不够，其实多半是 100 Continue 这个协议预约机制被中间层处理坏了。
100 Continue 是客户端与服务端之间的一次预约
发送一个大文件前，客户端先带一个 Expect: 100-continue 请求头，意思是想先问问服务端：这个请求你收不收？服务端回复 100 Continue，等于说”继续发吧，我等着”；客户端这才开始传送请求体。这样做的价值是省带宽——万一服务端要拒收，客户端就不用白传一大段数据。
这是一个典型的”先确认、再发送”的节奏。正常直连时它几乎感觉不到存在，因为两边的行为都有标准。可一旦中间夹了一层代理IP 转发，这个预约节奏就可能被打乱。
代理IP 链路上最常见的两种表现
表现一：中间层提前替服务端答应了。客户端问”收不收”，中间层不等服务端表态，自己先回了一个 100 Continue。客户端以为服务端准备好了，开始传送请求体；可服务端那边可能还没准备好接收，或者根本不知道有这回事，于是一边传一边等，最终超时或断开。表现就是上传卡在中间，进度条不动。
表现二：中间层把 100 响应扣下了。服务端其实回了 100，但中间层只转发最终响应，把这类中间响应吞掉。客户端等不到答复，按自己的超时策略继续等，或者干脆重试。表现是上传特别慢，或者”发送请求体”阶段反复重来。
四步排查
- 看请求头。打开抓包或开发者工具，确认请求里确实带着 Expect: 100-continue。没有这个头，说明是客户端或库的配置问题，和链路无关。
- 直连对比。同一个上传操作，关掉代理IP 试一次。直连正常、走代理IP 卡住，问题就在转发这一段。
- 看中间层行为。走代理IP 时抓一次完整交互，看 100 响应到底是谁回的、有没有到客户端。谁能回、谁没回，一次就能看清楚。
- 调整客户端策略。如果链路不支持干净的转发，可以让客户端不依赖 100-continue，直接发送请求体，或把等待 100 的超时调短。多数上传库都允许改这一项。
容易误判的两处
当成带宽问题。上传卡住时最容易想到的就是网速。但 100 Continue 的问题特征是”没开始传就卡住”，和传着传着变慢完全不同，从时序上就能区分。
当成接口 bug。服务端偶尔报”请求体不完整”，容易被当成服务端代码问题。实际上请求体根本没送过去，服务端收到的就是不完整的数据。排查时先确认数据有没有离开本机，再谈服务端。
这类问题有个共同点：协议本身是好的，坏在转发环节的处理。弄清楚你的代理IP 链路对中间响应的处理方式，比反复调超时参数更管用。抓一次完整交互，100 是通的还是被吞的，一目了然。