缓存分三类：浏览器缓存、Nginx服务端缓存（fastcgi_cache/proxy_cache）和反向代理缓存，作用位置、生效条件、配置入口各不相同；静态资源用浏览器缓存，PHP动态页需fastcgi_cache并配合fastcgi_cache_valid与fastcgi_ignore_headers，反向代理缓存须剔除用户标识参数并关闭敏感路径缓存。
缓存分三类，别全堆一起开
宝塔里说的“缓存”其实混着三种完全不同的东西：浏览器缓存（Expires、Cache-Control）、Nginx 服务端缓存（fastcgi_cache 或 proxy_cache）、以及反向代理缓存（走 proxy_pass 的那种）。它们作用位置、生效条件、配置入口都不一样，强行统一设时间或开关，大概率白配，甚至引发页面不更新、登录态错乱等问题。
- 静态资源（
.js、.css、.png）适合用「浏览器缓存」——在网站设置 → 「伪静态」下方直接勾选「启用静态文件缓存」，选 7 天或 30 天即可 - PHP 动态页（比如 WordPress 首页、文章页）想缓存，得用
fastcgi_cache，必须手动加配置块，且要配合fastcgi_cache_valid指定状态码（只缓存200、301，千万别缓存404或带 Cookie 的响应） - 如果你是用宝塔做 CDN 中转（源站在外网），那就该用「反向代理 +
proxy_cache」，此时proxy_cache_key必须排除用户标识类参数（如$arg_token、$cookie_user_id），否则会把 A 用户的页面缓存后返回给 B 用户
fastcgi_cache 配置不生效？先查这三处
很多人粘贴完官方那段 fastcgi_cache_path 和 location ~ \.php 块，重启 Nginx 后发现 X-Cache 响应头一直是 BYPASS 或空，根本没进缓存。核心原因就三个：
-
fastcgi_cache_path目录权限不对：/var/cache/nginx必须由www-data（或你面板实际运行 Nginx 的用户）可读写，chown -R www-data:www-data /var/cache/nginx不能漏 - 站点配置里没真正加载缓存区：光有
fastcgi_cache_path不够，还得在location ~ \.php块内明确写fastcgi_cache my_cache，且名字（my_cache）要和keys_zone后面的一致 - PHP 脚本自己发了禁止缓存头：WordPress、Typecho 等程序常在 PHP 里输出
Cache-Control: no-cache，Nginx 默认会尊重它；得在location块里加fastcgi_ignore_headers Cache-Control Expires Set-Cookie;才能强制接管
反向代理缓存怎么避免缓存登录页？
用宝塔建反向代理站点时，如果源站有登录态（比如后台 /wp-admin/、/admin），默认缓存规则会把带 Session 的 HTML 也存下来，结果别人访问就看到你的登录页——这不是功能缺陷，是你没过滤。
- 在反向代理配置的「自定义配置」框里，不要只写一个大
location /，而是拆开：location ^~ /wp-admin/ { proxy_cache off; }、location ^~ /wp-login.php { proxy_cache off; } - 缓存 key 要剔除影响身份的变量：
proxy_cache_key "$scheme$request_method$host$request_uri";这行里别含$cookie_或$arg_，否则不同用户请求可能被当成同一个 key - 加个兜底判断：
proxy_cache_bypass $http_cookie $arg_nocache;，这样带Cookie或 URL 含?nocache=1的请求自动跳过缓存
缓存路径和内存区大小不是越大越好
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:20m max_size=512m inactive=8h; 这行里三个数值有强关联，调错反而拖慢服务：
-
keys_zone=20m是内存中存缓存索引的空间，不是存文件内容的；20MB 约支持 10 万左右缓存条目，超了就会频繁淘汰，导致命中率暴跌 -
max_size=512m是磁盘上限，但若inactive=8h设太短（比如 30m），旧缓存还没等自然过期就被踢出，磁盘空间永远用不满，还增加 IO 压力 - 真实建议：中小站点从
keys_zone=my_cache:10m+max_size=256m+inactive=2h起步，观察nginx -s reload后日志里cache miss比例，再逐步调
缓存最麻烦的从来不是配不配得上，而是配完之后不知道它到底缓了什么、为什么没缓、缓错没缓对——务必打开 add_header X-Cache "$upstream_cache_status";，用 curl 或浏览器开发者工具看响应头，这才是唯一可信的依据。
