Claude API接入第三方模型时自动压缩失效问题解析与解决方案

1次阅读

共计 1480 个字符，预计需要花费 4 分钟才能阅读完成。

最近在对接 Claude API 和第三方模型时，发现一个棘手的问题：明明配置了自动压缩，但实际传输的数据却意外膨胀。最典型的表现是响应体大小突然增加 2 - 3 倍，同时 Content-Length 头与实际字节数不匹配。这个问题在传输大型模型输出时尤为明显，不仅浪费带宽，还可能触发下游系统的解析错误。

HTTP 压缩机制的核心环节
客户端通过 Accept-Encoding 头声明支持的压缩算法（如 gzip, deflate）
服务端选择算法后，在 Content-Encoding 响应头中声明
中间代理不应修改这两个头字段（RFC 7230 规定）
Claude 的特殊处理逻辑
默认对 >1KB 的文本响应启用 gzip 压缩
但遇到第三方模型的二进制响应时，会错误跳过压缩
特别是当响应头包含 Content-Type: application/octet-stream 时

import requests

# 强制声明只接受原始数据
headers = {
    'Accept-Encoding': 'identity',  # 关键参数
    'Authorization': f'Bearer {API_KEY}'
}

# 带异常处理的请求示例
try:
    response = requests.post(
        'https://api.claude.ai/v1/model',
        headers=headers,
        json=payload,
        timeout=30
    )
    response.raise_for_status()

    # 验证内容是否未压缩
    assert 'content-encoding' not in response.headers, \
        f'意外压缩: {response.headers}'

except requests.exceptions.RequestException as e:
    logging.error(f'API 调用失败: {str(e)}')
    raise

flowchart LR
    Client -->| 原始请求 | Proxy
    Proxy -->| 添加控制头 | ClaudeAPI
    ClaudeAPI -->| 未压缩响应 | Proxy
    Proxy -->| 按需压缩 | Client

关键实现代码：

// 代理中间件核心逻辑
app.use(async (ctx, next) => {
  // 剥离客户端压缩头
  delete ctx.headers['accept-encoding'];

  await next();

  // 根据响应类型决定压缩
  if (ctx.response.type === 'application/json') {ctx.set('Content-Encoding', 'gzip');
    ctx.body = createGzip().end(ctx.body);
  }
});