应按路径精准关闭Gzip而非全局禁用：对/login、/api/等敏感路径设gzip off，静态资源则用gzip_types限定压缩类型；同时将CSRF Token改用HttpOnly Cookie传递，并启用limit_req限速。
开启 Gzip 压缩能明显提升传输效率，但若配置不当，会引入 CRIME 和 BREACH 这两类侧信道攻击风险。它们不破解加密本身，而是利用压缩与响应长度之间的关联，逐步还原敏感内容（如 CSRF Token、Cookie、Session ID）。关键不是“要不要压缩”，而是“在哪压、怎么压、压什么”。
先分清攻击对象：CRIME 针 TLS 层，BREACH 针 HTTP 层
CRIME 利用的是 TLS 协议内置的压缩功能（如 DEFLATE），现代浏览器和主流 Nginx 版本（1.15.0+）已默认禁用，实际风险较低。BREACH 才是当前更需关注的问题——它利用的是 Nginx 或后端启用的 HTTP 层 Gzip 压缩，只要页面同时满足三个条件就可能被利用：
• 使用 HTTPS
• 启用了 Gzip 压缩（gzip on）
• 响应中既包含用户可控输入（如搜索词、URL 参数），又包含静态敏感数据（如隐藏域里的 Token）
核心防御：按路径精准关闭 Gzip，而非全局禁用
直接 gzip off 全局关闭虽简单，但会牺牲大量静态资源（JS/CSS/字体）的加载性能。更合理的方式是分级控制：
- 对登录页、密码重置页、含表单 Token 的 HTML 页面，统一禁用 Gzip：
location = /login { gzip off; } - 对 API 接口路径（如
/api/、/auth/），强制关闭压缩：location /api/ { gzip off; proxy_pass http://backend; } - 静态资源仍可压缩，但限定类型：
gzip_types application/javascript text/css image/svg+xml;（明确排除text/html和application/json）
补强措施：打破攻击前提，不止于关压缩
仅关 Gzip 不足以彻底消除风险，还需从响应结构和业务逻辑上削弱攻击基础：
- 把 CSRF Token 等敏感值改用
HttpOnly+SecureCookie 传递，避免出现在 HTML body 或 JSON 响应体中 - 敏感接口启用请求限速，例如限制单 IP 每分钟最多访问 10 次：
limit_req zone=api_breach burst=5 nodelay; - 避免在同一个响应里回显用户输入并嵌入密钥——比如搜索结果页既显示“您搜索了【xxx】”，又在 hidden input 里放 Token，这就是典型高危模式
验证是否生效：两步快速确认
改完配置别急着上线，用两个命令验证效果：
- 检查敏感路径是否真的没压缩：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/login→ 响应头不应出现Content-Encoding: gzip - 确认静态资源仍被压缩：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js→ 应看到Content-Encoding: gzip和Vary: Accept-Encoding
