如何让服务器返回压缩响应：节省流量的分步实战指南

09.09.2026

文章目录

HTTP 请求中一个简单的请求头，就能让下载的数据量缩减数倍。这里说的是客户端和服务器之间关于压缩的协商机制。如果你在使用代理，并且每个 GB 的流量都要付费，那么这个话题会直接影响你的账单。在本指南中，我们将深入探讨如何让服务器返回压缩响应，如何在自己的任务中衡量实际的节省效果，以及你会遇到哪些陷阱。

简介：一个请求头就能大幅削减流量

HTTP 压缩的工作原理出奇地简单。客户端告知服务器它支持哪些压缩算法。服务器选择合适的算法压缩响应体，然后发送。客户端在收到数据后进行解压。最终，通过线路传输的并不是原始的 HTML 或 JSON，而是其压缩版本，通常其大小会比原始数据小 3-5 倍。

学完本指南你将获得什么。 读完本指南，你将知道如何在客户端启用压缩，如何验证服务器是否真的返回了压缩响应，如何以字节为单位衡量压缩前后的流量节省情况，以及如何诊断压缩无法正常工作的场景。当你通过 Proxeon 代理传输流量并需按 GB 付费时，这些能力都至关重要。

本指南适合谁。 本材料面向开发人员、爬虫专家、自动化工程师以及所有通过代理编写 HTTP 客户端的人。适用中等技术水平。我们不会深入讲解流量消耗的构成全貌，这有专门的文章介绍，此处将专注讲解压缩本身。

你需要了解什么。 只需具备基本概念，知道什么是 HTTP 请求和响应，什么是请求头，以及如何运行终端命令。如果你曾用 curl 发起请求，或用 Python 或 Node.js 写过脚本，那么你就能轻松跟上。

需要多长时间。 阅读并复现所有示例大约需要六十分钟。而当你亲眼对比压缩响应和未压缩响应的大小时，前十分钟就能看到初步的实践成果。

准备工作

开始之前，请确保你拥有所需的一切。这样可以节省时间，避免中途出错的困扰。

所需工具

curl 7.72 或更高版本。在 2026 年的构建版本中，大多数系统开箱即支持 brotli 和 zstd。
Python 3.10 或更高版本，并安装了 requests 库，此外，若要支持 brotli 压缩格式，请安装 brotli 或 brotlicffi 包。
Node.js 18 或更高版本。其内置的 zlib 模块支持 gzip、deflate、brotli 压缩算法。
如果你希望在每日工作的环境中测量节省效果，则需要拥有访问 Proxeon 代理的权限。
用于编写脚本所需的任意文本编辑器。

系统要求

任何现代操作系统均适用：Windows、macOS 或 Linux。所有示例均为跨平台的。2 GB 的内存就足够了。CPU 没有特别要求，但在处理大量数据时，最大压缩级别的 brotli 算法可能会明显占用一个 CPU 核心。

需要安装和检查的内容

打开终端并运行命令检查 curl 版本：
```
curl --version
```
查看输出的第一行。那里有版本号。确保在功能列表中能找到 brotli，并尽可能找到 zstd。
用命令
```
python --version
```
检查 Python，并安装依赖项：
```
pip install requests brotli
```
用命令
```
node --version
```
检查 Node.js。

提示： 如果系统里的 curl 没有编译进 brotli 支持，请通过操作系统的官方包管理器安装。在 2026 年的企业构建中，brotli 几乎总是默认包含在内的。

备份。 在本指南中，我们不修改生产服务器的配置，也不接触生产数据。我们仅发送请求并测量响应。因此，无需备份。但是，如果你后续决定在自己的 Web 服务器上启用压缩，请务必在编辑前保存原始的配置文件。

✅ 检查： 三种工具都能响应版本检查命令并显示版本号。这意味着准备工作已完成，可以继续下一步。

用通俗的语言讲解基础概念

在动手之前，我们先理清术语。这会花五分钟，但可以减少后续的困惑。

压缩协商是如何工作的

HTTP 压缩依赖于三个请求头部。理解它们的作用能解决大多数问题。

