在heroku上，是否绝对没有办法将heroku上的https裸域重定向到带有www的非裸域？

Question

从Heroku文档中查看此链接：

https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords#subdomain-redirection

黄色方框说：

  

通过SSL直接向裸域提出请求（即   https://mydomain.com）在使用子域时会遇到警告   重定向。这是预期的，只能通过循环来避免   并公布您的安全网址的子域格式。

这真的是唯一的解决方案吗？只是希望人们在没有www的情况下不输入网址？

我遇到了一些问题，人们只是从网址中删除子域以进入主页（在https上）并遇到ssl警告？

有没有其他人想出办法解决这个问题？

Answer 1

我们目前发现的最好的想法是设置两个带有少量nginx配置的Amazon EC2微机器实例。然后，配置两个弹性IP地址以指向那些EC2实例，并将2个A记录指向这些IP地址。这样，如果硬件出现问题，您可以始终将弹性IP指向另一台EC2计算机，而无需等待DNS传播。转到https://example.com和http://example.com的用户将获得301到域并且没有SSL警告。

server {
  listen 80;
  listen 443 default_server ssl;
  server_name example.com;
  ssl_certificate server.crt;
  ssl_certificate_key server.key;
  return 301 https://www.example.com$request_uri;
}

另一个想法是使用wwwizer提供的优质服务。

Answer 2

最好的选择是使用DNSimple ALIAS record type之类的东西，它为CNAME记录提供根域支持。

然后您可以像这样设置您的记录（假设使用SSL Endpoint进行SSL）。

| type  | name | target                  |
| ALIAS |      | tokyo-123.herokussl.com |
| CNAME | www  | tokyo-123.herokussl.com |

虽然还有其他DNS提供商提供类似的ALIAS记录功能（例如DNSMadeEasy的ANAME），但它不是DNS规范中的内容。这就是我们尚未提供有关使用此类记录的详尽文档的原因。但是，我们的目标是在不久的将来纠正这一问题，因为对那些想要根域支持的人缺乏明确的指导。

同时关注using AWS Route 53 as your Heroku app's DNS。我相信很快或很快就可以在R53上实现这一目标。

Answer 3

301重定向是正确的方法，因为RFC1033声明您无法将您的区域顶点（根域）指向CNAME记录 - 它需要是A记录。

话虽如此，那里有DNS服务提供了这样做的可能性。我还没有自己试一试，但是CloudFlare提供免费套餐，去年开始为区域顶点提供CNAME。