要让proxy_cache和fastcgi_cache协同构成高性能缓存网关，关键是按角色分工：proxy_cache用于反向代理非PHP后端（如Java、Node.js）及静态资源，fastcgi_cache专用于PHP-FPM动态内容；二者必须路径隔离、缓存区独立（不同keys_zone）、键值可控，共存于同一Nginx时需严格通过location路由区分，并分别配置temp_path、cache_key、cache_valid等闭环参数。
要让 proxy_cache 和 fastcgi_cache 协同构成高性能缓存网关，关键不是堆叠配置，而是按角色分工、路径隔离、缓存区独立、键值可控——两者不能混用同一缓存区，也不能共用同一 keys_zone 名，否则会冲突或命中混乱。
明确职责边界：什么走 proxy_cache，什么走 fastcgi_cache
这是设计起点，决定后续所有配置逻辑：
- proxy_cache 用于反向代理场景：后端是 Node.js、Java（Spring Boot）、Python（Django/Flask）、Go 等非 PHP 应用，或静态资源服务器（如 CDN 源站、对象存储代理），缓存的是 HTTP 响应体本身；
- fastcgi_cache 专用于 PHP-FPM 场景：Nginx 通过 FastCGI 协议与 php-fpm 通信，缓存的是 PHP 动态生成的 HTML/JSON 内容，不适用于其他语言；
- 二者可共存于同一台 Nginx，但必须严格区分 location 路由：例如
/api/走 proxy_pass + proxy_cache，.php或/wp-admin/走 fastcgi_pass + fastcgi_cache。
独立定义缓存区：路径、名称、容量三者一一对应
在 http{} 块中分别声明，严禁复用同一 keys_zone 名：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_cache 区示例：
proxy_cache_path /data/nginx/proxy_cache levels=1:2 keys_zone=PROXY_CACHE:100m inactive=1h max_size=50g; - fastcgi_cache 区示例：
fastcgi_cache_path /data/nginx/fastcgi_cache levels=1:2 keys_zone=PHP_CACHE:200m inactive=30m max_size=30g; - 务必配套设置临时目录，避免缓存写入失败：
proxy_temp_path /data/nginx/proxy_temp;fastcgi_temp_path /data/nginx/fastcgi_temp;
location 中精准启用：缓存名、key、有效期、容错策略缺一不可
每个缓存类型需在对应 location 块中完整闭环配置：
- 对代理类请求（如
location /api/）：
proxy_cache PROXY_CACHE;<br> proxy_cache_key "$scheme$host$request_uri";<br> proxy_cache_valid 200 301 302 5m;<br> proxy_cache_valid 404 1m;<br> proxy_cache_use_stale error timeout updating http_502 http_503;<br> proxy_pass http://backend_api;
- 对 PHP 请求（如
location ~ \.php$）：
fastcgi_cache PHP_CACHE;<br> fastcgi_cache_key "$scheme$request_method$host$request_uri";<br> fastcgi_cache_valid 200 301 302 10m;<br> fastcgi_cache_use_stale error timeout invalid_header http_500;<br> fastcgi_ignore_headers Cache-Control Expires Set-Cookie;<br> fastcgi_pass php-fpm-sock;
- 注意：
proxy_cache_key与fastcgi_cache_key的变量组合应反映真实业务区分维度（如是否含 Cookie、User-Agent），但过度细分会大幅降低命中率；建议初期只保留稳定字段，后期按需扩展。
规避常见冲突点：多站点、Header 干扰、缓存污染
实际部署中最易出错的几个细节：
-
多站点不能共用 keys_zone：若同时托管 example.com 和 blog.net，需为各自定义独立
keys_zone（如EXM_CACHE和BLOG_CACHE），否则缓存键会跨站污染； -
务必透传必要 Header：启用缓存时，
proxy_set_header Host $host;和fastcgi_param HTTP_HOST $host;不可省略，否则后端无法正确路由或生成绝对链接； -
主动跳过缓存的请求要显式声明：比如带
Cache-Control: no-cache的调试请求，应加：
proxy_cache_bypass $http_cache_control;<br> fastcgi_cache_bypass $http_cache_control;
-
清除缓存需工具配合：Nginx 原生不支持按 URL 删除，建议编译安装
ngx_cache_purge模块，或用rm -rf清目录（需确保缓存路径唯一且无共享）。