客户端发送的 Accept-Encoding。 这是你的客户端随请求一起发送的请求头。其中列出了客户端可以解压的压缩算法。例如，字符串

Accept-Encoding: gzip, br, zstd

告诉服务器：我可以处理 gzip、brotli 或 zstd，任选其一。如果缺少此请求头，服务器将假定客户端需要未压缩的响应。

响应中的 Content-Encoding。 这是服务器在响应中添加的请求头。它表示响应体使用了哪种压缩算法。如果你看到

Content-Encoding: br

，则表明响应体已使用 brotli 算法压缩，客户端需要将其解压。如果响应中没有此请求头，则响应体为原始状态。

服务器端的 Vary。 Vary 请求头告知缓存和代理，响应取决于请求中的某些请求头。对于压缩，至关重要的值是

Vary: Accept-Encoding

。这意味着，对于使用 gzip 的客户端和不使用压缩的客户端，必须在缓存中存储不同版本的响应。如果没有此请求头，缓存可能会向无法解压的客户端提供压缩响应，反之亦然。

协商的核心思想

记住这个顺序。客户端通过 Accept-Encoding 发出请求。服务器决定并通过 Content-Encoding 响应。中间环节依靠 Vary。如果这个链环中任何一个环节出现问题，你都会得到未压缩的响应，并为你不需要的流量支付额外费用。

提示： 即使你的 HTTP 库会自动添加 Accept-Encoding，也始终检查实际的响应头。自动化有时会静默，而流量却在消耗。

gzip、deflate、brotli、zstd：算法对比

HTTP 中存在四种常见的压缩算法。它们在压缩率和 CPU 负载方面各不相同。让我们逐一分析，并用表格汇总数据。

gzip

最古老、最通用的算法。几乎处处支持：任何服务器、客户端、代理。它在文本数据上提供了良好的压缩率，且 CPU 负载适中。如果你不确定选择哪一种，请从 gzip 开始。

deflate

与 gzip 近亲，内部使用相同的算法，但封装不同。在实际使用中较少，且有时服务器端实现存在错误。压缩率与 gzip 大致相当。没有特别的理由选择 deflate 而不是 gzip。

brotli

专为 Web 设计的现代算法。在文本数据上，尤其是 HTML、CSS 和 JSON，压缩效果明显优于 gzip。代价是在最高压缩级别下，压缩端的 CPU 负载会更高。解压速度快。在请求头中表示为 br。

zstd

快速的现代算法，压缩级别可灵活调整。压缩率接近 brotli，但压缩速度更快。在 Web 中的支持度正在增长，到 2026 年，大多数主流服务器和客户端都能识别它。在请求头中表示为 zstd。

典型文本响应对比表

假设有一个未压缩大小为 1000 千字节的典型 JSON 响应。数据是近似值，会因具体内容而异，但数量级是准确的。

未压缩： 1000 KB，节省 0%，CPU 负载最低。
gzip 级别 6： 约 190 KB，节省约 81%，负载较低。
deflate 级别 6: 约 195 KB，节省约 80%，负载较低。
brotli 级别 5： 约 165 KB，节省约 83%，负载中等。
brotli 级别 11： 约 140 KB，节省约 86%，负载较高。
zstd 级别 3: 约 175 KB，节省约 82%，负载较低。
zstd 级别 19： 约 150 KB，节省约 85%，负载中等。

简单的结论是：在文本数据上，任何压缩都能将流量降低约五倍。不同算法之间的差异仅在几个百分点内。因此，对于通过代理节省流量，关键不在于选择哪种算法，而在于压缩是否已启用。

提示： 如果你只下载数据而不是提供，那么你 CPU 的负载仅来自解压，而所有算法的解压速度都很快。因此，你可以放心地请求最节省流量的选项。

✅ 检查： 你了解 brotli 和 zstd 在文本上的效果通常略优于 gzip，但 gzip 最兼容。这对实践来说已经足够了。

第 1 步：发送请求并检查响应是否被压缩

本阶段的目标。 学会查看 Content-Encoding 请求头和实际的响应体大小。没有这个，就无法测量节省效果。

使用 curl 检查

