使用 CloudFront 在原始服务器之间拆分流量——这个配置正确吗？
Using CloudFront to split traffic between origin servers – is this configuration right?
我正在分阶段用新网站替换旧网站。从用户的角度来看，所有现有的 URL 必须保持不变，但某些路径应该服务于新页面。
我有两个原始服务器：旧服务器 (www.mysite.com) 和新的 EC2 (www.ec2-loadbalancer.com) – 出于隐私原因，显然是模拟 URL。
我创建了一个 CNAME 设置为 www.mysite.com 的 AWS CloudFront 分配。在此发行版中，我创建了两个来源域：
www.mysite.comwww.ec2-loadbalancer.com
在 CloudFront 中，我配置了一些行为，以便将 /foo 之类的路径发送到我的 EC2 负载均衡器源，并将所有其他路径（例如默认路径）发送到 www.mysite.com。
从 DNS 的角度来看，我添加了 www.mysite.com 的 CNAME 记录，它指向我的 Cloudfront 主机域（例如 foo.cloudfront.net.）。此域的 A 记录指向旧服务器的 IP。
我今天启动了所有这些并且它似乎有效，但我在网站上看到间歇性的 403 错误，并且在进行更改两个小时后（没有 "www" CNAME 之前，所以 TTL 应该不会有什么不同），一些浏览器仍在从原始 IP（而不是 CloudFront 的）为站点提供服务。
我配置正确了吗？我不知道如何通过 A 记录来做到这一点——它指向遗留服务器的 IP，而 CloudFront 不允许我输入 IP 地址作为来源。我是否应该将 www CNAME 指向 IP 地址，而将 A 记录指向 CloudFront？我在这里有点迷路。
另一方面，这可能都是传播问题，但我很担心在进行更改后数小时内看到 40 倍的错误。
我认为您应该创建一个 A 记录（用于指定的域名），其中的别名指向云端分布。应该可以解决问题。
即使用别名而不是 IP 地址并将您的域指向云端：
很遗憾您不能与我们共享域以帮助调试，但至少，dig 是您的朋友。例如：
$ dig membership.theguardian.com
...
;; ANSWER SECTION:
membership.theguardian.com. 367 IN CNAME i.global-ssl.fastly.net.
i.global-ssl.fastly.net. 12 IN A 151.101.128.67
i.global-ssl.fastly.net. 12 IN A 151.101.64.67
i.global-ssl.fastly.net. 12 IN A 151.101.0.67
i.global-ssl.fastly.net. 12 IN A 151.101.192.67
...告诉您 membership.theguardian.com 通过 CNAME 指向 Fastly。您可以检查备用 DNS 服务器，例如 8.8.8.8 上的 Google's DNS，方法是：
$ dig @8.8.8.8 membership.theguardian.com
...这样您就可以看到其他人是如何解析您的域的。
From a DNS perspective, I've added a CNAME record of www.mysite.com
which points to my Cloudfront host domain (eg. foo.cloudfront.net.).
The A record for this domain points to the IP of the legacy server.
我不是 DNS 专家，所以我在这里可能没有理解您的意思，但这听起来像是引入了歧义？对我来说，这听起来像是您对同一个 www.mysite.com 域有两个不同的记录，其中一个指向 CloudFront，另一个指向旧服务器的 IP。取决于如何解决，浏览器可以发送到一个或另一个？！
www.mysite.com 应 仅 指向 CloudFront。我个人会为此使用 CNAME。- 您的遗留服务器和 EC2 弹性负载均衡器都应该有明确的地址 - 我个人会给他们自己明确的域名，以避免混淆（例如
legacy.mysite.com & beta.mysite.com ) - 并且在 CloudFront 中，当您引导流量时仅引用那些清晰的名称（例如，将流量传递到 www.mysite.com 作为转到旧服务器的方式会造成混淆）。
祝你好运！
我正在分阶段用新网站替换旧网站。从用户的角度来看，所有现有的 URL 必须保持不变，但某些路径应该服务于新页面。
我有两个原始服务器：旧服务器 (www.mysite.com) 和新的 EC2 (www.ec2-loadbalancer.com) – 出于隐私原因，显然是模拟 URL。
我创建了一个 CNAME 设置为 www.mysite.com 的 AWS CloudFront 分配。在此发行版中，我创建了两个来源域：
www.mysite.comwww.ec2-loadbalancer.com
在 CloudFront 中，我配置了一些行为，以便将 /foo 之类的路径发送到我的 EC2 负载均衡器源，并将所有其他路径（例如默认路径）发送到 www.mysite.com。
从 DNS 的角度来看，我添加了 www.mysite.com 的 CNAME 记录，它指向我的 Cloudfront 主机域（例如 foo.cloudfront.net.）。此域的 A 记录指向旧服务器的 IP。
我今天启动了所有这些并且它似乎有效，但我在网站上看到间歇性的 403 错误，并且在进行更改两个小时后（没有 "www" CNAME 之前，所以 TTL 应该不会有什么不同），一些浏览器仍在从原始 IP（而不是 CloudFront 的）为站点提供服务。
我配置正确了吗？我不知道如何通过 A 记录来做到这一点——它指向遗留服务器的 IP，而 CloudFront 不允许我输入 IP 地址作为来源。我是否应该将 www CNAME 指向 IP 地址，而将 A 记录指向 CloudFront？我在这里有点迷路。
另一方面，这可能都是传播问题，但我很担心在进行更改后数小时内看到 40 倍的错误。
我认为您应该创建一个 A 记录（用于指定的域名），其中的别名指向云端分布。应该可以解决问题。
即使用别名而不是 IP 地址并将您的域指向云端：
很遗憾您不能与我们共享域以帮助调试，但至少，dig 是您的朋友。例如：
$ dig membership.theguardian.com
...
;; ANSWER SECTION:
membership.theguardian.com. 367 IN CNAME i.global-ssl.fastly.net.
i.global-ssl.fastly.net. 12 IN A 151.101.128.67
i.global-ssl.fastly.net. 12 IN A 151.101.64.67
i.global-ssl.fastly.net. 12 IN A 151.101.0.67
i.global-ssl.fastly.net. 12 IN A 151.101.192.67
...告诉您 membership.theguardian.com 通过 CNAME 指向 Fastly。您可以检查备用 DNS 服务器，例如 8.8.8.8 上的 Google's DNS，方法是：
$ dig @8.8.8.8 membership.theguardian.com
...这样您就可以看到其他人是如何解析您的域的。
From a DNS perspective, I've added a CNAME record of www.mysite.com which points to my Cloudfront host domain (eg. foo.cloudfront.net.). The A record for this domain points to the IP of the legacy server.
我不是 DNS 专家，所以我在这里可能没有理解您的意思，但这听起来像是引入了歧义？对我来说，这听起来像是您对同一个 www.mysite.com 域有两个不同的记录，其中一个指向 CloudFront，另一个指向旧服务器的 IP。取决于如何解决，浏览器可以发送到一个或另一个？！
www.mysite.com应 仅 指向 CloudFront。我个人会为此使用 CNAME。- 您的遗留服务器和 EC2 弹性负载均衡器都应该有明确的地址 - 我个人会给他们自己明确的域名，以避免混淆（例如
legacy.mysite.com&beta.mysite.com) - 并且在 CloudFront 中，当您引导流量时仅引用那些清晰的名称（例如，将流量传递到www.mysite.com作为转到旧服务器的方式会造成混淆）。
祝你好运！