上传大文件时，进度条可能一直停在“正在等待服务器响应”，过一会儿又直接失败重来。很多人的第一反应是网络不好，其实问题常常出在一个叫 100-continue 的机制上。
什么是 100-continue：先问后传
想象一个场景：客户端要发一个几百兆的文件，如果直接把内容全发过去，服务器万一不接受，这些流量就白传了。100-continue 的解决思路是“先问后传”：客户端先发出请求头，告诉服务器“我要传这么大一个文件”，服务器同意并返回 100 Continue，客户端才开始传正文；服务器拒绝，客户端就省下整个传输过程。
| 环节 | 做什么 | 卡住时看到的现象 |
|---|---|---|
| 客户端发出请求头 | 带上 Expect: 100-continue 探询 | 长时间停在“等待响应” |
| 服务器返回 100 Continue | 允许继续传输 | 正常流程，无感 |
| 服务器返回 417 | 拒绝传输 | 直接报错中断 |
| 代理中转 | 转发询问与响应 | 询问与正文之间卡顿、超时 |
代理环境里为什么容易卡
多数代理本身不关心 100-continue，只做原样转发，理论上没问题。但实际使用中，一部分中转服务带有“等待响应超时”的设置：客户端在等服务器返回 100 Continue，中转方在等客户端先发正文，双方都在等，最终触发超时——表现就是上传卡在等待、随后失败。另一类情况是中转方对请求头做了裁剪，Expect 头被去掉，客户端直接发正文，问题反而变小，只是少了“先问”的保护。
遇到这种情况怎么处理
- 先定位环节：直连上传试一次，直连正常、走代理卡，问题多半在中转环节
- 换连接保持好的出口：选择对长连接友好的服务，减少等待被中断
- 客户端侧调整：部分工具可关闭 Expect: 100-continue，代价是少了提前确认
- 看服务端反馈：确认是 417 拒绝还是单纯超时，再对症处理
先问后传是好机制，卡住多半是“等”出了超时。
与 IP 代理的关系：代理作为流量中转方，原则上不干预 100-continue，但中转环节的超时策略会直接影响大文件上传成败；选择连接稳定、超时设置合理的出口资源，能明显减少这类卡顿。所有使用都应遵循平台规则与法律法规，用于正当业务目的。