想象一下，我们有一个由nginx作为前端，apache（以php或其他）作为后端的网站。 这个想法是，nginx将服务静态，而代理请求* .php文件后端。 易于实施，无需大脑configuration，不是吗？
现在想象我们有坏行为的后端。 它使用了一些不稳定的模块，它用来产生页面几秒钟，我们不确定页面是否被渲染。 奇怪，但仍然有可能，对不对？ 遗留代码等。 顺便说一句，后端可能在不同的机器上（是的，传统：旧的操作系统，旧的软件，“甚至不要碰它！”等）
现在我们想在后端不回答的情况下“保护”自己。 如果我们没有页面或得到5xx错误，我们最后一次成功的时候为页面提供服务将会很好。 换句话说，如果后端返回了200个代码和页面内容，那么我们就为它服务。 如果我们得到了超时，或者我们从后端得到了5xx代码，我们为相同的URI提供页面，但是caching了一个。 这会给我们一些时间来修复后端，而用户至less会看到一些东西。
Nginx是一个不错的软件。 我发现proxy_cache_use_stale指令，还有一些其他的，但恐怕如果后端失败，将会提供什么版本。
我也可以想象一些http平衡器（以nginx为例），它将检查后端状态并停止使用它。 然后第二个后端可能是服务器充满了模仿原始网站的静态页面（甚至可能没有一些元素，如“login”链接）。 如果是这样，我应该如何明智地更新“模仿”服务器一段时间？
什么方法可能会更好？ 你会select什么？
CloudFlare在世界各地拥有100多个数据中心，他们的地位非常好，并且非常好看，你无法打败他们免费的价格。 CloudFlare确实会在主站点处于脱机状态时显示警告，但是他们的付费业务计划可能会抑制这种警告 – 您必须问问他们。 如果你不想要警告你唯一的select是Nginx或类似的caching。
他们的关键部分nginxconfiguration将是这些，在您的位置块。 这篇优秀的文章里有很多关于他们的内容 。 基本上它只说caching200（成功）的响应，并且只对1秒（如果可以的话增加），在更新时使用陈旧的页面，而不要对已经请求的页面的请求进行排队。
proxy_cache_lock on; proxy_cache_valid 200 1s; proxy_cache_use_stale updating; 如果你有匿名用户页面caching，将减less你的服务器上的负载，即使你只caching页面1秒，但时间越长越好。 减less的负载可能会使应用程序更可靠。
当然，你应该修复这个performance不好的应用程序。