在Nginx的HTTP2服务端推送机制里，http2_push_diary_expire是一个容易被忽略却直接影响推送效率的指令。它决定了服务端维护的推送日记（push diary）中记录项的存活时长，超过这个时间后相关记录会被清理，后续请求可能重新触发推送判断。理解它的过期处理逻辑，是避免带宽浪费和推送失效的关键。
一、http2_push_diary_expire的底层工作原理
Nginx在处理HTTP2连接时，为了不重复向同一个客户端推送相同资源，会在内存中维护一份推送日记。这份日记以客户端连接信息为维度，记录已经推送过的资源URI以及推送时间。http2_push_diary_expire指令就是用来设定这些记录从写入时刻算起，最多保留多少秒。默认值通常是10分钟（600秒），一旦某条记录的存在时间超过这个阈值，Nginx就会在后续的日记清理流程中将其移除。
需要明确的是，这个过期时间和浏览器侧的缓存完全没有关系。即便日记里的记录过期被删，浏览器之前收到的推送资源依然遵循自身的Cache-Control或Expires头。很多开发者在调试时发现资源更新后客户端还收到旧推送，就盲目调大http2_push_diary_expire，这其实是混淆了服务端推送决策与客户端缓存边界。正确的认知是：日记过期只影响服务端是否认为“这个客户端我已经推过”，而不影响客户端是否真的再用那份文件。
从内存管理角度看，推送日记是每连接独立的，高并发场景下如果http2_push_diary_expire设置过长，会导致大量连接占用内存来保存推送记录，尤其在长连接保活时间较久的架构里，可能成为隐性的内存压力点。因此过期值并非越大越好，需要结合业务推送资源数量和连接存活时长综合权衡。
二、过期时间设置不当引发的典型问题
当http2_push_diary_expire设置得过短，比如设为30秒，而客户端与服务端保持HTTP2连接并间歇性请求页面，就可能出现：第一次请求首页推送了style.css，30秒后日记过期，客户端再次请求另一页面时，Nginx又推送一遍style.css。这种重复推送不仅没有节省往返，反而因为重复传输占用了带宽，违背了服务端推送的初衷。在静态资源体积较大、页面访问频次高的站点，这类短过期配置会让推送从优化变成负担。
反过来，如果过期时间设得极大，例如一天，那么当某个被推送的资源从服务器删除或改名后，只要旧连接还在日记有效期内，Nginx仍会尝试推送那个已经不存在的URI。此时客户端会收到一个推送失败或404的推送流，而服务端日志里可能刷出大量无效推送记录。更严重的是，在资源频繁迭代的发布流程中，长过期会让新版本资源无法及时通过推送到达老连接，因为服务端以为“推过了”就不再推，除非用户彻底断开重连。
我们还常见一种误区：把http2_push_diary_expire和http2_push_preload的生效范围搞混。前者管日记回收，后者决定是否把Link头里的preload资源真正推送出去。过期处理异常时，应先在配置中打印出当前指令值，并用不同过期值做对比测试，而不是随意改动其他推送参数来“碰运气”。
三、结合配置与代码的正确过期处理实践
在Nginx配置中，http2_push_diary_expire通常写在http、server或location块内。针对更新频繁的前端资源，建议将过期值设定为略大于用户平均会话时长，例如用户平均停留5分钟，可设为400秒，既避免短时间内重复推送，又能在会话中段自然失效以兼容资源微调。下面是一个典型的配置片段示例：
server {
listen 443 ssl http2;
server_name example.ipipp.com;
# 设定推送日记过期为400秒
http2_push_diary_expire 400s;
location / {
# 对首页推送关键css和js
http2_push /static/main.css;
http2_push /static/core.js;
root /var/www/html;
index index.html;
}
# 资源版本化，避免旧推送干扰新文件
location /static/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
}
上面的配置里，我们把日记过期设为400秒，并对静态资源使用了带版本化思想的缓存头。实际项目中，更推荐把文件命名为main.v1.css这样的形式，当内容变更就改版本号，这样即便推送日记未过期，新页面引用的也是新URI，Nginx会视为不同资源再次推送，不会受旧记录影响。这种“过期处理+版本化”的组合，比单纯拉长http2_push_diary_expire要稳健得多。
验证过期处理是否生效，可以开启Nginx的debug级日志，观察push diary相关的回收信息，或者在客户端用浏览器开发者工具的HTTP2视图查看推送流是否随连接时间出现预期中的中断与重启。如果发现旧资源仍被推送，优先检查是不是日记过期过短导致连接初期重复推，还是过期过长导致已删资源仍推送，再反过来微调http2_push_diary_expire的秒数，而不是推翻整套推送方案。
四、运维层面的监控与动态调整建议
在真实生产环境，http2_push_diary_expire不应是一次设定终身不变。建议通过监控Nginx的connections和pushing状态，统计每个连接平均推送次数。如果平均推送次数异常高，往往是过期太短；如果带宽中推送占比低但404推送多，则是过期太长。可以用简单的脚本定期拉取状态，并给出告警。
此外，在滚动发布或灰度更新时，可以临时调低http2_push_diary_expire，让老连接更快忘记旧推送，从而更快适配新版本资源；发布稳定后再调回常规值。这种基于发布节奏的动态过期策略，能兼顾性能与正确性。总之，把该指令当作可调节的推送记忆时长，而不是缓存开关，才能处理好它的过期问题。
Nginxhttp2_push_diary_expireHTTP2_server_push修改时间：2026-08-19 04:58:30