无法配置AWS API Gateway使用Gzip编码集成端点

从你描述的情况来看，双重压缩是最可能的罪魁祸首——你的Spring Boot后端已经对响应做了Gzip压缩，而AWS API Gateway在转发响应时又自动执行了一次压缩，导致返回的内容被压缩了两次，这就会触发curl和Postman的解压错误（invalid block type、incorrect header check都是典型的损坏压缩包报错）。

下面是具体的排查和修复步骤：

1. 关闭API Gateway的自动压缩功能 #

AWS API Gateway默认会对符合条件的响应启用Gzip压缩（比如响应大小超过阈值、MIME类型在列表内）。如果后端已经返回了压缩后的内容，API Gateway不会自动识别，会再次压缩，导致双重压缩。

解决方法：

• 登录AWS控制台，进入你的API Gateway服务
• 找到目标API，切换到Settings标签页
• 在Content Encoding区域，关闭Enable compression选项
• 重新部署你的API（这一步很重要，配置变更需要部署后生效）

2. 验证Swagger配置的响应头映射 #

你在Swagger里配置了method.response.header.Content-Encoding映射到integration.response.header.Content-Encoding，这个配置是对的，但要确保API Gateway没有修改这个响应头。可以用curl查看响应头：

curl -I -X GET https://api.service.com/brand/list -H 'Accept-Encoding: gzip'

确认返回的响应头里包含Content-Encoding: gzip，且没有额外的编码相关头（比如Content-Encoding: gzip,gzip这种重复值）。

另外，你在requestParameters里硬编码了Content-Type: 'application/json'，要确保后端接受这个类型，并且返回的响应MIME类型和你在produces里定义的一致，避免出现不匹配的情况。

3. 确认Spring Boot的压缩配置正确性 #

确保你的Spring Boot只在收到Accept-Encoding: gzip请求时才返回压缩内容，且压缩流程正常。检查你的配置文件（比如application.yml）：

server:
  compression:
    enabled: true
    # 只对指定MIME类型压缩，和Swagger的produces对应
    mime-types: application/json,text/plain,application/x-www-form-urlencoded
    min-response-size: 1024  # 只压缩超过1KB的响应，避免小内容压缩反而增大体积

同时可以直接请求后端服务（绕过API Gateway），验证压缩是否正常：

curl -I -X GET http://original.service.com/brand/list -H 'Accept-Encoding: gzip'

确认返回Content-Encoding: gzip，且用--compressed参数能正常解压：

curl --compressed -X GET http://original.service.com/brand/list -H 'Accept-Encoding: gzip'

如果这一步正常，说明后端压缩没问题，问题确实出在API Gateway的重复压缩上。

4. 验证修复效果 #

完成上述配置后，重新部署API Gateway，再用curl测试：

curl --compressed -X GET https://api.service.com/brand/list -H 'Accept-Encoding: gzip'

如果能正常返回解压后的内容，Postman的请求也应该恢复正常了。

内容的提问来源于stack exchange，提问作者Tolga Evcimen