在反向代理架构中，Nginx常以HTTP/2协议连接上游服务，以此复用长连接、降低握手开销。但当链路空闲时，防火墙或负载均衡器可能悄悄清理会话表，造成连接在应用层看来依然打开，实际已无法收发数据。HTTP/2规范中的PING帧提供了一种轻量心跳机制，Nginx从特定版本开始支持在回源方向上发送PING并保持空闲连接存活，理解其配置方式对保障回源稳定性十分关键。
HTTP/2 PING帧的工作机制与回源价值
HTTP/2在单个TCP连接上划分多个流，帧是基本传输单元。PING帧类型为0x6，载荷固定为八字节，不关联任何流编号，属于连接级控制帧。发送方发出PING后，接收方必须立即返回PING ACK，这一过程不携带业务数据，仅用于探测往返时延与连接可用性。在Nginx回源场景中，若上游支持HTTP/2，代理机可定时发出PING，避免连接因长时间无数据被中间设备回收。
与TCP keepalive相比，HTTP/2 PING工作在应用层，能穿透仅识别应用流量的代理。TCP层保活报文有时被云网络忽略，而PING帧封装在HTTP/2帧结构内，更接近真实请求路径。当Nginx检测到连续多个PING未收到ACK，便可判定连接失效并主动断开，触发新建连接或挑选其他上游，从而把断链发现时间从分钟级缩短到秒级。
实际生产中，回源链路的空闲期常出现在夜间低峰或后台任务间隔。若没有心跳，下一次请求可能正好命中已死连接，导致该请求失败或等待TCP重传超时。启用PING心跳后，连接被定期验证，新请求总能落在健康连接上。对于使用gRPC或SSE等长连接回源的业务，PING还能辅助区分网络中断与正常静默，减少误判。
Nginx启用回源HTTP/2与PING心跳的配置方法
要让Nginx向上游发送HTTP/2请求并携带心跳，首先需在upstream或proxy_pass处声明协议。较新版本的Nginx Plus及开源主线分支提供http2指令用于回源。基础配置是在指向 upstream 的 location 中设置 proxy_http_version 2; 并配合 proxy_pass https://backend;，同时开启相关超时与心跳参数。
具体心跳参数方面，http2_idle_timeout 控制连接空闲多久后Nginx开始发送PING，http2_recv_timeout 限制等待帧的时长。以下示例展示了典型配置：在空闲十秒后发PING，若三秒内未收到ACK则关闭连接。注意这些指令应置于 http、server 或 location 上下文，且上游必须真正支持HTTP/2，否则Nginx会降级或报错。
http {
upstream backend {
server 10.0.0.5:443;
keepalive 32;
}
server {
listen 443 ssl;
location /api/ {
proxy_pass https://backend;
proxy_http_version 2;
http2_idle_timeout 10s;
http2_recv_timeout 3s;
proxy_set_header Host $host;
}
}
}
若使用Nginx开源旧版没有原生回源HTTP/2心跳指令，可借助 proxy_read_timeout 配合应用层心跳，或在上游侧开启PING并由对端维持。但更推荐升级到支持 http2_idle_timeout 的版本，因为主动从代理端发PING能统一治理所有上游连接。配置后可用 nginx -t 校验，并通过抓包观察是否周期性出现类型为PING的HTTP/2帧。
调试时建议打开调试日志，搜索 http2 与 idle 关键字确认心跳触发。若发现PING过于频繁导致CPU上升，可适当拉长 http2_idle_timeout；若中间设备回收时间约为三十秒，则空闲超时设十五秒左右较安全。心跳本身开销极低，每个PING仅八字节，不会明显占用带宽。
被动超时与主动PING心跳的对比及排障思路
传统做法依赖 proxy_read_timeout 等被动超时：只有当下一次请求读写阻塞超过阈值才断开连接。这种方式实现简单，但缺陷明显，连接可能已半死却不自知，请求方承受全部延迟。主动PING把探测前置，在空闲期就完成清理，使连接池始终有效。下表列出两者差异：
| 维度 | 被动超时 | 主动PING心跳 |
|---|---|---|
| 断链发现时机 | 下次请求时 | 空闲期定时 |
| 对请求影响 | 可能超时失败 | 几乎无感 |
| 配置复杂度 | 低 | 中 |
| 适用协议 | 所有 | 仅HTTP/2 |
排障时若回源偶发 502 Bad Gateway 且错误日志出现 upstream prematurely closed connection，应先确认中间设备空闲回收时间，再比对 http2_idle_timeout 是否大于该值。若上游是自建Nginx，也需确保其未禁用PING ACK。有时TLS会话复用与PING叠加会造成报文乱序，可临时关闭OCSP stapling观察。
另一个常见误区是认为开启TCP keepalive就无需HTTP/2 PING。在跨可用区或经过NAT网关时，TCP保活间隔常被云端覆盖为接近两小时，远不能满足秒级业务要求。HTTP/2 PING在七层工作，只要连接未彻底断，帧就能送达。因此二者是互补关系，而非替代。对于强一致回源接口，建议同时保留TCP保活与PING心跳，形成双层防护。
最后，在容器化部署里，Sidecar与Nginx可能共享网络命名空间，PING报文同样受iptables规则约束。若观察到PING发出却无ACK，可用 tcpdump -i any -nn port 443 过滤 http2 类型帧，确认是网络丢弃还是上游未回包。结合监控对PING失败计数告警，能在用户感知前修复回源链路。
NginxHTTP/2_PING回源心跳修改时间：2026-08-15 19:56:34