Answers:
通常，是的，取决于TTL。
使用CDN时，通常会为内容配置TTL（生存时间）。在决定绝对必须使用最新内容刷新缓存之前，这是缓存可以使用多长时间的最大值。例如，假设您将所有* .jpg URL配置为具有5分钟的TTL。
然后，如果您的服务器出现故障，您还有5分钟的时间将其重新启动，然后用户会注意到。好吧，至少对于.jpgs。好吧，至少对于碰巧已经预先缓存的.jpgs。
另外，某些CDN使用Akamai NetStorage之类的功能，您可以在其中将内容直接上传到CDN － CDN被提供了一些内容，并被告知可以先验地直接提供。由于从来没有开始过“按需”“拉”式缓存，因此当服务器关闭时，这当然应该可以工作。
正如其他张贴者所指出的那样，这不是CDN的设计目的，并且它们不提供任何保证这种行为有效的保证。它只是碰巧可以正常工作（当您看到它发生时，它真棒！）。当然，如果需要特定的技术详细信息，则必须联系您的提供商。
是的：即使您的站点关闭，CDN服务器仍将运行，这是处理重大中断的一个不错的选择。您对所发生的事情有相当多的控制权，因此您可以根据资源和优先级来定制体验。这些选项通常属于以下类别：
已配置用于缓存的对象（通常是通过设置Cache-Control标头）应一直可用，直到它们过期。某些CDN为CDN边缘服务器提供了从其他CDN服务器检索内容的能力，这可以在停机期间提供帮助，并且在原始服务器相对于CDN服务器具有较高延迟时，通常可以提高性能。
某些CDN提供了在后端服务器不可用时提供已过期内容的功能（例如，使用Fastly，您可以启用Varnish的宽限期或圣人模式）。显然，这对从未缓存过的内容没有帮助，但是在许多情况下，当您使服务器恢复在线状态时，它至少可以使您的核心主页，联系信息等保持在线。
大多数CDN都提供尝试多个后端服务器的功能，因此您可以拥有一个单独的故障转移站点，以提供对您的站点有意义的体验：故障转移到另一台服务器或功能降低的站点，静态HTML页面等。这对于灾难性的情况很有用。托管失败，因为您可以选择托管在完全不同的公司，或者在Akamai NetStorage之类的情况下，直接与CDN提供程序托管，这样它们将支持整个堆栈。
除第三个选项外，您无法控制CDN服务器上将缓存的内容，因此该过程中最重要的部分是确定在各种功能不可用时如何降低网站的性能：例如，如果您拥有即使JavaScript完全失败，合理的HTML内容（即使是更多的高级功能在后台悄然失效），即使是大多数信息驱动的网站，也可能只能使用基本页面内容来运行。
Serve stale if unable to validate选择，这样当原点断开时，即使达到TTL，它也可以提供内容。
Cache-Control: stale-if-error现在也支持。
大多数CDN都从源（在本例中为服务器）起的一段时间（TTL）内缓存（动态）内容。在Amazon的Cloudfront管理控制台中，说明了S3存储桶的缓存控制。
Amazon S3的默认行为是将对象缓存24小时。
您可以通过在源服务器上提供/写入Cache-Control标头或Expires标头来影响默认行为。
当您使用Cache-Control max-age标头时，最小值为0。这时，Amazon将满足您的原始服务器的要求，每次都会检查对象是否已更改。
当您对对象使用Expires标头时，Amazon直到那个日期才会联系您的原始服务器。
我希望这可以澄清亚马逊的行为。