HAProxy 通过配置 compression algo 和 compression type 指令开启 HTTP 压缩，适用于文本类内容传输场景，主要风险是会增加 CPU 消耗。
先说结论：HAProxy 支持在配置文件中使用 compression 指令族启用 gzip 或 deflate 压缩，能有效减少文本数据带宽占用，但需避免对已压缩资源重复处理。
- 适合：HTML、CSS、JavaScript、XML 等文本类型响应
- 先准备：确认 HAProxy 版本支持压缩模块，备份配置文件
- 验收：通过 curl 请求头验证 Content-Encoding 是否变为 gzip
命令速用版
在 haproxy.cfg 的 defaults、frontend 或 backend 段添加以下配置即可启用基础压缩：
compression algo gzip type text/html text/css application/javascript application/xml
修改完成后执行 systemctl reload haproxy 使配置生效，无需重启服务。
为什么会这样
HAProxy 压缩功能通过拦截后端响应并在发送给客户端前进行编码来减少传输体积。开启压缩后，HAProxy 会检查客户端请求头中的 Accept-Encoding 字段，若客户端支持 gzip 或 deflate，则对匹配 compression type 的响应内容进行压缩处理。这一过程将网络传输压力转移到了 HAProxy 所在服务器的 CPU 上，适合带宽受限但 CPU 资源充足的场景。
分步处理
1. 编辑配置文件：使用 vim 打开/etc/haproxy/haproxy.cfg，找到 defaults 或具体的 frontend 段。
2. 添加压缩算法：输入 compression algo gzip，指定使用 gzip 算法，部分版本支持 deflate 可选。
3. 指定压缩类型：输入 compression type text/html text/css application/javascript，仅对文本类 MIME 类型开启压缩，避免对图片视频浪费 CPU。
4. 检查配置语法：执行 haproxy -c -f /etc/haproxy/haproxy.cfg 确保无语法错误。
5. 重载服务：执行 systemctl reload haproxy 应用更改，避免中断现有连接。
怎么验证是否生效
使用 curl 命令模拟支持压缩的客户端请求，观察响应头是否包含 Content-Encoding: gzip。执行 curl -H "Accept-Encoding: gzip" -I http://你的域名，若返回头中出现 Content-Encoding: gzip 且 Content-Length 明显减小，说明压缩已生效。若未出现该字段，检查客户端请求头是否携带 Accept-Encoding 或配置是否未重载。
常见坑
1. 重复压缩：不要对图片、视频、已压缩的归档文件开启压缩，这会消耗 CPU 且几乎不减小体积。
2. CPU 飙升：高并发下压缩会显著增加 CPU 负载，若服务器 CPU 使用率已高，需谨慎开启或限制压缩类型。
3. 缓存问题：压缩后的内容 vary 头需正确配置，避免缓存服务器将压缩内容误发给不支持压缩的客户端。
4. 版本兼容：部分旧版本 HAProxy 可能需要编译时开启压缩支持，若配置不生效需确认版本特性。
常见问题
HAProxy 压缩会影响 HTTPS 性能吗
会有一定影响，因为 HTTPS 本身已加密，HAProxy 需在解密后压缩再加密，增加 CPU 开销，但能减少加密传输的数据量。
如何只对特定后端开启压缩
将 compression 指令写在特定的 backend 段中，而不是 defaults 段，这样仅该后端池的响应会被压缩。
压缩级别可以调整吗
HAProxy 原生配置中通常不直接暴露压缩级别参数，主要依赖算法默认设置，如需精细控制需结合外部模块或版本特性。
参考来源
1. 尹正杰 - 博客园：HAProxy 的高级配置选项 - 压缩功能
2. HAProxy 官方文档：Configuration Manual - Compression options
3. 社区技术整理：haproxy 配置详解及性能优化指南