同样是走代理访问服务，普通网页请求大多顺畅，轮到 gRPC 接口却频频握手失败、超时重连。这不是代理”坏了”，而是 gRPC 基于 HTTP/2 长连接的工作方式，对代理提出了不一样的兼容要求。
gRPC 和普通请求最大的不同，是”一条连接用到底”
普通 HTTP 请求大多是短连接：一个请求一条连接，用完整条关闭。gRPC 恰恰相反，它复用同一条 HTTP/2 长连接，多个请求和流式响应都在这条连接上并行传输。连接活得越久，效率越高；但只要代理在中间”拆台”，整条链路就一起遭殃。
| 对比项 | 普通 HTTP 请求 | gRPC 调用 |
|---|---|---|
| 连接方式 | 多为短连接 | 单条长连接复用 |
| 协议版本 | HTTP/1.x 为主 | HTTP/2 必须 |
| 数据格式 | 文本为主 | Protobuf 二进制 |
| 连接中断影响 | 重发即可恢复 | 流式数据可能丢失 |
坑一：代理不认 HTTP/2，gRPC 直接”降级失败”
gRPC 只在 HTTP/2 上运行，没有 HTTP/1.1 的退路。如果代理只支持 HTTP/1.x，握手阶段客户端要求升级到 HTTP/2 时，代理要么僵住、要么返回无法理解的响应。表现为建立连接成功，但请求一直挂起直到超时。
坑二：长连接被中间层掐断
代理、防火墙或网络设备常常有”空闲连接回收”策略，一段时间没数据就把连接关掉。gRPC 的流式调用一旦连接被静默切断，业务方可能隔了很久才察觉——数据”丢在路上了”却没有任何报错。排查时优先看代理的超时配置，而不是反复重启客户端。
- 先确认代理是否支持 HTTP/2：不支持就换支持的服务商或自建代理
- 调整连接空闲超时：把代理与网络设备的空闲回收时间调大
- 客户端启用自动重连：gRPC 断线重连机制是标配，别关掉
- 观察服务端日志：连接被中途关闭通常会在服务端留下痕迹
长连接最怕的不是”慢”，而是”悄悄断”——代理链路里的每一处超时设置都值得过一遍。
与 IP 代理的关系：代理IP服务的接入能力决定业务兼容边界——评估服务商时，HTTP/2 与长连接支持应纳入考察项。所有使用都应遵循平台规则与法律法规，用于正当业务目的。