代理IP下载大文件总是中断？Range分段、连接复用与断点续传排查
通过代理IP下载镜像、备份或公开数据集时，小文件能够完成，大文件却在中途卡住、重复下载，甚至最后的哈希值不一致。这个现象不能简单归因于“代理速度慢”：Range分段是否被转发、连接是否复用、响应是否被压缩改写，都会改变下载结果。
先确认问题发生在哪一层
把一次下载拆成客户端、代理入口、代理出口和目标站四段。先在授权环境中保存请求时间、状态码、Content-Length、Content-Range、ETag、响应协议和失败时的字节位置。不要只记录“下载失败”，否则很难判断是目标站拒绝续传，还是代理在长连接阶段重置。
| 现象 | 优先检查 |
|---|---|
| 首次请求就返回完整文件 | 是否发送了Range，目标站是否支持分段，代理是否删除了该请求头 |
| 续传返回416 | 本地文件长度超过当前资源，或资源在两次请求间发生变化 |
| 返回206但拼接后哈希错误 | Content-Range区间、响应压缩、重复区间和文件写入偏移 |
| 固定进度后连接重置 | 空闲超时、出口限速、代理缓冲或连接池复用 |
用最小请求验证Range
先用小区间测试，不要一开始就并发切几十段。下面的命令只展示结构，地址和代理凭据请替换为你有权访问的资源：
curl -v -x http://PROXY_HOST:PORT
-H "Range: bytes=0-1023"
-o part-000.bin https://example.invalid/file.bin理想结果是状态码206，并且Content-Range类似bytes 0-1023/TOTAL。如果返回200，先用同一出口对比直连结果，确认是目标站行为还是链路改写。若返回416，读取服务端给出的有效范围，不要盲目把本地文件继续拼接。
断点续传要保存验证信息
可靠的续传至少要保存三类信息：资源标识（ETag或Last-Modified）、已写入的区间、最终校验值。资源标识改变时，旧分片不能继续使用。写文件时按Content-Range的起始偏移定位，而不是按“请求次数”追加；并发分片完成后还要检查区间是否覆盖、是否重叠。
对压缩响应要特别谨慎。若客户端请求了gzip，代理或目标站可能返回压缩流，Content-Length对应的是压缩后长度，不能直接拿来计算解压文件的偏移。需要稳定的二进制分段时，可在测试阶段明确请求Accept-Encoding: identity，并记录服务器是否仍返回压缩内容。
连接复用与超时的排查顺序
- 关闭客户端连接池，使用单次连接复现，判断是否只有Keep-Alive或HTTP/2复用会失败。
- 记录首字节时间、每分钟吞吐和重置位置，区分“从未建立”与“传输一段后被断开”。
- 降低并发和分片大小，观察失败点是否随并发变化；不要把重试当成无限循环。
- 检查代理服务的并发、流量和单连接时长限制，凭据、节点和配额均使用脱敏日志记录。
完成下载后的验收
文件大小一致只是第一关。优先使用发布方提供的SHA-256或签名校验；没有官方哈希时，至少保存响应头、分片区间和下载时间，便于重新复核。若代理下载与直连的哈希不同，应先停止分发文件，重新检查压缩、重定向、Range区间和中间缓存。
代理IP适合在获得授权的下载、备份和跨网络连通性测试中使用。它不能改变资源许可，也不能用来绕过站点的访问控制或下载限制。
