点开一个 PDF 链接，浏览器自带的阅读器转了半天圈，最后只留下一片空白；同一份文件下载到本地却打得开，排版也正常。这种”能下载不能预览”的情况，在代理IP 环境下很常见，原因往往不在文件本身，而在预览这条路径上。
预览和下载走的不是同一条路
下载是一次连续读取。浏览器发起一个请求，服务端把文件从头到尾发过来，中途断开还能续传。整个过程对连接的连续性要求高，对请求次数要求低。
预览是多次按需读取。在线阅读器通常不会一次性把整份文件拉下来，而是先取目录和首页，翻到哪页再拉哪页的文件片段。请求次数多、单个请求小，还要频繁用范围请求去取文件中间的某一段。而代理IP 链路的加入，等于给这条按需读取的路径多加了一跳转发，每一次往返都被拉长。
预览还要额外拿渲染资源。不少在线预览服务会把文档先转成图片或网页格式，字体、脚本、样式表要一并加载。文件本身没问题，只要其中一路资源没取到，预览界面就一直转圈。
按这四步排查
- 先确认下载能不能成功。同一个链接，另存为试一次。下载正常、预览失败，说明问题出在预览这条链路，不是文件或代理IP 出口本身。
- 看预览请求有没有走代理IP。有些在线预览服务用的是独立域名，分流规则如果没涵盖它，它就会直连，表现为每次都卡在同一处。
- 检查范围请求是否被中间层改写。预览依赖按字节区间取数据，中间层一旦把这类请求转成整文件请求，或者缓存了错误的片段，页面就会一直加载不出来。
- 分开验证渲染资源。打开开发者面板，看字体、脚本、样式表是不是有失败项。把这几类资源的加载补上，预览往往立刻就正常了。
容易被当成文件损坏的两种情况
一种是大文件分页预览。文件越大，预览服务越倾向于分片返回，中间层对长连接的处理如果不友好，翻页时就会反复卡住，看起来很像”文件坏了”。
另一种是预览服务做了地区调度。文档被送到不同地区的转换服务处理，代理IP 出口地区一变，处理队列和返回内容的版本也可能跟着变，表现是”同一份文件换个出口就能看”。
这两种情况的共同点，是本地文件完好无损，坏的只是取回它的那一段路径。先确认文件本身没问题，再往链路方向查，能省掉大量无效的重新上传。
还有一种情况值得单独说：预览服务有频率限制
在线预览通常按账号或按地址统计调用次数，短时间内反复刷新同一个文档，很容易触发限流，表现是”第一次能看，刷新几次就转圈”。这类限流对代理IP 出口尤其敏感——出口地址一变，服务方看到的就是另一个调用方，限流计数也可能跟着乱。遇到预览时好时坏，先把刷新频率降下来试一次，比反复切换出口更能说明问题。
那到底该先看哪里？
先看请求次数，而不是文件大小。预览这类场景，代理IP 链路的处理能力更多体现在并发与请求次数上，把每一次按需读取都顺畅送出去、让代理IP 出口保持稳定，比单纯提高带宽管用得多。遇到预览转圈，先数一数它到底发了多少次请求，答案通常就藏在里面。