nginx正向代理仅支持http流量缓存，https因connect隧道无法缓存；需配置proxy_cache_path、proxy_cache等指令启用http缓存，关键点包括缓存键含$http_host、按状态码设过期时间、启用proxy_cache_lock防穿透；推荐用squid等专用工具或镜像代理替代。
Nginx 做正向代理时，缓存功能确实能加速内网用户重复访问外网公共资源（如静态 JS、CSS、图片、开源镜像包等），但需注意：标准正向代理场景下，Nginx 的 proxy_cache 机制并不直接适配通用浏览器代理行为。原因在于：浏览器通过 HTTP 代理发起请求时，目标 URL 是完整地址（如 http://example.com/style.css），而 Nginx 默认的 proxy_pass 转发逻辑不自动提取和规范化缓存键；同时，HTTPS 流量走 CONNECT 隧道，根本无法被缓存。
仅对 HTTP 网站有效：启用基础缓存的必要配置
如果你只代理纯 HTTP 流量（例如内网测试环境、特定 HTTP 接口服务），且客户端可配合（如用 curl -x 或定制工具），可按如下方式开启缓存：
- 定义缓存区：在
http块中添加
- 在 server 块中启用缓存（监听非 CONNECT 端口，如 8080）：
listen 8080;
resolver 114.114.114.114 valid=300s;
location / {
proxy_pass http://$http_host$request_uri;
proxy_set_header Host $http_host;
proxy_cache public_cache;
proxy_cache_valid 200 301 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_lock on;
}
}
- 关键点说明：
– $http_host 必须参与缓存键生成（默认已包含），否则不同域名会混用缓存；
– proxy_cache_valid 按响应状态码分级设置过期时间，避免缓存错误响应；
– proxy_cache_lock 防止缓存未命中时多个相同请求穿透到上游；
– 所有缓存对象都基于原始响应头中的 Cache-Control 和 Expires 进行校验，若后端返回 no-cache 或 private，Nginx 默认不缓存（可加 proxy_ignore_headers Cache-Control Expires Set-Cookie; 强制缓存，但需谨慎）。
HTTPS 流量无法缓存，这是根本限制
当浏览器通过 Nginx 正向代理访问 HTTPS 网站（如 https://npmjs.org）时，实际建立的是 CONNECT 隧道，所有数据是加密字节流，Nginx 不解密、不解析、不感知内容。因此：
- 任何
proxy_cache指令对该连接完全无效； - 你看到的“缓存命中”日志或
X-Cache: HIT头，只可能出现在 HTTP 请求路径上； - 所谓“HTTPS 缓存加速”，在正向代理层面不存在技术实现——它属于 TLS 层之下，而 Nginx 在 CONNECT 模式下工作在 TCP 层。
更实用的替代方案：分层缓存 + 专用工具
若目标是真正提升内网访问外网公共资源的速度，建议绕过 Nginx 正向代理的局限：
- HTTP/HTTPS 分离处理：用 Squid 或 TinyProxy 作为主正向代理（原生支持 HTTPS CONNECT + 客户端认证 + DNS 缓存 + 对象级缓存），再让 Nginx 反向代理 Squid 的本地 HTTP 缓存端口（如 3128），对外提供统一入口；
- 镜像代理 + 本地 CDN：对高频资源（如 npm、pypi、Maven 中央库），部署 Nexus Repository 或 Artifactory，做定时同步+缓存，内网用户直连该镜像源，不走通用代理；
- DNS+Hosts 层缓存：在内网 DNS 服务器（如 dnsmasq）中缓存常用域名 IP，并预热 TTL，减少 DNS 查询延迟——这对加速首次访问效果明显。
不复杂但容易忽略：缓存收益高度依赖资源特性。静态文件、不变 API 响应适合缓存；带登录态、个性化、实时性要求高的页面（如银行网银、动态仪表盘）不仅不该缓存，还必须禁用或严格校验。
