gRPC反向代理混淆原生gRPC与gRPC-Web请求问题排查

• Content-Type判断逻辑存在缺陷：原生gRPC的Content-Type头遵循application/grpc[+<序列化格式>][;参数]的标准格式，实际请求中常携带编码、字符集等后缀参数（例如application/grpc+proto; encoding=gzip），当前代码使用字符串全等匹配，只要头信息携带额外参数就无法命中原生gRPC处理分支，请求会默认流入gRPC-Web处理逻辑。
• 反向代理未正确支持HTTP/2协议：原生gRPC强制依赖HTTP/2协议传输，要求TLS握手阶段协商h2协议；如果反向代理未开启HTTP/2支持，会将gRPC请求降级为HTTP/1.1处理，这类请求会被自动识别为gRPC-Web请求，走HTTP风格的路径路由逻辑，最终出现grpc.example.com:443/Hello.HelloService/Greeter这类拼接了域名的错误请求路径。
• 缺失gRPC请求的强制特征校验：原生gRPC请求固定为POST方法，且必须携带TE: trailers请求头，当前逻辑仅校验Content-Type，既容易出现误判，也无法拦截不符合gRPC规范的异常请求。

• 替换Content-Type匹配规则：放弃全等匹配，改用前缀匹配覆盖所有原生gRPC的Content-Type变体，代码示例：

import "strings"

grpcHeader := c.Request.Header.Get("Content-Type")
grpcserver := grpc.Server{}
// 匹配所有以application/grpc开头的合法gRPC Content-Type
if strings.HasPrefix(grpcHeader, "application/grpc") {
    grpcserver.ServeHTTP(c.Writer, c.Request)
}

• 为反向代理显式开启HTTP/2支持：TLS配置中添加h2协议协商项，确保gRPC请求不会被降级，配置示例：

tlsConfig := &tls.Config{
    NextProtos: []string{"h2", "http/1.1"}, // 优先协商HTTP/2协议
    InsecureSkipVerify: true,
    // 保留原有其他TLS配置
}

• 补充gRPC请求特征校验，避免分支误判：在原生gRPC判断分支中增加请求方法、TE头的校验，代码示例：

if c.Request.Method == http.MethodPost &&
	c.Request.Header.Get("TE") == "trailers" &&
	strings.HasPrefix(grpcHeader, "application/grpc") {
	grpcserver.ServeHTTP(c.Writer, c.Request)
}

• 检查代理层路径重写规则：原生gRPC请求路径固定为/<服务全限定名>/<方法名>格式，代理转发时直接透传原始路径即可，不要拼接Host、域名等额外内容到路径中。

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