Google Cloud ESP向gRPC服务器通告无效压缩格式及Cloud Endpoints架构咨询

Hey，针对你遇到的这个问题，结合你描述的Web应用架构，我来梳理下可能的原因和排查方向：

先对齐你的架构链路 #

首先再明确下你提到的完整请求路径，这对排查很重要：

browser <----> ESP <----------> gRPC client <JSON> proxy <-ProtoBuf-> server

其中核心的部署细节：

• ESP作为前端入口承接浏览器请求
• gRPC客户端和后端服务器跑在同一GCE虚拟机的独立Docker容器里，通过Docker网桥互通
• 中间代理负责JSON和ProtoBuf的格式转换

可能的问题根源与排查步骤 #

ESP和gRPC服务器之间的压缩格式不匹配，通常是压缩算法协商失败导致的——ESP通告了gRPC服务器不支持的压缩格式，下面是几个关键排查点：

1. 检查ESP的压缩配置 #

ESP默认支持gzip和deflate，但如果你的配置里启用了其他算法，就可能出问题：

• 查看ESP的启动参数，有没有类似--compression_algorithm的配置，确认指定的算法是gRPC服务器支持的
• 如果用了Endpoints配置文件（比如openapi.yaml或grpc-api-config.yaml），检查x-google-endpoints或相关字段里的压缩规则是否合理

2. 确认gRPC服务器的压缩支持 #

很多gRPC框架不会默认开启所有压缩算法，需要显式配置：

• 比如Go的gRPC服务器，得通过grpc.Compressor注册支持的压缩器，默认可能只支持gzip；如果ESP发了其他格式的请求，服务器就会报错
• 建议在gRPC服务器端开启请求头日志，打印收到的grpc-encoding和grpc-accept-encoding头，确认实际收到的压缩格式标识是否合法

3. 排查Docker网桥的网络干扰 #

虽然客户端和服务器在同一虚拟机，但Docker网桥的网络配置可能意外修改请求头：

• 有没有自定义的Docker网络规则？比如某些防火墙或代理规则篡改了压缩相关的请求头
• 可以在gRPC服务器容器里抓包（用tcpdump）对比ESP发送的请求头和服务器实际收到的内容

4. 检查中间代理的格式转换影响 #

那个负责JSON/ProtoBuf转换的代理，可能在转发时修改了压缩头：

• 比如代理没有正确传递ESP的grpc-accept-encoding头，或者自行添加了服务器不支持的压缩格式
• 可以在代理的入口和出口分别打印请求头，看是否有异常修改

快速验证方案 #

先临时禁用ESP的压缩功能，看问题是否消失：

• 在ESP启动命令里加--disable_compression参数，或者在配置文件中关闭压缩
• 如果禁用后通信正常，那基本可以确定是压缩格式协商的问题，再逐步定位具体是哪个环节的配置不匹配

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