打开终端。
首先，在不请求压缩的情况下获取资源，以获取原始大小。执行：
```
curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data
```
记录下数值。这是未压缩响应的字节大小。
现在，请求压缩。--compressed 标志会自动添加 Accept-Encoding 并解压响应：
```
curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data
```
比较两个数值。在内容相同的情况下，第二个数值应显著小于第一个。

重要提示： 使用 --compressed 时，curl 的 size_download 指标反映的是解压后数据的大小，而不是实际通过网络传输的流量大小。要查看实际网络传输的大小，请关注响应头，并使用我们将介绍的中间测量方法。

查看响应头

使用输出请求头的标志执行请求：

curl -s -I --compressed https://example.com/api/data

在输出中查找 Content-Encoding 行。如果包含 gzip、br 或 zstd，则说明服务器返回了压缩响应。
查找 Vary 行。其中包含 Accept-Encoding 表示缓存配置正确。

提示： 要明确指定所需算法，请手动添加请求头：

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

这样你可以检查服务器是否真的支持 brotli。

通过 Proxeon 代理工作

要在真实场景中测量节省效果，请通过代理发送请求。在 curl 中，使用 -x 标志：

curl -s --compressed -x http://用户名:密码@proxeon地址:端口 -o /dev/null -w "%{size_download}" https://example.com/api/data

这样你就能看到压缩是否能通过代理到达，以及请求头是否在路上被剥落。

预期结果。 你会看到两个数值：未压缩响应的大小和压缩后的大小。并且你在响应中看到 Content-Encoding 请求头。这表示机制正在工作。

可能的问题： 如果两个数值相同且缺少 Content-Encoding 请求头，则说明服务器未返回压缩。原因我们将在单独的章节中讨论。

✅ 检查： 在使用 --compressed 标志后的响应中，存在包含某种算法的 Content-Encoding 行。此步骤已完成。

第 2 步：用 Python 测量实际节省效果

本阶段的目标。 通过可复用到你自己任务中的工作脚本，获得压缩前后精确的网络流量数据。

简单测量（通过 requests）

默认情况下，requests 库会自行添加 Accept-Encoding 并解压响应。为了测量实际网络大小，我们需要查看解压前原始内容的长度。

创建 measure.py 文件。
粘贴以下代码：

