Cloudfront自定义源分发返回502“ERROR无法满足请求。”对于某些网址

时间：2013-12-18 16:58:02

标签： ssl cdn amazon-cloudfront

我们拥有一个自定义源的Cloudfront发行版，该版本在很长一段时间内都运行良好，为我们的某个站点提供静态资源。就在今天早上，我们注意到我们的徽标显示为断开链接。

经过进一步调查，Cloudfront将返回一条奇怪的错误消息，这是我以前从未见过的URL in question：

  

ERROR

     

无法满足请求。

     
     
     

由cloudfront（CloudFront）生成

此分发中的其他几个Cloudfront URL返回相同的错误，但其他（同样，来自同一分发）的工作正常。我没有看到什么有效，哪些无效的模式。

其他一些数据点：

  • origin URLs工作正常。据我所知，最近没有服务中断。
  • 我特意使徽标网址无效，无效。
  • 我已经使分发的根URL无效，无效。

知道这里发生了什么吗？我以前从未见过Cloudfront这样做过。

更新

以下是来自Cloudfront的逐字HTTP响应：

$ http GET https://d2yu7foswg1yra.cloudfront.net/static/img/crossway_logo.png
HTTP/1.1 502 Bad Gateway
Age: 213
Connection: keep-alive
Content-Length: 472
Content-Type: text/html
Date: Wed, 18 Dec 2013 17:57:46 GMT
Server: CloudFront
Via: 1.1 f319e8962c0268d31d3828d4b9d41f98.cloudfront.net (CloudFront)
X-Amz-Cf-Id: H_HGBG3sTOqEomHzHubi8ruLbGXe2MRyVhGBn4apM0y_LjQa_9W2Jg==
X-Cache: Error from cloudfront

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
</BODY></HTML>

<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated by cloudfront (CloudFront)
</ADDRESS>
</BODY></HTML>

14 个答案:

答案 0 :(得分：125)

我今天在Amazon Cloudfront上遇到此错误。这是因为我使用的cname（例如cdn.example.com）没有添加到“alternate cnames”下的分发设置中，我只将cdn.example.com转发到我的站点/主机控制面板中的cloudfront域，但是您还需要将其添加到Amazon CloudFront面板。

答案 1 :(得分：31)

我最近遇到了类似的问题，原因是我使用的是ssl_ciphers。

来自http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html，

＆＃34; CloudFront使用SSLv3或TLSv1协议以及AES128-SHA1或RC4-MD5密码将HTTPS请求转发到源服务器。如果源服务器不支持AES128-SHA1或RC4-MD5密码，则CloudFront无法与您的源建立SSL连接。 ＆＃34;

我不得不更改我的nginx配置，将AES128-SHA（不推荐的RC4：HIGH）添加到ssl_ciphers以修复302错误。我希望这有帮助。我已经从我的ssl.conf

粘贴了这一行 
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;

答案 2 :(得分：14)

找到我的答案并在此处添加，以防大卫（和其他人）帮助。

原来我的原始服务器（比如www.example.com）上有301重定向设置，将HTTP更改为HTTPS：

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/images/Foo_01.jpg

但是，我的Origin Protocol Policy仅设置为HTTP。这导致CloudFront找不到我的文件并抛出502错误。另外，我认为它缓存了502错误5分钟左右，因为它在删除301重定向后没有立即工作。

希望有所帮助！

答案 3 :(得分：8)

在我们的案例中，所有内容都很好，但是大部分时间都需要考虑到这一点：

TLDR：检查证书路径以确保根证书正确无误。对于COMODO证书，它应该说“USERTrust”并由“AddTrust External CA Root”发布。不是“COMODO RSA认证机构”发布的“COMODO”。

来自CloudFront文档： http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

  

如果源服务器返回无效证书或自签名证书，或者原始服务器以错误的顺序返回证书链，CloudFront将丢弃TCP连接，返回HTTP错误代码502，并设置X-Cache标题为来自cloudfront的错误。

我们根据http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

启用了正确的密码

根据Google，Firefox和ssl-checker，我们的证书有效： https://www.sslshopper.com/ssl-checker.html

SSL Checker result without all required certificates

然而，ssl检查链中的最后一个证书是“COMODO RSA域验证安全服务器CA”，由“COMODO RSA证书颁发机构”发布

似乎CloudFront不持有“COMODO RSA证书颁发机构”的证书，因此认为原始服务器提供的证书是自签名的。

这显然是在突然停止之前工作了很长时间。发生了什么事情我刚刚更新了今年的证书，但在导入过程中，所有以前的证书的证书路径中都发生了一些变化。他们都开始引用“COMODO RSA认证机构”，而在链条更长，根目录是“AddTrust External CA Root”之前。

Bad certificate path

因此，切换回较旧的证书并未解决云端问题。

我不得不删除名为“COMODO RSA Certification Authority”的额外证书，该证书没有引用AddTrust。执行此操作后，我的所有网站证书路径都会更新，以便再次指向AddTrust / USERTrust。注意也可以从路径中打开坏根证书，点击“详细信息” - ＆gt; “编辑属性”，然后以这种方式禁用它。这立即更新了路径。您可能还需要删除“个人”和“受信任的根证书颁发机构”下的证书的多个副本

Good certificate path

最后，我不得不在IIS中重新选择证书，以使其服务于新的证书链。

毕竟，ssl-checker开始在链中显示第三个证书，该证书指向“AddTrust External CA Root”

SSL Checker with all certificates

最后，CloudFront接受了原始服务器的证书，并将提供的链称为受信任的。我们的CDN再次开始正常工作！

