下载老断线？先弄懂 Range 请求在代理里的门道

下载大文件时，网络一抖就失败，再点一次却能“接着下”。这个能力背后是一个叫 Range 请求的机制在起作用，可它走代理时，有时会莫名其妙失灵。

Range 请求是什么：断点续传的底层机制

普通下载时，客户端会请求服务器把整个文件一次返回。支持续传的下载器则会在请求里带上 Range 头，告诉服务器“我要第 N 到 M 字节这一段”。服务器支持的话，会返回 206 Partial Content 和对应的分片；不支持也没关系，返回 200 和整个文件，下载器照样能下，只是没法续。所谓断点续传，本质就是“接着上次的分片继续要”。

走代理后为什么续传会失效

代理原则上只是转发，Range 头原样传给服务器即可，理论上不影响续传。但两类情况会让它失灵：一是中转环节带缓冲，把响应临时收拢后合并输出，206 分片被拼成了完整响应，下载器只好从头开始；二是分片传输中途中转超时或连接被重置，之前那一段并没有真正落到目标服务器，续传时服务器只能从头响应。还有一个常见原因是下载器配置里没开断点续传，或本地缓存被清理，Range 请求根本发不出来。

怎么排查和处理

• 先看本地：确认下载器开启断点续传，别每次都清缓存重来
• 验证是不是代理问题：直连同一下载，直连可续传、走代理不行，问题多在中转环节
• 换缓冲少、连接稳的出口：减少分片传输被中断的概率
• 观察响应头：返回 206 说明分片机制正常；一直 200 说明 Range 头可能被处理掉了

断点续传不是下载器的魔法，是服务器按字节分片的本事。

与 IP 代理的关系：代理对 Range 请求通常原样透传，但中转环节的缓冲与超时策略会直接影响分片传输的稳定性，进而决定断点续传是否可靠；选择传输行为透明、线路稳定的代理出口，能让大文件下载的续传体验更可控。所有使用都应遵循平台规则与法律法规，用于正当业务目的。