import requests
url = "https://example.com/api/data"
# 无压缩请求
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# 带压缩请求
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "无")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("未压缩字节数:", size_plain)
print("压缩算法:", encoding)
print("网络传输约字节:", size_wire)
print("解压后字节数:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("流量节省百分比:", saved)

注意： Content-Length 值有时不存在，尤其是在 chunked 流式传输时。如果缺失，请使用下面更准确的方法。

精确测量网络流量

为了精确测量实际通过线路的数据量，请禁用自动解压，并计算原始流的字节数。

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# 禁用自动解压以查看原始大小
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("算法:", r.headers.get("Content-Encoding", "无"))
print("网络原始字节数:", raw_bytes)

将 raw_bytes 与未压缩请求的大小进行比较。差值即为你实际节省的流量。

通过 Proxeon 代理测量

添加 proxies 参数，以获取现实条件下的数据：

proxies = {
"http": "http://用户名:密码@proxeon地址:端口",
"https": "http://用户名:密码@proxeon地址:端口",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

提示： 多次运行测量并取平均值。动态响应的大小会发生变化，因此单次测量可能会误导。

预期结果。 脚本打印压缩算法和原始字节数，该数值应小于未压缩响应的字节数。如果在文本资源上节省了 70% 甚至更多，那么一切正常。

✅ 检查： 在输出中，算法不等于“无”，且原始字节数少于未压缩的情况。完美。

第 3 步：在 Node.js 上进行同样的测量

本阶段的目标。 为那些用 Node 编写客户端的人提供一个可行的 JavaScript 测量工具。

测量原始流

创建 measure.js 文件。
粘贴以下代码，该代码会在解压前计算字节数：

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || '无', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('未压缩字节数:', plain.bytes);
 console.log('算法:', comp.enc);
 console.log('网络压缩字节数:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('节省百分比:', saved);
})();

重要提示： 本示例中，我们直接读取来自 res 的原始流，并且不连接 zlib。因此，bytes 计数器显示的正是网络流量。这也是你向代理提供商支付的流量。

在 Node 中手动解压

如果你还需要读取内容，请通过内置的 zlib 模块解压流：

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

提示： 在较新的 Node.js 版本中，对于 zstd，有 zlib.createZstdDecompress 方法。如果你的版本不支持，请升级 Node，或使用单独的 npm 包。

预期结果。 Node 打印的节省百分比应与你在 Python 和 curl 中获得的结果相当。

✅ 检查： 三种工具给出的节省数据接近。这意味着你的测量是可信的。

第 4 步：为什么响应是未压缩的

本阶段的目标。 学会诊断压缩未生效的原因，并解决问题。这是实际中最常见的问题。

第一种情况：客户端未请求

最常见的原因。你的 HTTP 客户端未发送 Accept-Encoding 请求头，服务器诚实地返回了未压缩的响应。例如，当你手动构造请求头而忘记压缩，或使用低级套接字时。

检查实际发送给服务器的内容。在 curl 中添加 -v 标志，在出站请求头中找到 Accept-Encoding 行。
如果该行不存在，请通过 -H 或 --compressed 标志显式添加。
在 Python 中，确保没有将请求头覆盖为空值。

注意： 某些库在你手动设置任何请求头时，会停止添加默认值。如果你手动设置 User-Agent，请同时检查 Accept-Encoding 是否一并消失。

第二种情况：服务器不支持

服务器可能根本不支持压缩，或者不支持你请求的算法。在这种情况下，服务器会返回未压缩的响应，这是标准允许的行为。

依次请求不同的算法：先是 gzip，然后是 br，最后是 zstd。
观察在哪种算法下响应才存在 Content-Encoding。
如果都不存在，则服务器不提供压缩。对于外部服务器，你无法更改，但如果有其他端点或 API，你可以选择。

提示： 许多 API 只为超过特定大小的响应提供压缩。小响应通常故意不压缩，因为压缩的开销超过了收益。

第三种情况：中间代理剥离了请求头

你和服务器之间可能有一个缓存节点、网关或代理，会删除或修改压缩请求头。有时中间代理为自身目的解压响应，然后向你提供已解压的版本。

分别通过直接连接和代理发送请求，比较 Content-Encoding 请求头。
如果直接连接有压缩，而通过代理没有，则代理在干预。
通过 Proxeon 代理时，压缩是透明传输的，因此如果你看到差异，问题应定位到目标服务器或其 CDN。

预期结果。 你确切知道压缩在哪个环节丢失了，并明白该如何处理。

✅ 检查： 你能用一句话解释为什么某个响应未压缩。诊断技能已掌握。

第 5 步：压缩操作中的陷阱

本阶段的目标。 避免那些会破坏数据或扭曲测量的细微错误。

双重压缩

有时内容已在应用级别压缩，服务器还会再次压缩。反之，你在请求体中压缩，而代理或库再次压缩。双重压缩几乎不会有额外收益，有时甚至会增大体积，并且绝对浪费 CPU 资源。

检查响应中 Content-Encoding 是否同时存在两个值，例如 br 内的 gzip。
不要手动压缩库会自动压缩的内容。
如果看到编码链，则按相反顺序解压。

损坏的流

连接中断或中间代理错误可能导致压缩流不完整。解压时你会遇到错误或数据截断。

始终将解压操作放在错误处理中。
解压出错时重试请求，而不是尝试读取损坏数据。
如果指定了 Content-Length，请将实际大小与它进行比较。

注意： 切勿将部分解压的数据保存为最终结果。损坏的 JSON 看起来可能合理，但在后续处理中会导致隐蔽的错误。

当库不自动解压时进行手动解压

如果你为了精确测量而关闭了自动解压，或者使用低级客户端，则必须手动解压。Python 示例：

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

提示： 如果 deflate 解压失败，请尝试使用 wbits 参数设为 minus fifteen 的 zlib.decompress 调用。某些服务器发送的是没有 zlib 封装的原始 deflate 流。

预期结果。 你能手动解压任何一种支持的格式，并正确处理流错误。

✅ 检查： 你的脚本在遇到损坏响应时不会崩溃，而是重新请求。稳定性已达成。

第 6 步：不需要压缩的内容

本阶段的目标。 不要将 CPU 和时间浪费在压缩已经压缩过的内容上。这可以在不影响流量节省的情况下节约资源。

已压缩的格式

某些数据存储格式内部已经使用了压缩。尝试再次压缩是徒劳的：收益仅为零点几个百分点，却白白增加 CPU 负载。

图片： JPEG、PNG、WebP、AVIF 已在各自格式内部进行压缩。
视频： MP4、WebM、MKV 包含高度压缩的视频流。
音频： MP3、AAC、OGG 本质上已压缩。
归档文件： ZIP、RAR、7z、gz 等已压缩容器。

对于此类资源，Accept-Encoding 不会为响应体带来任何节省。而且，服务器通常也不会再次压缩它们，因为会按 MIME 类型列表进行配置。

值得压缩的内容

HTML、CSS、JavaScript。
JSON 和 XML API 响应。
普通文本、CSV、日志文件。
SVG，因为它本质上是文本。

提示： 如果你主要下载媒体文件，压缩的节省几乎为零。此时，赢家是其他方法：只请求所需尺寸和格式，而不是压缩本身。但那是流量管理的话题，而不是压缩。

预期结果。 你不会因为压缩二进制格式而浪费资源，并且只在压缩能真正提供帮助的地方使用压缩。

✅ 检查： 你能在一秒钟内判断特定类型的响应是否值得压缩。理解已形成。

结果验证

是时候确认你已正确设置一切。请按检查清单进行操作。

工作状态检查清单

你的客户端发送包含所需算法的 Accept-Encoding 请求头。
在文本资源的响应中，存在包含这些算法之一的 Content-Encoding 请求头。
测量脚本显示流量规模至少比未压缩文本小 70%。
通过 Proxeon 代理时压缩得以保留，数据与直接请求一致。
解压过程不报错，数据可正常读取。
你不会尝试压缩二进制格式。

如何测试

选择三个不同的端点：一个返回 JSON，一个返回 HTML，一个返回图片。
用你的测量脚本逐个通过。
确保前两者的节省效果显著，而第三者的节省几乎为零。

成功指标。 对于文本 API，你能稳定获得 70% 到 90% 范围内的节省。对于媒体，节省最小，这是正常的。通过代理时数据不会恶化。

✅ 检查： 检查清单中的六个项目均已完成。压缩已正确配置并测量。

常见错误及解决方案

以下是按问题 - 原因 - 解决方案三个部分整理的常见问题。

响应未压缩（尽管已发送 Accept-Encoding）

原因： 服务器不支持此内容类型或此响应大小的压缩。 解决方案： 尝试其他算法，并确保资源是文本且足够大。

curl 中看不到节省，size_download 不变

原因： --compressed 标志显示的是解压后的大小。 解决方案： 使用单独的脚本测量网络流量，禁用自动解压，如 Python 和 Node 步骤所示。

库返回乱码而非文本

原因： 您已禁用自动解压，但未手动解压流。 解决方案： 确定 Content-Encoding，然后应用相应的解压函数。

解压 deflate 时出错

原因： 服务器返回原始 deflate 流而没有封装。 解决方案： 使用 wbits 参数 minus fifteen 进行解压。

通过代理压缩丢失

原因： 路径上某节点修改了请求头，通常是目标网站的 CDN。 解决方案： 比较直接和代理请求，确定是哪个环节。Proxeon 代理透明传递请求头，因此问题通常出在服务器端。

重复测量中响应大小不同

原因： 内容是动态的，会随请求而变化。 解决方案： 对多个测量取平均值，并在相同请求参数下进行比较。

Content-Length 缺失

原因： chunked 流式传输不预先指定长度。 解决方案： 在读取流时手动计算字节数，如脚本示例所示。

双重压缩增加 CPU 负载

原因： 内容在不同层级被压缩两次。 解决方案： 移除库或服务器已执行的压缩操作。

高级功能

掌握基本场景后，还有很多可以探索的方向。

算法优先级选择

在 Accept-Encoding 请求头中，您可以使用 q 值指定权重，向服务器提示偏好。例如，

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

表示优先 zstd，其次是 brotli，再其次是 gzip。并非所有服务器都考虑权重，但许多服务器都会尊重顺序。

缓存解压数据

如果你经常访问同一资源，请在本地缓存解压后的结果。这可以降低流量，并减轻重复解压带来的 CPU 负载。

按 URL 列表进行批量测量

将测量脚本包裹在端点列表的循环中，并收集节省数据表。这样你可以找到项目中最重且未压缩的响应，并优先处理它们。

提示： 以字节为单位记录每天的节省量。乘以每 GB 的价格，你就能直观地看到通过代理启用压缩带来的经济收益。

✅ 检查： 通过运行一次脚本，你能够为多个资源生成节省汇总表。

FAQ

始终请求 brotli 而不是 gzip 吗？

如果你只下载，所有算法的解压速度都很快，因此可以请求最有效的算法。实际上，请在 Accept-Encoding 中同时包含 gzip、br、zstd。服务器将选择可用的最优算法。

文本 API 的压缩能节省多少流量？

通常为 70% 到 90%。也就是说，原本 1 GB 的响应，通过网络传输时可能只需 150 到 200 MB。在按 GB 计费时，节省是直接且显著的。

压缩会影响响应速度吗？

较小的数据量传输更快，尤其是在慢速链路上。服务器端的压缩延迟，通常会被传输时间的减少而充分抵消。

为什么 curl 在没有压缩标志的情况下显示相同大小？

因为 --compressed 显示的是解压后的大小。实际网络流量要小得多。使用单独的脚本测量原始流。

POST 请求体可以压缩吗？

可以，客户端在请求中设置 Content-Encoding，但服务器必须支持解压。并非所有服务器都支持，因此请查阅 API 文档。

压缩在 Proxeon 代理上有效吗？

是的。代理会透明地传递 Accept-Encoding 和 Content-Encoding 请求头，因此所有节省都会保留。因此，直接在代理上进行测量是最有利的，因为它模拟了真实环境。

如果服务器不提供压缩怎么办？

确保你请求了压缩，并且资源是文本。如果服务器仍然无响应，你无法更改外部服务器，但可以选择其他端点，或将压缩放在自己的缓存层。

是否应通过 Accept-Encoding 压缩图像？

不。JPEG 和 WebP 等格式已经压缩过了。额外压缩不会有收益，只会增加 CPU 负载。

如何在 zstd 和 brotli 之间选择？

对于下载场景，流量上的差异仅在几个百分点内。请同时将两者都加入 Accept-Encoding，让服务器决定。如果服务器只支持一种，你会得到那一种。

客户端工作是否需要 Vary？

作为客户端，你不需要设置 Vary，它由服务器设置。但理解它是很有用的：它解释了为什么缓存有时返回压缩版本，有时返回未压缩版本。

结语

你已完成了从理论到实际测量的整个流程。现在你理解了压缩是如何通过 Accept-Encoding、Content-Encoding 和 Vary 进行协商的。你掌握了如何在 curl、Python 和 Node.js 中请求压缩，并测量压缩前后的实际网络流量。你知道响应未压缩的可能原因，并能通过三种典型情况进行诊断。你也了解了双重压缩、损坏流和手动解压等陷阱。并且，你已不再浪费资源去压缩图像、视频或归档文件。

下一步怎么做。 在你项目中的所有主要端点上运行测量脚本。找到压缩未启用的端点，并显式请求它。记录节省字节数的日志，以便了解通过 Proxeon 代理时的经济收益。当你掌握了基本场景后，继续进行按 URL 列表的批量测量和使用 q 值设置算法优先级。

压缩是减少流量支出最便宜的方式之一。一个正确发送的请求头就能使数据量减少数倍。现在，这个工具已经掌握在你的手中，你可以有意识并准确地进行应用。

关于作者

Roman Melnikov

Technical Writer and System Administrator

工作经验： Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.

教育背景： Bauman Moscow State Technical University. Information Systems and Technologies

专业领域：

Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting