Nginx 缓存与 HTTPS/HTTP2 实战(基于陶辉《深入理解 Nginx》第四章)
Nginx 缓存与 HTTPS/HTTP2 实战基于陶辉《深入理解 Nginx》第四章本文所有命令输出均来自两台真实云服务器Ubuntu 24.04.4 / nginx 1.24.0的现场回显未做任何编造。承接上一篇的反向代理拓扑本篇在同一台代理层上叠加两件事① 用proxy_cache给上游响应做反向代理缓存② 用listen 443 ssl http2提供 HTTPS 与 HTTP/2。一、架构回顾客户端 ──► 代理层 139.9.***.*** ├─ :80 反向代理 负载均衡上一章 ├─ :8088 反向代理「缓存」演示 ──┐ └─ :443 HTTPS HTTP/2 ├─► 上游 192.168.0.113:8081/8082/8083 缓存落在 /var/cache/nginx/blog ─┘缓存的核心价值让代理直接返回热点响应不再回源从而降低上游压力、缩短响应时间。二、反向代理缓存proxy_cache1) 配置缓存相关的指令分两处proxy_cache_path必须在http上下文这里放在conf.d被主配置include进 http 块proxy_cache系列在location内。# /etc/nginx/conf.d/proxy_cache.conf proxy_cache_path /var/cache/nginx/blog levels1:2 keys_zoneblog_cache:10m max_size1g inactive60m use_temp_pathoff; server { listen 8088; server_name _; add_header X-Cache-Status $upstream_cache_status always; # 透出命中状态 add_header X-Upstream $upstream_addr always; location / { proxy_pass http://backend_rr; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_cache blog_cache; proxy_cache_key $scheme$proxy_host$request_uri; proxy_cache_valid 200 302 10m; # 200/302 缓存 10 分钟 proxy_cache_valid 404 1m; proxy_cache_valid any 5m; proxy_cache_lock on; # 缓存击穿保护只放一个请求去回源 proxy_cache_bypass $http_cache_control; # 客户端可绕过 proxy_no_cache $http_pragma $http_authorization; } # 演示忽略上游 Cache-Control强制按本地规则缓存 location /force/ { proxy_pass http://backend_rr; proxy_ignore_headers Cache-Control Expires Set-Cookie; proxy_cache blog_cache; proxy_cache_key FORCE:$scheme$proxy_host$request_uri; proxy_cache_valid 200 30s; add_header X-Cache-Status $upstream_cache_status always; } }几个要点keys_zoneblog_cache:10m在共享内存划 10MB 存缓存索引与上一章upstream的zone同理必须共享。levels1:2多级目录避免单目录文件过多拖慢文件系统。$upstream_cache_statusMISS / HIT / BYPASS / EXPIRED / UPDATING / STALE是验证缓存效果的「显微镜」。2) 命中验证MISS → HIT对同一 URL 连续请求第一次回源MISS之后直接命中HIT$curl-s-ihttp://127.0.0.1:8088/|grep-iEX-Cache-Status|X-BackendX-Backend: backend-8083 X-Cache-Status: MISS $curl-s-ihttp://127.0.0.1:8088/|grep-iEX-Cache-Status|X-BackendX-Backend: backend-8083 X-Cache-Status: HIT $curl-s-ihttp://127.0.0.1:8088/|grep-iEX-Cache-Status|X-BackendX-Backend: backend-8083 X-Cache-Status: HIT注意第二次、第三次虽然是 HIT但X-Backend仍是backend-8083——这是缓存命中后直接读磁盘/内存、不再回源的证据若真回源轮询会把后端换成其它节点。3) 缓存键cache key随 URL 变化缓存键包含$request_uri所以不同查询串是独立缓存项$curl-s-ihttp://127.0.0.1:8088/?v2|grep-iEX-Cache-StatusX-Cache-Status: MISS $curl-s-ihttp://127.0.0.1:8088/?v2|grep-iEX-Cache-StatusX-Cache-Status: HIT4) 客户端绕过缓存通过proxy_cache_bypass $http_cache_control带Cache-Control: no-cache的请求会强制回源$curl-s-i-HCache-Control: no-cachehttp://127.0.0.1:8088/|grep-iEX-Cache-StatusX-Cache-Status: BYPASS5) 强制缓存忽略上游头上游若返回Cache-Control: no-store之类默认不会被缓存。用proxy_ignore_headers可让代理按自己的规则缓存$curl-s-ihttp://127.0.0.1:8088/force/test|grep-iEX-Cache-StatusX-Cache-Status: MISS $curl-s-ihttp://127.0.0.1:8088/force/test|grep-iEX-Cache-StatusX-Cache-Status: HIT6) 缓存真的落盘了$find/var/cache/nginx/blog-typef|head/var/cache/nginx/blog/3/65/4ec78dcd21eb44ed1326c79aceb9a653 /var/cache/nginx/blog/7/40/50550861c9c9b763e75dfd0cf6a14407 /var/cache/nginx/blog/a/f6/3d77faa614c79b2586bc1d0380b94f6a $find/var/cache/nginx/blog-typef|wc-l3/、/?v2、/force/test三个键各生成一个缓存文件levels1:2的多级目录结构也清晰可见。生产建议用proxy_cache_lock on防「缓存击穿」——高并发同时 miss 同一 key 时只放一个请求去回源。搭配add_header X-Cache-Status $upstream_cache_status做可观测性是排查「为什么没命中」最快的手段。注意默认只缓存 GET/HEADproxy_cache_methods可改带Set-Cookie的响应默认不缓存可用proxy_ignore_headers调整。三、HTTPS HTTP/21) 生成自签证书演示用$mkdir-p/etc/nginx/ssl $ openssl req-x509-nodes-days365-newkeyrsa:2048\-keyout/etc/nginx/ssl/blog.key-out/etc/nginx/ssl/blog.crt\-subj/CNnginx-blog-lab$ls-l/etc/nginx/ssl/ -rw-r--r--1root root1127... /etc/nginx/ssl/blog.crt -rw-------1root root1704... /etc/nginx/ssl/blog.key生产环境请用受信任 CA 签发的证书Let’s Encrypt 免费自签证书仅用于实验室验证 TLS 链路。2) 开启 443 SSL HTTP/2# /etc/nginx/conf.d/proxy_https.conf server { listen 443 ssl http2; server_name _; ssl_certificate /etc/nginx/ssl/blog.crt; ssl_certificate_key /etc/nginx/ssl/blog.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; add_header X-Upstream $upstream_addr always; location / { proxy_pass http://backend_rr; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 告知后端原始是 https } }关键点listen 443 ssl http2;一条指令同时启用 TLS 与 HTTP/2nginx 1.25 还支持http2独立指令1.24 用 listen 参数写法即可。ssl_protocols TLSv1.2 TLSv1.3禁用不安全的 TLS 1.0/1.1。X-Forwarded-Proto $scheme后端据此知道原始请求是 HTTPS正确生成https://链接。3) 验证监听已起且响应头直接就是HTTP/2$ ss-ltn|grep:443LISTEN05110.0.0.0:4430.0.0.0:* $curl-k-s-Ihttps://127.0.0.1/|head-8HTTP/2200server: nginx/1.24.0(Ubuntu)date: Fri,24Jul202604:45:47 GMT content-type: text/plain x-backend: backend-8081 x-upstream:192.168.0.113:8081 $curl-k-s-o/dev/null-whttp_version%{http_version}\n--http2https://127.0.0.1/http_version2用openssl s_client显式协商h2确认 ALPN 真正生效$echo|openssl s_client-connect127.0.0.1:443-alpnh22/dev/null|grep-iEsubject|ALPN|issuersubjectCNnginx-blog-labissuerCNnginx-blog-lab ALPN protocol: h2ALPN protocol: h2说明客户端与 Nginx 在 TLS 握手阶段就协商出了 HTTP/2 协议。从公网访问同样正常$curl-k-s-o/dev/null-wcode%{http_code} version%{http_version}\nhttps://139.9.***.***/code200version1.1注示例里本地curlSchannel 后端公网探测回显为version1.1是因为该客户端实现未在握手时优先协商 h2而服务器侧的curl --http2与openssl -alpn h2均明确返回http/2/ALPN protocol: h2足以证明 HTTP/2 已生效。生产中以openssl s_client -alpn h2的 ALPN 结果为准。四、小结反向代理缓存proxy_cache_path共享内存索引 磁盘目录proxy_cacheproxy_cache_valid三件套即可生效用X-Cache-Status观测 MISS/HIT/BYPASSproxy_cache_lock防击穿proxy_ignore_headers可覆盖上游缓存策略。HTTPS/HTTP2自签证书或 CA 证书配listen 443 ssl http2ssl_protocols关掉旧协议X-Forwarded-Proto把「原始是 https」透给后端。验证用curl --http2看http_version2用openssl s_client -alpn h2看ALPN protocol: h2。两篇串联代理层 反向代理隐藏上游 负载均衡横向扩展 缓存减压提速 TLS/HTTP2安全与性能。四者叠加就是一套标准的「接入层 / 网关」雏形。附本实验部署的全部配置文件清单均已在真实服务器生效文件所在机器作用/etc/nginx/conf.d/backends.conf上游 192.168.0.1133 个后端 8081/8082/8083/etc/nginx/conf.d/proxy_upstreams.conf代理 192.168.0.1494 个 upstreamrr/weighted/ip_hash/least_conn均带zone/etc/nginx/conf.d/proxy_lb.conf代理:80 / :8091 / :8092 / :8093 负载均衡演示/etc/nginx/conf.d/proxy_cache.conf代理:8088 反向代理缓存/etc/nginx/conf.d/proxy_https.conf代理:443 ssl http2

相关新闻

Unity游戏开发入门:从零实现小球吃金币的完整项目实战

Unity游戏开发入门:从零实现小球吃金币的完整项目实战

1. 项目概述:从零到一,体验游戏开发的乐趣如果你对游戏开发感兴趣,想亲手做出一个能跑能跳、有反馈有目标的小游戏,那么“小球吃金币”这个项目绝对是你的不二之选。它就像游戏开发界的“Hello World”,麻雀虽小&#…

2026/7/26 23:08:15阅读更多 →
营销自动化系统技术解析:从用户画像到618实战优化

营销自动化系统技术解析:从用户画像到618实战优化

最近不少开发者都在讨论一个现象:某些平台在618大促期间通过"专家指导"和"重金投入"实现了惊人的销售业绩。作为技术人员,我们更关心的是这背后到底用了什么技术手段?这些"专家系统"是如何工作的?今…

2026/7/26 23:08:15阅读更多 →
人工智能训练师三级全真模拟试卷(一)|65题+答案解析 2026版

人工智能训练师三级全真模拟试卷(一)|65题+答案解析 2026版

摘要:人工智能训练师三级全真模拟试卷(一):65题(单选30+多选10+判断15+简答10),附完整答案解析。严格按照考试大纲设计,题型分布、难度比例、考点覆盖均参考历年真题规律,附AutoGrader自动评分工具和薄弱点分析报告。 一、导读 本试卷严格按照三级人工智能训练师考试…

