反向代理缓存可用，但需确保Nginx编译含ngx_http_proxy_cache_module模块；宝塔8.x默认支持，自定义编译易缺失，应通过软件商店勾选“Proxy Cache”重装，并在全局http块配置proxy_cache_path，站点配置中调用proxy_cache。
反向代理缓存能用吗？先看 Nginx 版本和模块
宝塔面板底层用的是 Nginx，但默认安装的 nginx 很可能没编译 ngx_http_proxy_cache_module —— 这个模块是反向代理缓存的基础设施。直接配了也无效，连 proxy_cache_path 都会报 unknown directive "proxy_cache_path"。
检查方法：nginx -V 2>&1 | grep -o with-http_proxy_cache_module。没输出就说明缺失。
- 宝塔 8.x 默认 Nginx 1.22+ 多数已内置，但「极速编译」或「自定义编译」安装的容易漏掉
- 如果缺失，别折腾源码重编，直接在宝塔「软件商店 → Nginx → 设置 → 编译安装」里勾选「Proxy Cache」再重装更稳
- 注意：重装 Nginx 会清空你手动写的
nginx.conf全局配置，缓存路径等必须在重装后重新加到「配置修改」页顶部
缓存配置写在哪？不是在站点配置里随便贴
宝塔的「反向代理」功能本身不支持缓存指令，它只生成基础 proxy_pass。想用缓存，必须绕过图形界面，在 Nginx 全局配置里定义缓存区，再在具体站点的「配置修改」中调用。
常见错误是把 proxy_cache_path 直接塞进站点配置的 location 块里——Nginx 会报错，因为该指令只能出现在 http 块顶层。
- 正确位置：宝塔 → Nginx → 「配置修改」→ 找到
http {开头处，在其下第一行添加：proxy_cache_path /www/server/nginx/proxy_cache levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=30m use_temp_path=off;
- 然后在目标站点的「配置修改」→ 「反向代理」生成的配置段里，
location内补上：proxy_cache api_cache;proxy_cache_valid 200 302 10m;proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; - 特别注意：
keys_zone名称（这里是api_cache）必须前后一致，大小写敏感
哪些 API 能缓存？别让敏感数据进磁盘
缓存不是万能加速器。对带用户身份、实时性要求高、或返回头含 Cache-Control: no-store 的 API，硬上缓存反而导致数据错乱或泄露。
典型不能缓存的场景：/user/profile（含 token 或 session）、/order/status（需秒级更新）、所有 POST/PUT/DELETE 请求（Nginx 默认不缓存非 GET/HEAD）。
- 强制只缓存特定路径：用
location ~ ^/api/v1/public/替代泛匹配location / - 绕过缓存的请求，加
proxy_cache_bypass $http_cache_control $arg_nocache;，前端加?nocache=1就能临时穿透 - 响应头里有
Set-Cookie的，Nginx 默认不缓存；如确需缓存，得加proxy_ignore_headers Set-Cookie;，但要确认业务无状态 - 缓存键默认包含 Host + URI + 参数，如需忽略某参数（比如
utm_source），得用proxy_cache_key自定义
缓存生效了吗？别只看响应头里的 X-Proxy-Cache
宝塔默认不会自动加 X-Proxy-Cache 头，光靠浏览器 Network 面板看不出是否命中。得自己加日志或查磁盘文件。
更麻烦的是：缓存目录权限不对、磁盘满、或 inactive 时间设太短，都会让缓存“看似启用实则失效”。
- 验证缓存写入：
ls -l /www/server/nginx/proxy_cache/，有子目录且非空说明路径生效 - 加临时日志：在站点配置的
location块里加log_format cache '$remote_addr - $upstream_cache_status [$time_local] "$request" $status $body_bytes_sent';，再用access_log /www/wwwlogs/cache.log cache; - 关键指标看
HIT/MISS/BYPASS，而不是只盯200状态码 - 首次访问必
MISS，第二次才可能HIT；但若上游响应头带Vary: Authorization，即使同一 URL 也会因 header 不同而分存多份，容易误判为未命中
缓存路径的磁盘空间和 inode 数量，比响应速度更容易成为瓶颈。尤其是大量小响应体（如 JSON API），levels=1:2 能缓解，但得定期 find /www/server/nginx/proxy_cache -type f -mmin +60 -delete 配合清理脚本。
