我们刚刚收到消息，Heroku 因 DDoS 攻击导致的 24 小时+中断终于结束了。我有一个关于与用户沟通的问题：当网站完全关闭时，我如何仍然与我的用户保持联系？我正在考虑这两个选项：
- 输入
www.mysite.com的用户会自动重定向到状态页面，与status.heroku.com非常相似，该页面独立运行，可以提供更新的信息和交谈方式。 - 失败#1，在其他地方设置一个简单的网页，称为
status.mysite.com，我必须事先告诉用户。
如果我基于 Heroku 的网站出现故障，是否可以自动重定向到其他网站？
我应该使用哪些服务来托管尽可能独立于 Heroku 基础设施的简单状态页面？
假设您在非 Heroku 的地方注册了您的域，您只需更改域的主 DNS 条目以指向不同的 IP 地址即可。
例如，您可以在免费的 Amazon EC2 微型实例上创建一个非常简单的站点，然后在紧要关头更改域的 DNS 以指向简单的 EC2 站点。
这种 DNS 条目需要一段时间才能传播（在 ~1 分钟到几个小时之间），因此这只是长时间中断的有用策略。
假设 www.mysite.com 直接指向 Heroku 的服务器，则不可能以稳健的方式实现选项 1。到目前为止，更改您的 DNS 条目对于互联网上的每个人来说还不够快。某些 ISP 可能会缓存长达 24 小时的 DNS 条目。
选项 2 易于实施。为了尽可能独立于Heroku的基础设施，我建议不要将亚马逊的云产品用作托管服务。仅仅因为Heroku本身使用了该平台。我建议看看Google App Engine。对于小型网站也是免费的，非常强大，并且完全独立于与Heroku和/或Amazon相关的任何内容。
您是否会将主服务器隐藏在防火墙后面，并使用 quid 服务器作为代理，并带有看门狗。鱿鱼服务器对 DOS 连接将更加健壮。它会切换到主服务器关闭时的回退模式。
域已注册为指向快速高效的 squid 服务器。squid 服务器转到主服务器（隐藏服务器）以获取页面。Squid 还可以缓存静态页面。如果鱿鱼服务器检测到DOS攻击（它或主服务器拥塞），那么它可以为静态站点提供服务。鱿鱼服务器还将使站点不易受到DOS攻击。
后端（主服务器）正在运行什么并不重要，只要它可以指示页面可以缓存多长时间即可。我希望大多数人都这样做。