代理流量怎么节省？用 HTTP 缓存和条件请求减少重复下载

该图展示的是一般的缓存代理，并不表示 MooProxy 代理入口提供缓存。本文介绍的客户端条件请求需要自行实现。

先建立可比较的基线

选取同一目标、同一地区、同一会话和固定时间段，分别记录请求数、状态码、响应主体字节数、有效数据比例与代理账单。业务成功以内容正确为准，而非只看 200。将首次访问和重复访问分开统计，再观察 304 比例及数据的新鲜度。

例如，一份 2 MB 响应下载 1,000 次约为 2,000 MB。若其中 900 次在验证后返回无响应主体的 304，则主体部分约节省 1,800 MB；这只是示例，不包括请求头、TLS、重试及其他实际计费流量。

理解 ETag 与 304

服务器提供 ETag 时，客户端可在下次请求发送 If-None-Match。资源未变化时，服务器可以返回 304 Not Modified，客户端继续使用此前保存的内容；304 并不是空数据的替代品。Last-Modified 与 If-Modified-Since 是另一组验证机制。具体可缓存时间和范围以响应的 Cache-Control 等指令为准。

curl -sS -D headers.txt -o response.json https://example.com/data
# 从 headers.txt 读取服务端返回的 ETag，保留引号
curl -sS -D recheck-headers.txt -o recheck-body.txt \
  -H 'If-None-Match: "ETAG_FROM_RESPONSE"' https://example.com/data

示例仅对你有权访问且支持验证的资源有效。example.com/data 是占位地址，不一定存在。生产程序应在 304 时读取自己的已缓存副本；若副本缺失则重新获取完整响应。

隔离账户、地区和内容版本

private、no-store、Vary 和认证状态会影响能否复用响应。不要跨账户共享含个人信息的缓存；语言、授权、地区、Cookie 及其他影响内容的请求条件应纳入缓存边界。即使 URL 相同，不同出口地区也可能返回不同价格或内容，不能因为 URL 相同就合并。

对于登录态、余额、库存或价格等高变化数据，先由数据所有方确认刷新要求；如果响应要求不存储，就不要保存。缓存不能绕过站点的权限与访问限制。

分阶段上线并验证收益

1. 选一小组允许缓存的公开资源，记录原始数据和时间。
2. 启用条件请求，核对 200 与 304 的内容一致性及更新延迟。
3. 对照代理账单，计算节省量；记录失败、重试和业务错误。
4. 设置清晰的过期、失效与回滚策略，再逐步扩大范围。

在 Playwright 流量优化指南 中可以继续查看浏览器资源策略。