同一个网页有时秒开有时重新下载？聊聊 ETag 与条件请求

重复访问同一个网页或文件，有时候浏览器瞬间就把内容展示出来，有时候却要重新拉一遍。差别往往不在网速，而在浏览器与服务器之间的”缓存验证”机制——ETag 和条件请求就是其中的关键角色，走代理之后它们的行为也值得了解。

条件请求省下的是重复传输

缓存验证的思路很直接：浏览器把本地缓存资源的”版本标记”带给服务器，询问”我这份还是不是最新的”。服务器比对后如果没变化，就只回一个很小的 304 状态码，不重新传内容；浏览器收到 304 后直接使用本地缓存。一来一回省掉的，是整份资源的重复下载。

条件请求在代理链路里扮演什么角色

转发型代理只负责搬运，不参与缓存判断，验证逻辑发生在浏览器与源站之间，代理把请求和 304 原样转发。缓存型代理则可能替浏览器回答”资源未变化”，减少回源。对普通用户来说，最直观的差别是：走代理后如果每次都收到 200 而不是 304，说明验证没有命中，重复下载在变多。

为什么走代理后 304 变少

一是链路变化：代理出口或会话重建会让部分客户端丢弃本地缓存标记；二是中转环节若做过内容改写，资源的版本标记对不上，服务器只能重新返回 200；三是某些站点对代理链路直接禁用协商缓存。看到”每次都是 200″别急着怪网速，先确认缓存验证有没有生效。

1. 看响应头：资源是否有 ETag/Last-Modified 标记
2. 看状态码：重复访问时是 304 还是 200，决定验证是否命中
3. 对比直连与代理：同一站点直连 304、走代理 200，问题出在中转环节
4. 区分两类缓存：本地强缓存不发请求，协商缓存才走条件请求

ETag 是资源的”版本指纹”，304 是服务器说”没变，用你那份”——省下的每次重复传输，在长代理链路上尤其可观。

与 IP 代理的关系：代理IP负责流量转发，缓存验证发生在客户端与源站之间，但代理链路的稳定性会影响验证命中率；理解 304 与 200 的差别，才能正确判断”走代理后重复下载”是网络问题还是缓存问题。所有使用都应遵循平台规则与法律法规，用于正当业务目的。