大请求自动 gzip：CLAUDE_CODE_GZIP_REQUEST_BODIES
长对话、大文件、很多工具定义叠在一起时，Claude Code 往 Anthropic API 发的请求体很容易涨到几兆字节。上行带宽一般比下行紧，尤其在代理、跨境链路或共享办公网上，大请求往往是「卡住几秒才开始流式输出」的原因之一。
CLI 2.1.300 改了一处默认行为：发往 api.anthropic.com 的大体积请求会用 gzip 压缩，而且就算你关掉了遥测，压缩仍然生效。
以前和现在
以前，gzip 请求体和遥测开关联在一起：关掉遥测时，大请求可能仍按明文体积上传。很多人出于隐私或合规会关遥测，结果顺带失去了上行压缩。
现在的规则更干净：
| 项 | 说明 |
|---|---|
| 默认 | 大请求自动 gzip |
| 目标 | api.anthropic.com |
| 与遥测的关系 | 无关——关遥测也照样压 |
| 关闭方式 | CLAUDE_CODE_GZIP_REQUEST_BODIES=0 |
你几乎不用改任何配置就能受益；只有明确要关时才需要动手。
怎么关闭
环境变量设为 0 即可：
bash
export CLAUDE_CODE_GZIP_REQUEST_BODIES=0也可以写进 settings 的 env 段（用户级或项目级均可，看你团队的习惯）：
json
{
"env": {
"CLAUDE_CODE_GZIP_REQUEST_BODIES": "0"
}
}改完后新开一轮会话（或确认子进程能读到新环境变量）再生效。
什么时候可能需要关
大多数人应保持默认开启。下面几种情况可以考虑关掉，方便排查：
- 中间代理或 WAF 对
Content-Encoding: gzip处理异常，表现为偶发 4xx、连接重置，而关掉压缩后立刻正常； - 抓包 / 调试工具需要直接看明文 JSON 请求体，gzip 会让你多解一层；
- 自定义网关对压缩请求支持不完整（少见，但企业内自建代理有时会踩）。
如果关掉之后上行明显变慢、大上下文首包延迟变长，再开回去即可——说明瓶颈本来就在体积，而不是压缩本身。
和「省 token」不是一回事
gzip 压的是网络上的字节，不会减少模型计费的 token。上下文照样按 token 算；它只让同样一份请求在路上更小、更快。想省费用，仍要靠压缩对话、少塞无关文件、合理用工具搜索等手段。
小结
- 2.1.300：大请求默认 gzip，且不再绑在遥测开关上；
- 想关：
CLAUDE_CODE_GZIP_REQUEST_BODIES=0； - 默认开着就行；只有代理/调试异常时再关。
升级到 2.1.300 或更新版本后，长会话在弱网上的「发出去那一下」通常会轻快一些。若你这边仍偶发超时，再对照代理日志看是否需要临时关闭压缩做对比测试。