由于重定向是浏览器的指令，它告诉浏览器在其他地方查找请求的资源

Since a redirect is an instruction for the browser, telling it to look elsewhere for the requested resource, CloudFront isn't designed to follow redirects itself -- it returns the redirect to the browser.

您想要的是一个新的CloudFront缓存行为和一个新的CloudFront Origin服务器声明，该声明已在处理您网站的现有CloudFront发行版中配置.

What you want, instead, is a new CloudFront Cache Behavior, and a new CloudFront Origin server declaration, configured in the existing CloudFront distribution that's handling your site.

在CloudFront中，添加一个新的Origin，将Origin Domain Name(原始域名)设置为指向EC2实例的主机名(如果存在，则指向实例前面的负载均衡器).您会注意到一个名为"Origin Path"的字段，您可能会想将其设置为"/blog/"或类似名称，但这是不正确的.将原始路径"留空.

In CloudFront, add a new Origin, setting the Origin Domain Name to the hostname pointing to the EC2 instance (or to the load balancer in front of the instance, if there is one). You'll notice a field called "Origin Path" which you might be tempted to set to "/blog/" or something similar, but that is incorrect. Leave "origin Path" blank.

然后添加与路径模式/blog/* 匹配的新缓存行为，并将其指向新的源.

Then add a new Cache Behavior matching the Path Pattern /blog/* and pointing it to the new origin.

简而言之，这就是您要寻找的东西，但是还有其他一些因素需要适当的设置和配置.

That, in a nutshell, is what you are looking for, but there are several other factors that will require appropriate settings and configuration.

除非您将源协议策略"设置为仅HTTP"，否则您将在源服务器上需要TLS证书，在这种情况下，您正在CloudFront和EC2之间运行未加密的流量.CloudFront具有特定要求在原始服务器上正确配置TLS，并且与TLS相关的大多数错误配置都会导致

You'll need a TLS certificate on your origin server, unless you set the Origin Protocol Policy to HTTP Only, in which case you're running unencrypted traffic between CloudFront and EC2. CloudFront has specific requirements for correctly configuring TLS on your origin server and most misconfigurations related to TLS will result in a 502 Bad Gateway error though of course there can be other causes for that error code.

您的博客软件可能需要查询字符串参数和/或cookie，默认情况下，CloudFront会从所有请求中删除它们(因为它们会干扰缓存).这是两个缓存行为"设置通常需要自定义，因为默认设置基于典型静态内容的适当设置.

Your blog software might require query string parameters and/or cookies, which CloudFront, by default, strips from all requests (because they interfere with caching). These are two of the Cache Behavior settings that commonly require customization, since the defaults are based on appropriate settings for typical static content.

您还需要配置博客软件，以期望传入的请求包含路径前缀"/blog/"，因为CloudFront不会删除路径组件.呈现原始服务器中删除一个或多个元素的路径的唯一方法是使用Lambda @ Edge重写路径-正如我在这里解释的那样.

You will also need to configure your blog software to expect the incoming requests to include the path prefix "/blog/" because CloudFront does not remove path components. The only way to present the path to the origin server with one or more elements stripped from it is to use Lambda@Edge to rewrite the path -- as I explained here.

如果您现在在脑子里***将路径设置为"/blog/"而不是"/blog"，则需要牢记的问题是此路径需要正确的锚定-HTTP语义假定目录级别以"/"结尾"，而文件和其他资源则没有，因此，如果您尝试将博客放在不以/结尾的路径上，则可能会遇到困难...但是这样做的好处是不应该键入尾随/的用户，您仍然需要在S3中配置重定向-但这仅是为了发送对/blog 的请求回到/blog/.

If you are now mentally protesting the path being set to "/blog/" instead of "/blog", the problem to keep in mind is that this path needs correct anchoring -- HTTP semantics assume directory levels end with "/" while files and other resources don't, so you're likely to encounter difficulties if you try to put the blog at a path that doesn't end with /... but for the benefit of users who shouldn't be expected to type the trailing /, you still do need to configure a redirect in S3 -- but only in order to send requests for /blog right back to /blog/.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyEquals>blog</KeyEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyWith>blog/</ReplaceKeyWith>
      <HostName>${main_site_hostname}</HostName>
      <Protocol>https</Protocol>
    </Redirect>
  </RoutingRule>
</RoutingRules>

在测试时，您可能还需要将 Error Caching Minimum TTL设置为0 ，以便不进行修复一个问题，即使您所做的更改已解决了错误，在接下来的5分钟内仍会看到返回的缓存错误.CloudFront这样做是为了帮助避免使可能已经遇到问题的原始服务器超载(如返回错误的事实所证明)，但它会使某些用户措手不及.

When testing, you may also want to set your Error Caching Minimum TTL to 0 so that you don't fix a problem and keep seeing cached errors returned for the next 5 minutes, even though the error has been resolved by a change you made. CloudFront does this to help avoid overloading an origin server that might already be experiencing problems (as evidenced by the fact that it's returning errors), but it catches some users off guard.