为了防止将来发生这种情况，我们需要从具有正确证书链的机器导出我们新生成的证书，即不信任或删除“COMODO RSA Certification Authroity”颁发的证书“COMODO RSA Certification Authroity”（在2038年到期）。这似乎只影响Windows机器，默认安装此证书。

答案 4 :(得分：2)

我刚刚解决了这个问题，在我的情况下，它确实与重定向有关，但与我的CloudFront Origin或Behavior中的错误设置无关。如果您的源服务器仍然重定向到原始URL，而不是您为您的Cloudfront URL设置的，则会发生这种情况。如果您忘记更改配置，这似乎很常见。例如，如果您有www.yoursite.com CNAME到您的Cloudfront分发版，请访问www.yoursiteorigin.com。显然人们会来www.yoursite.com。但是，如果您的代码尝试重定向到www.yoursiteorigin.com上的任何页面，您将收到此错误。

对我来说，我的来源仍然是对我的原始网址进行http-＆gt; https重定向，而不是我的Cloudfront网址。

答案 5 :(得分：2)

在我的情况下，这是因为我们有一个无效的ssl证书。问题出现在我们的临时箱上，我们也使用了我们的产品证书。在过去的几年里，它已经使用了这种配置，但突然间我们开始出现这个错误。奇怪。

如果其他人收到此错误，请检查ssl证书是否有效。您可以通过AWS CloudFront分配界面启用到s3的日志记录以帮助调试。

此外，您可以在此处参考亚马逊的文档：http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

答案 6 :(得分：2)

另一种可能的解决方案：我有一个登台服务器，通过HTTP为站点和Cloudfront资产提供服务。我的原点设置为＆＃34;匹配查看器＆＃34;而不是＆＃34; HTTP Only＆＃34;。我还使用HTTPS Everywhere扩展程序，该扩展程序将所有http://*.cloudfront.net网址重定向到https://*版本。由于登台服务器无法通过SSL提供，而且Cloudfront与查看器匹配，因此无法在https://example.com找到资产并缓存一堆502.

答案 7 :(得分：1)

在我们的案例中，我们已经放弃了对原始服务器上的PCI-DSS合规性的SSL3，TLS1.0和TLS1.1的支持。但是，您必须在CloudFront原始服务器配置上手动添加对TLS 1.1+的支持。 AWS控制台显示客户端到CF的SSL设置，但在向下钻取之前不会轻易显示CF到源的设置。要修复，请在CloudFront下的AWS控制台中进行修复：

  1. 点击DISTRIBUTIONS。
  2. 选择您的发行版。
  3. 点击ORIGINS标签。
  4. 选择您的原始服务器。
  5. 点击编辑。
  6. 在“Origin SSL Protocols”
    7. 下选择您的源支持的所有协议

答案 8 :(得分：1)

对于我的特殊情况，这是由于CloudFront Behavior背后的Origin ALB拥有DEFAULT ACM证书所指向的另一个域名。

要解决此问题，我必须：

  1. 转到ALB
  2. 在“监听器”选项卡下，选择我的监听器，然后选择“编辑”
  3. 在默认SSL证书下，选择正确的原始证书。

答案 9 :(得分：0)

我遇到了这个问题，在我停止使用代理后解决了这个问题。也许CloudFront将一些IP列入黑名单。

答案 10 :(得分：0)

通过连接我的证书来生成有效的证书链（使用GoDaddy标准SSL + Nginx）来解决此问题。

http://nginx.org/en/docs/http/configuring_https_servers.html#chains

生成链：

cat 123456789.crt gd_bundle-g2-g1.crt > my.domain.com.chained.crt

然后：

ssl_certificate /etc/nginx/ssl/my.domain.com.chained.crt;
ssl_certificate_key /etc/nginx/ssl/my.domain.com.key;

希望它有所帮助！

答案 11 :(得分：0)

就我而言，我使用nginx作为API网关URL的反向代理。我得到了同样的错误。

当我将以下两行添加到Nginx配置时，我解决了这个问题：

proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com";
proxy_ssl_server_name on;

来源在这里：Setting up proxy_pass on nginx to make API calls to API Gateway

答案 12 :(得分：0)

在我的情况下，问题是我同时使用了Amazon的Cloudflare和Cloudfront的Cloudfront，而Cloudfront不喜欢我提供的Cloudflare设置。

更具体地说，在Cloudflare的“加密”设置中，我已将“最小TLS设置”设置为1.2，而没有为Cloudfront中的分发启用TLS 1.2通信设置。这足以使Cloudfront在尝试连接到受Cloudflare保护的服务器时声明502 Bad Gateway错误。

要解决此问题，我必须在该Cloudfront发行版的“原始设置”中禁用SSLv3支持，并启用TLS 1.2作为该原始服务器支持的协议。

为调试此问题，我使用了curl的命令行版本，以查看从CDN询问映像时Cloudfront实际返回的内容，并且我还使用了openssl的命令行版本来确切确定哪个版本。 Cloudflare提供的协议（不提供TLS 1.0）。

tl：dr;确保所有内容都能接受并要求TLS 1.2，或者在您阅读本文时，每个人都在使用最新的和最先进的TLS。

答案 13 :(得分：0)

当心Origin Protocol Policy：

对于HTTPS查看器请求CloudFront转发到该来源，来源服务器上SSL证书中的域名之一必须与您为“来源域名”指定的域名匹配。否则，CloudFront会使用HTTP状态代码502（错误网关）响应查看器请求，而不是返回所请求的对象。

在大多数情况下，您可能希望CloudFront使用“仅HTTP”，因为它从也可能由Amazon托管的服务器中获取对象。此步骤无需额外的HTTPS复杂性。

请注意，这与Viewer Protocol Policy不同。您可以详细了解两个here之间的区别。

相关问题
最新问题