2026/7/26 23:06:14阅读更多 →
Node.js 后端项目复盘:TypeScript 迁移的全流程经验与类型覆盖率提升方案

Node.js 后端项目复盘:TypeScript 迁移的全流程经验与类型覆盖率提升方案

Node.js 后端项目复盘:TypeScript 迁移的全流程经验与类型覆盖率提升方案 一、引言 把一个生产环境稳定运行两年的 8 万行 Node.js 后端项目从 JavaScript 迁移到 TypeScript,不是"装个 tsconfig 就能跑"的事。去年我主导了这样一个迁移项目&a…

2026/7/27 0:34:32阅读更多 →
思维树提示:让AI探索多条推理路径

思维树提示:让AI探索多条推理路径

思维树提示:让AI探索多条推理路径前面两篇文章我们讲了思维链提示——让AI"一步步"推理。但现实中的很多问题,不是只有一条推理路径。你往往需要考虑多个可能性、比较不同的方案、在关键节点做出选择。思维树提示(Tree of Thoughts…

2026/7/27 0:34:32阅读更多 →
内部工具的产品化之路:从解决自己问题到服务整个团队

内部工具的产品化之路:从解决自己问题到服务整个团队

内部工具的产品化之路:从解决自己问题到服务整个团队 一、深度引言与场景痛点:那个只有 3 个人用的脚本,怎么就变成团队标配了 最成功的内部工具,往往不是"产品经理调研需求 → 出 PRD → 开发排期"这个流程出来的。而是…

2026/7/27 0:32:32阅读更多 →
日志采集与分析平台的搭建:ELK 技术栈的部署与调优

日志采集与分析平台的搭建:ELK 技术栈的部署与调优

日志采集与分析平台的搭建:ELK 技术栈的部署与调优 一、深度引言与场景痛点:微服务上线后,日志散落在 12 台机器上 微服务架构带来的一个典型困境是日志分散。一个用户请求可能经过 API 网关 → 用户服务 → 订单服务 → 支付服务 → 消息服务…

2026/7/27 0:32:32阅读更多 →
AI 辅助技术方案评审:用模型帮你检查设计文档的逻辑漏洞

AI 辅助技术方案评审:用模型帮你检查设计文档的逻辑漏洞

AI 辅助技术方案评审:用模型帮你检查设计文档的逻辑漏洞 一、深度引言与场景痛点:技术方案评审中,最难发现的不是错误,而是"遗漏" 技术方案评审是后端开发中的重要环节。一个 50 页的设计文档,评审者需要在有…

2026/7/27 0:32:32阅读更多 →
开发环境容器化:DevContainer 与远程开发的实践总结

开发环境容器化:DevContainer 与远程开发的实践总结

开发环境容器化:DevContainer 与远程开发的实践总结 一、深度引言与场景痛点:"在我电脑上能跑"是协作开发的元问题 新同事入职第一天,花了整整一个下午配置开发环境——安装 JDK 17、MySQL 8.0、Redis、Maven,配置环境变…

2026/7/27 0:32:31阅读更多 →
覆盖国产 + 海外 + 开源模型,OpenClaw 2.7.9 Windows/Mac 双端部署详解

覆盖国产 + 海外 + 开源模型,OpenClaw 2.7.9 Windows/Mac 双端部署详解

🔹 工具基础介绍 OpenClaw 是开源生态中一款实用性较强的本地智能工具,凭借本地离线运行、可视化图形操作和任务自动化三大核心特性,赢得了众多用户的青睐。与普通在线对话AI工具不同,它属于能够直接操控本机软硬件的智能数字员工…

2026/7/26 0:01:28阅读更多 →
伺服阀焊完微漏毁整机?精密激光焊接三关锁住高压

伺服阀焊完微漏毁整机?精密激光焊接三关锁住高压

所谓液压伺服阀体的精密激光焊接,是用激光束对阀座壳体(通常为不锈钢或铝合金)进行密封焊接,使阀体在21-35MPa的高压液压油或压缩气体中长期运行而不发生介质泄漏。液压伺服阀是高端液压系统的"大脑"。从航空航天飞行控…

2026/7/26 0:01:28阅读更多 →
D2DX:三步实现《暗黑破坏神2》高清宽屏体验的终极指南

D2DX:三步实现《暗黑破坏神2》高清宽屏体验的终极指南

D2DX:三步实现《暗黑破坏神2》高清宽屏体验的终极指南 【免费下载链接】d2dx D2DX is a complete solution to make Diablo II run well on modern PCs, with high fps and better resolutions. 项目地址: https://gitcode.com/gh_mirrors/d2/d2dx 你是否还在…

2026/7/26 0:01:28阅读更多 →
SPI实战指南:从时钟模式到寄存器配置,解决嵌入式通信难题

SPI实战指南:从时钟模式到寄存器配置,解决嵌入式通信难题

1. 项目概述:从寄存器手册到实战指南 如果你手头有一份类似德州仪器(TI)TMS320x240xA系列DSP的SPI模块技术手册,看着里面密密麻麻的寄存器位定义、时序图和公式,是不是感觉头大?这份资料虽然权威&#xff0…

2026/7/27 0:00:24阅读更多 →
【JAVA毕设源码分享】基于springboot的水果购物管理系统的设计与实现(程序+文档+代码讲解+一条龙定制)

【JAVA毕设源码分享】基于springboot的水果购物管理系统的设计与实现(程序+文档+代码讲解+一条龙定制)

博主介绍:✌️码农一枚 ,专注于大学生项目实战开发、讲解和毕业🚢文撰写修改等。全栈领域优质创作者,博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围:&am…

2026/7/27 0:00:24阅读更多 →
2007-2023年各市区县生态文明建设示范区DID

2007-2023年各市区县生态文明建设示范区DID

数据简介 自改革开放以来,我国依赖高投入、高资源消耗和高污染等传统发展模式实现了经济短期内的快速增长, 然而这也导致了严重的生态环境危机。因此,国家有力于推动企业高质量经济发展,协同生态保护的方针,从而从201…

2026/7/27 0:00:24阅读更多 →
YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

如果你在部署 YOLOv8 时,发现推理速度只有可怜的 1-2 FPS,而别人的演示视频却能跑到 30 FPS 以上,那么问题很可能不在模型本身,而在于你的整个处理链路。很多开发者拿到一个训练好的 YOLOv8 模型后,会直接使用官方示例…

2026/7/25 23:03:25阅读更多 →
Coze与Dify对比指南:低代码AI应用开发从入门到实战

Coze与Dify对比指南:低代码AI应用开发从入门到实战

1. 从零到一:为什么你需要了解 Coze 和 Dify?如果你对 AI 应用开发感兴趣,但一看到“大模型”、“智能体”、“工作流”这些词就头疼,觉得门槛太高,那这篇文章就是为你准备的。很多开发者,包括我自己&#…

2026/7/26 19:05:21阅读更多 →
AI生图工具怎么选?2026年6月版实测对比

AI生图工具怎么选?2026年6月版实测对比

做自媒体的朋友应该都有体会:配图一直是个让人头疼的问题。2026年,AI生图工具已经非常成熟了,但工具太多反而不知道怎么选。以下是截至2026年6月我对主流AI生图工具的实测对比。Midjourney V8.1:速度之王2026年6月11日&#xff0c…

2026/7/26 19:05:21阅读更多 →