gRPC客户端通过代理时，最常见的误判是“TCP端口能连，所以代理没问题”。gRPC通常运行在HTTP/2上，TLS场景还涉及CONNECT隧道和ALPN协商；调用建立后又会长时间复用连接。任何一层的空闲超时、协议降级或连接重置，都可能表现为UNAVAILABLE、DEADLINE_EXCEEDED或流突然结束。
一、先确认是哪一种gRPC连接
应记录目标是明文HTTP/2还是TLS上的gRPC、客户端语言与库版本、代理类型，以及调用是一元请求、服务端流、客户端流还是双向流。不同形态对连接时长、流量方向和超时的要求不同，不能只用一次短请求代表全部业务。
二、TLS gRPC经过HTTP代理的常见路径
- 客户端解析代理地址并建立TCP连接；
- 向代理发送CONNECT，请求连接目标主机和端口；
- 代理认证并连接目标；
- 客户端在隧道内与目标完成TLS握手；
- 通过ALPN协商HTTP/2；
- gRPC在HTTP/2流中发送消息和状态。
CONNECT基础原理可参考HTTPS代理隧道说明。
三、普通HTTPS可用，gRPC为什么仍失败
| 现象 | 可能位置 | 检查方向 |
|---|---|---|
| CONNECT被拒绝 | 代理策略 | 目标端口、白名单与407 |
| TLS握手失败 | 证书或SNI | CA、域名、时间、TLS检查 |
| 无法协商h2 | 客户端到目标 | ALPN、服务端与代理模式 |
| 短请求成功、流式中断 | 长连接路径 | 空闲超时、心跳与NAT |
| 高并发尾延迟上升 | 连接与流量控制 | 并发流、窗口、丢包和连接池 |
四、Deadline和代理超时不是一回事
gRPC Deadline是调用允许持续的总时间，代理还可能有连接超时、上游连接超时、读取超时和空闲超时。若Deadline比正常业务耗时还短，调用会由客户端主动取消；若代理空闲超时更短，流可能在没有数据传输时被中断。日志应记录时间线，而不是只记录最终状态。
五、Keepalive为什么要谨慎设置
Keepalive可帮助发现失效连接，也可能维持需要长期存在的流。但探测过于频繁会增加客户端、代理和服务端负载，还可能违反服务端策略。合理做法是先确认各层空闲超时，再让探测间隔、超时和允许无活动调用时发送的规则相互匹配。
六、HTTP/2多路复用的边界
多个gRPC调用可共享一条HTTP/2连接，减少握手成本，但共享TCP也意味着丢包和连接故障会影响多个流。单连接还受并发流与流量控制限制。相关机制见HTTP/2代理多路复用与连接池。
七、代理认证应在哪一层完成
407来自正向代理，gRPC服务自己的认证通常在CONNECT隧道建立后的应用调用中完成。代理凭据与业务令牌要分别存储和脱敏。NTLM等连接相关认证还可能与连接复用产生兼容问题，应在选定的语言客户端和运行平台上实测。
八、客户端是否自动读取环境变量
不能对所有gRPC语言实现一概而论。不同语言、库版本和Channel配置对HTTP_PROXY、HTTPS_PROXY、NO_PROXY或显式代理参数的支持不同。应查当前客户端文档，并通过代理日志或授权出口检测验证实际路径。
九、建议的最小测试矩阵
- 直连与代理各测试一次一元调用；
- 分别测试短流和超过常见空闲时间的长流；
- 测试正确凭据、无凭据和过期凭据；
- 记录DNS、TCP、CONNECT、TLS和首个响应时间；
- 逐步提高并发，观察连接数与高分位延迟；
- 模拟代理连接重置，检查重连和幂等边界。
十、重试不能忽略业务语义
连接中断时，客户端未必知道服务端是否已经处理请求。对产生订单、扣款或写入的调用，必须通过幂等键、请求ID或状态查询设计安全恢复，不能看到UNAVAILABLE就无限重试。可参考代理重试与幂等设计。
十一、结论
gRPC代理排查应按CONNECT、TLS、HTTP/2、调用Deadline和长连接策略逐层进行。先用最小调用确认协议，再测试真实流式时长与并发，才能判断问题来自代理兼容、客户端配置还是服务端处理。
