我使用的是 AWS 的“基本支持”计划，因此无法咨询那里的内部技术专家。我试图设置 cloudfront。我的后端位于 AWS 香港。但是，我注意到 Cloudfront HK 服务器“前端”的流量不会直接转到我的后端 EC2 服务器，该服务器也位于 AWS 香港。相反，请求从 AWS 新加坡发送到我的 HK EC2。（换句话说，HK CloudFront 代理通过新加坡从我的 HK EC2 原始服务器获取内容。）这种情况常见吗？这会增加请求的不必要的延迟。直接请求可以在 100 毫秒内完成，但这需要 250 毫秒。我检查了这是否仅适用于香港，结果发现并非如此。我从东京发出了一个请求，该请求被 CloudFront Tokyo 捕获。从那里，它不是直接发送到香港，而是发送到新加坡，然后从那里重定向回香港。知道为什么会这样吗？我无法想出任何合理的理由来解释为什么 AWS 会将发往同一位置另一台服务器的流量通过第三国进行路由，而不是直接在该位置内进行路由。
需要说明的是，Cloudfront 中的原始服务器采用经典的 aws DNS 表示法 (ip-address-location-awz.amazon.com)。CF 不可能认为它是非 AWS IP 地址。
答案1
您所看到的情况的原因已有记录，但文档中没有提供太多细节或对其含义的讨论。
CloudFront 网络有两层。
有外部“全球”层和内部“区域”层。大多数 AWS 区域都有区域 CloudFront 边缘，但并非所有区域都有——香港目前是一个例外，它是一个没有区域边缘的 AWS 区域。
请求通常会到达查看器附近的“全球边缘”位置（例如美国佐治亚州亚特兰大），在此检查边缘缓存并提供内容，或者将请求转发到原点。
但它没有被转发直接地回到原点。
相反，请求会被转发到最近的“区域缓存”（例如来自亚特兰大，可能是美国俄亥俄州——us-east-2 区域），在那里检查该缓存是否有响应。如果找到，它会返回到处理原始请求的全局边缘，在那里它会被存储在缓存中（如果可缓存）并返回给查看器。
如果区域缓存也没有副本，则请求将从那里转发到原始服务器，并且响应缓存在区域缓存中，并返回到原始全局边缘，如果可能的话也缓存在那里，然后返回给查看器。
从统计上看，这一切在缓存命中方面都运行良好，尽管在这种情况下，它会在缓存未命中和不可缓存内容方面引入往返劣势，因为香港边缘必须咨询新加坡区域边缘，然后新加坡区域边缘必须将请求发送回香港的 EC2。（亚特兰大到俄亥俄州再到香港无疑比香港到新加坡再到香港更合理）。
如果 CloudFront 在香港部署区域边缘，这种行为将来几乎肯定会改变。
单个请求的往返基准也不一定能说明整个性能情况，特别是在低流量环境中。CloudFront 支持 http/2，因此可以在单个浏览器连接上并行处理多个请求，CloudFront 通过向源发出的一系列独立 HTTP/1.1 请求在后端并行处理这些请求。CloudFront 在全球边缘处理与浏览器的 TLS 协商，并重用从全球边缘到区域缓存以及从区域缓存到源服务器的连接，因此在积极处理流量的站点上，请求更有可能从这些优化中受益，从而减少实际往返时间（与单独观察到的时间相比）。
看CloudFront 如何与区域边缘缓存配合使用和全球和区域边缘列表。
看源保持活动超时讨论如何自定义您的分发配置，以增加 CloudFront 保持开放后端连接以供重复使用的时间；默认值仅为 5 秒，但您可以将其增加到 60 秒，或者通过特殊安排将其增加更多。另请参阅自定义来源/持久连接。