设置
我们正在尝试使用CloudFront的Web / wix / etc-like网站pipe理系统。 它具有以下域和子域。
– 我们的域名：我们的主要网站
– admin.ourdomain：每个网站的pipe理界面，可通过https访问
– images.ourdomain：一个S3桶
– router.ourdomain：见下文
– [customersomething] .ourdomain：我们的免费用户的子域名
– [customersomething.com]：我们的高级客户的域名
该系统的工作方式，其中大部分域名是CNAME-d到router.ourdomain（因为这是我们的客户与他们不同的域名注册商等最简单的方式），而router.ourdomain是我们的别名ELB，然后我们的EC2-s上的PHP正在处理基于HTTP_HOST值的站点，而来自S3的图像。
我们的计划
现在我们想把这些东西放在CloudFront的后面。 大部分东西是微不足道的。 把S3放在CF后面很容易。 通过asset.ourdomain子域很容易将每个ourdomain / *。（js | css）放在CF后面。 我们可以使用* .images.ourdomain在子域之间进行分割，减less客户端的加载时间等。我们甚至可以把每个* .ourdomain的东西，包括PHP的免费网站放在CF后面，把“* .ourdomain”进入CF参数。
问题
但是我们无法弄清楚的一点是如何将所有dynamic创build的PHP网站与自定义域放在CF后面。 提醒一下：这些是CNAME-d到router.ourdomain。 把每个域放到CF参数中是不可取的，因为我们需要能够处理数以万计的域名，而且我们需要为每个域名进行手动configuration。
所以我们的想法是我们应该把router.ourdomain作为备用域名放入CFconfiguration中，在route 53中将router.ourdomain指向CF，然后将CF指向我们的ELB作为原点。 我们发现每次都得到这个消息是一个很好的方法：“错误请求不能被满足，错误的请求，由cloudfront（CloudFront）生成”。 其实并不是每一次，因为www .ourdomain的工作，因为它应该（这是CNAMEd router.ourdomain），但其他每个子域给出了上面的错误（* .ourdomain是CNAMEd到router.ourdomain，但它也是一样的那些被CNAMEd的子域一个一个的去除router.ourdomain，除了www，当然还有路由器）。 所以现在我们不是不知道我们该如何解决这个问题，我们甚至不明白，为什么它对www不起作用，反之亦然。
任何想法和想法，将不胜感激，谢谢。
提醒一下：这些是CNAME-d到router.ourdomain
是的，你提到过。 这是关于这个的事情：
没关系。
是的，CloudFront将备用主机名称称为CNAME。 是的，CNAME DNSlogging是您将路由指定网站stream量的典型方式，以击中CloudFront。 但是，不能，将主机名configuration为指向您的CloudFront分配的CNAME与现在Cloudfront（通常为HTTP）无关。
当浏览器想要连接到Web服务器时，它会从DNS中查找IP地址。 如果path中有CNAME，则丢弃该信息。 浏览器所关心的是“我要连接哪个IP地址？”
假设www.example.org是webfarm.example.com的CNAME。 浏览器查找www.example.org并以webfarm.example.com的IP地址结束。
手中的答案，浏览器build立一个连接到Web服务器，并发送一个请求。
GET / HTTP/1.1 Host: www.example.com 浏览器发送的http请求中的Host:头部包含主机名，如地址栏中所示。 CNAME信息完全不可用，浏览器或Web服务器都不知道。
那么CNAME如何与请求parsing和第7层路由相关？ 不可能。 CNAME目标仅用作查找要连接的IP地址的path。
您的发行版不是在Cloudfront上使用这些IP地址的唯一的发行版。 有成百上千的人 它归结为Host:标题。
“CNAME”（备用主机名）列表是一组主机名，用于CloudFront在传入Host:标题中匹配以确定请求应被视为属于您的分配。 这是一个浏览器可能发送的Host:头文件列表。 在Host:头与configuration中的configuration值匹配之前，与该请求关联的分配是未知的并且是未定义的。
如果Cloudfront与任何发行版无法匹配传入的Host:标头，Cloudfront会执行什么操作？
HTTP/1.1 400 Bad Request
所以，你所看到的行为是可以预料的，而且是正确的。 通配符在CloudFrontconfiguration中可以工作，只要它们构成备用主机名configuration行中唯一最左侧的元素即可。 但这与DNS无关。
如果您希望他们使用您的发行版，则无法避免在CloudFront中configuration其他客户拥有的域名。
但是，您可以通过API以编程方式修改它们，而不是手动：
http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html
每个分配有100个这样的别名限制，但是您可以通过向AWS支持提交表单来请求增加。 但事实上，您可以将它们分解为多个发行版，因为CloudFront不会在给定path上使用请求esders中的一台主机caching对象，并将其作为caching的不同响应返回主机，即使是在相同的分布，如果你转发主机头到原始服务器（你必须做的，如果原始服务器是能够分辨出来的）。 它不能，因为请求中的重要参数已经从一个请求改变到另一个请求。