Nginx从1.13.9版本开始正式支持HTTP/2 Server Push功能,允许服务器在客户端明确请求之前主动推送静态资源到浏览器。为了配合这一机制,Nginx引入了推送日记的概念,而http2_push_diary_ttl_hours正是控制这份日记存活时长的指令。理解这个参数的作用,需要先弄清楚推送日记在整个Server Push流程中扮演的角色,否则很容易配置出看似生效、实则重复推送的问题。

一、什么是HTTP2推送日记
当Nginx向客户端推送某个资源时,会在内存中记录一条推送日记,内容是已推送资源的哈希值。当同一个客户端后续发起连接时,浏览器会在请求头中携带之前接收过的推送资源的摘要信息,Nginx据此判断哪些资源不需要再次推送。这套机制有效避免了重复推送造成的带宽浪费。
推送日记并非永久保存。每条日记记录都有生存周期,超过这个周期后记录会被清除,此时即使客户端之前已经收到过该资源,Nginx也可能再次推送。http2_push_diary_ttl_hours指令就是用来设置这个生存周期的,单位是小时,取值范围是1到2147483647,默认值为1小时。
需要注意的是,推送日记保存在Nginx的内存中,且与客户端会话绑定。如果Nginx重启,日记会全部丢失,这也是为什么在高并发场景下需要权衡内存占用与推送效率的原因。
二、http2_push_diary_ttl_hours的配置方法
该指令可以在http、server、location三个层级中配置,属于配置上下文灵活的指令。下面是一个典型的完整配置示例:
server {
listen 443 ssl http2;
server_name www.ipipp.com;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# 控制推送日记的存活时间为24小时
http2_push_diary_ttl_hours 24;
location / {
root /var/www/html;
index index.html;
# 预读资源列表文件,实现批量推送
http2_push_preload on;
}
location /static/ {
# 针对静态资源设置更长的日记周期
http2_push_diary_ttl_hours 48;
http2_push /static/style.css;
http2_push /static/app.js;
}
}
配置完成后,使用nginx -t检查语法,再通过nginx -s reload平滑重载即可生效。验证推送是否生效可以使用浏览器的开发者工具,在Network面板中查看资源是否带有push标记,或者使用curl命令配合--http2参数观察响应头。
关于取值的权衡:设置得过短(如默认1小时),长时间停留在站点上的用户可能遭遇重复推送;设置得过长则会增加内存压力,且客户端缓存可能早已失效,推送过期的资源引用反而无意义。对于更新频率较低的静态站点,24到48小时是常见的合理区间。
三、Server Push的实际价值与注意事项
必须客观说明的是,Chrome浏览器从106版本开始默认禁用了HTTP2推送功能,因为实际统计显示推送的资源经常与浏览器自身的预加载请求冲突,导致重复下载。这并不意味着这项技术毫无价值,在自研客户端、内网系统或可控的App内嵌WebView场景中,Server Push依然能带来可观的加载收益。
与之相比,更通用的替代方案是在HTML头部使用预加载提示。它的优势在于由浏览器决定是否下载,不会产生重复请求:
<!DOCTYPE html>
<html>
<head>
<link rel="preload" href="/static/style.css" as="style">
<link rel="preload" href="/static/app.js" as="script">
</head>
<body>
<h1>页面内容</h1>
</body>
</html>
如果同时使用两种方式,Nginx的http2_push_preload指令会自动解析Link响应头中的preload标记并转为推送。此时推送日记的作用更加凸显,只有日记机制正常工作,才能避免推送与preload指令的双重下载问题。
四、排查推送不生效的常见原因
实际运维中遇到推送失效,可以从以下几个方向排查。首先是协议确认,客户端到Nginx之间必须是HTTP2连接,任何中间代理转换为HTTP1.1都会让推送失效,可通过响应头中的协议信息确认。其次是确认指令拼写,http2_push_diary_ttl_hours中diary一词容易误写为daily,这是高频错误。
再次要检查日记是否因过期或服务重启而丢失。如果发现频繁重复推送,可以适当调大ttl值;如果发现推送完全不触发,则要检查客户端是否在禁用推送的浏览器版本上测试。最后,建议结合access log记录推送行为,通过日志量化推送命中率,用数据驱动参数调优,而不是凭感觉设置数值。
总体而言,http2_push_diary_ttl_hours是一个小而精的调优指令,它本身不复杂,但要发挥价值必须建立在正确理解推送日记机制和目标用户访问行为的基础上。在可控客户端环境中合理配置它,配合精准的资源推送清单,依然能够获得比传统请求模式更优的首屏体验。
Nginxhttp2_pushHTTP/2 Server Push修改时间:2026-09-01 03:00:46