需要一些集体的头脑风暴 :)。有一个很重的 PHP 应用程序（例如 Magento），每次访问者点击一个不存在的页面（或者应用程序的某个部分有问题并返回错误）时，应用程序服务器上的负载就会滚雪球般增长：
如果页面不存在，则不会缓存它们，并且应用程序将花费大量资源来检查所有内容并生成缓存副本，这将浪费时间；
如果应用程序的某个部分出现问题，应用程序将花费宝贵的时间来生成这些错误响应，而牺牲了网站健康部分的访问者的利益。
这里的想法是将来自 FastCGI 后端的所有负面响应（如 404 和 5xx）缓存在 nginx 前端，比如说 5 分钟 - 这将显著降低对应用程序服务器的性能影响。
使用 fastcgi_cache_* 指令可以非常轻松地实现缓存。但是，一旦您在 fastcgi_pass 所在的 location 块中定义了 fastcgi_cache_* 指令，它就会尝试缓存通过该 location 块的所有内容。
因此，问题是如何将 fastcgi_cache 限制为仅来自后端脚本的 404 响应？
只是为了进一步说明该场景。假设一个请求转到 /app/missing，应用程序的唯一入口点在 /index.php 中，因此 nginx 将向调用 /index.php/app/missing 的后端 FastCGI 服务器传递请求。现在，由于 /app/missing 不存在，index.php 将返回 HTTP 404。此路由将占用与您请求 /app/missing 一样多的 CPU。理想的情况是，一旦从 index.php 返回 HTTP 404，/app/missing 就会与来自 nginx 上的 index.php 的 404 页面一起缓存，因此如果有人立即请求 /app/missing不对 PHP 后端执行了调用，但返回了缓存页面。
答案1
这可以解决问题：
fastcgi_cache_valid 200 301 302 0;
fastcgi_cache_valid 404 500 503 5m;
如果 nginx 不允许 0 作为此处的值，则需要让 PHP 应用程序X-Accel-Expires: 0在有效页面上将 HTTP 标头添加到其输出中，然后在 nginx 配置中添加此行：
fastcgi_cache_valid 404 500 503 5m;