在网站崩溃时将用户重定向到其他地方
我们刚刚收到消息，Heroku 因 DDoS 攻击而导致的 24 小时以上停机终于结束了。我有一个关于与用户沟通的问题：当网站完全关闭时，我如何仍然与用户保持联系？我正在考虑这两个选项：
- 输入
www.mysite.com的用户会自动重定向到状态页面，很像独立运行的status.heroku.com并可以提供最新的信息和交谈的方式。 - 失败#1，在其他地方设置一个名为
status.mysite.com的简单网页，我必须事先告知用户。
如果我的基于 Heroku 的网站出现故障，是否可以自动重定向到其他网站？
我应该使用哪些服务来托管一个尽可能独立于 Heroku 基础设施的简单状态页面？
We have just received news that Heroku's 24-hour+ outage due to DDoS attack is finally over. I have a question regarding communication with users: when a site is completely down, how can I still maintain contact with my users? I'm thinking about these two options:
- Users entering
www.mysite.comare automatically redirected to a status page, much likestatus.heroku.com, which is running independently and can provide updated information and a way to talk. - Failing #1, setting up a simple webpage elsewhere called
status.mysite.comthat I have to tell users about beforehand.
Is it possible to do an automatic redirect to a different website if my Heroku-based one goes down?
What services should I use to host a simple status page that are as independent from Heroku's infrastructure as possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
假设您已在 Heroku 以外的地方注册了域，您可以简单地将域的主 DNS 条目更改为指向不同的 IP 地址。
例如，您可以在免费的 Amazon EC2 微型实例上创建一个非常简单的站点，并在紧要关头更改域的 DNS 以指向简单的 EC2 站点。
此类 DNS 条目的传播需要一段时间（约 1 分钟到几个小时），因此这对于长时间中断来说只是一个有用的策略。
Presuming you have registered your domain somewhere that is not Heroku, you could simply change the main DNS entry for your domain to point to a different IP address.
You could, for example, create a very simple site on a free Amazon EC2 micro instance, and in a pinch, change the DNS for your domain to point to the simple EC2 site.
It takes a little while for that sort of DNS entry to propagate (between ~1 minute and a couple of hours), so that's only a useful strategy for a long outage.
假设 www.mysite.com 直接指向 Heroku 的服务器，则不可能以稳健的方式实现选项 1。到目前为止，对于互联网上的每个人来说，更改 DNS 条目的速度还不够快。某些 ISP 可能会将 DNS 条目缓存长达 24 小时。
方案 2 很容易实现。为了尽可能独立于 Heroku 的基础设施，我建议不要使用 Amazon 的云产品作为托管服务。仅仅是因为 Heroku 本身就使用该平台。我建议您查看 Google App Engine。对于小型网站也是免费的，非常强大，并且完全独立于与 Heroku 和/或 Amazon 相关的任何内容。
Assuming www.mysite.com points directly to Heroku's servers, it is not possible to implement option 1 in a robust way. Changing your DNS entries is by far not quick enough for everyone on the internet. Some ISPs might cache DNS entries for as long as 24 hours.
Option 2 is easy to implement. To be as independent from Heroku's infrastructure as possible I would advice not to use Amazon's cloud offerings as a hosting service. Simply because Heroku uses that platform itself. I would suggest to have a look at Google App Engine. Also free for small sites, very robust, and completely independent of anything related to Heroku and/or Amazon.
您是否会将主服务器隐藏在防火墙后面，并使用带有看门狗的 quid 服务器作为代理。鱿鱼服务器对于 DOS 连接将更加健壮。当主服务器出现故障时，它将切换到回退模式。
该域名注册为指向快速高效的鱿鱼服务器。鱿鱼服务器前往主（隐藏服务器）获取页面。 Squid 还可以缓存静态页面。如果鱿鱼服务器检测到 DOS 攻击（它或主服务器拥塞），那么它可以为静态站点提供停机页面服务。 Squid 服务器还将使站点不易受到 DOS 攻击。
后端（主服务器）运行什么应该无关紧要，只要它可以指示页面可以缓存多长时间即可。我希望大多数人都会这样做。
Would you hide the main server behind a firewall, and use a quid server as a proxy, with a watchdog. The squid server will be more robust to DOS attach. It would switch to a fall back mode it main server went down.
The domain is registered to point at the fast efficient squid server. The squid server goes to the main (hidden server) to fetch a page. Squid can also cache static pages. It the squid server detects a DOS attack ( it or main server is congested) then it can serve a static site is down page. The squid server will also make the site less susceptible to DOS attack.
Should not matter what the back-end (main server) is running, as long as it can indicate how long a page can be cached. I expect most do.