Cloudfront自定义来源分发返回502“错误无法满足该请求。” 对于某些URL

71

我们拥有一个具有自定义来源的Cloudfront发行版，该发行版已经运行了很长时间了，可以为我们的一个站点提供静态资产。就在今天早上，我们注意到我们的徽标显示为断开的链接。

经过进一步调查，Cloudfront返回了一个我从未见过的有关该URL的奇怪错误消息：

错误

无法满足该请求。

由cloudfront（CloudFront）生成

此发行版中的其他几个Cloudfront URL返回相同的错误，但是其他（同样来自相同发行版）的URL正常运行。我看不到什么可行和无效的模式。

其他一些数据点：

  • 该产地的URL工作得很好。据我所知，最近没有服务中断。
  • 我专门使徽标URL无效，没有任何效果。
  • 我已经使发行版的根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>
ssl  cdn  amazon-cloudfront 
— 戴维·艾克
source
3
有趣的是...。我刚刚创建了我的第一个发行版（没有自定义CNAME），并且得到了同样的东西。从基本的一切开始，但还没有运气。
— 肖恩·杜贝
是的，我创建了一个新的发行版进行测试，并且同样。：\
— David Eyk 2013年
我遇到了类似的问题，尽管我从CloudFront发行版中获取了一些静态文件的504网关超时。我意识到我已经启用了pglcmd通过iptables阻止IP范围的功能。我仍然不知道为什么CloudFront正在检查这些文件，这些文件的到期标头设置为一年。
— paradroid

Answers:

34

最近我有一个类似的问题，事实证明这是由于我使用的ssl_ciphers所致。

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

“ CloudFront使用SSLv3或TLSv1协议以及AES128-SHA1或RC4-MD5密码将HTTPS请求转发到原始服务器。如果您的原始服务器不支持AES128-SHA1或RC4-MD5密码，则CloudFront无法建立SSL连接归根结底。”

我必须更改我的nginx confg来向ssl_ciphers添加AES128-SHA（不推荐使用RC4：HIGH）以解决302错误。我希望这有帮助。我已经从ssl.conf中粘贴了该行

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5;
— 矿工
source
这似乎是解决我特定问题的正确解决方案，尽管似乎有多种方法可以获取该错误消息，这在此处的其他答案中也得到了反映。
— David Eyk 2014年
4
您可能希望使用AES128-SHA而不是RC4:HIGH。使用RC4:HIGH降级我Qualsys SSL实验室的测试得分从A到C.
— 大卫的Eyk
这也解决了我的问题。但是，我必须使用AES128-SHA1带有“ 1”的。没有1，它对我不起作用。此外，AWS建议使用安全性较低的TLSv1not SSLv3。
— bmorenate
128

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

— 阿德里安
source
4
就我而言，这是CNAME中的错字。h！
— maksimov
1
谢谢，这个解决了！
— 马特·沃卡斯
4
添加备用CNAME后，CloudFront分发状态（在“常规”选项卡下）需要一段时间才能从“进行中”变为“已部署”。在此期间，您仍然会收到类似的CloudFront错误消息。就我而言，大约花了半个小时。
— idoimaging '17
对于某些要查找更改cname的用户：转到CloudFront部分=>选择您的cloudfront =>选择General=> Edit=>在其中添加您的CNAME网址Alternate Domain Names (CNAMEs)（位于第三行）
— 2018年
13

找到了我的答案，并在此处添加了它，以防它帮助David（及其他）。

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

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

但是，我的原始协议策略设置为仅HTTP。这导致CloudFront找不到我的文件并抛出502错误。另外，我认为它将502错误缓存了5分钟左右，因为删除301重定向后，它无法立即工作。

希望有帮助！

— 肖恩·杜伯
source
嗯！我的情况不尽相同，但我敢打赌，这真的很接近。
— 大卫·艾克
你确定？我将您的网址作为http运行并得到：HTTP / 1.1 301永久移动服务器：nginx / 0.7.65日期：2013年12月19日，星期四05:00:15 GMT内容类型：text / html内容长度：185连接：keep -alive位置：my.crossway.org/static/img/crossway_logo.png <html> <head> <title> 301永久移动</ title> </ head> <body bgcolor =“ white”> <center> <h1 > 301永久移动</ h1> </ center> <hr> <center> nginx / 0.7.65 </ center> </ body> </ html>
— Shawn Dube 2013年
1
但是我没有HTTP Only在原产地政策中使用，而是在使用Match Viewer。奇怪的是，直到最近它还可以正常工作。
— 大卫·埃克
我认为，即使您使用“匹配查看器”，也可能会引起问题，即使不是这样。我在主页上输入301时碰到了同样的东西，它在5分钟的缓存长度内破坏了该页面。
— 彼得
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标头设置为Error来自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结果

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

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

这工作了很长时间，然后才突然停止。发生的事情是我刚刚更新了当年的证书，但是在导入期间，所有以前的证书的证书路径都发生了更改。他们都开始引用“ COMODO RSA证书颁发机构”，而在此链较长之前，其根是“ AddTrust外部CA根”。

错误的证书路径

因此，切换回旧版证书无法解决Cloudfront问题。

我不得不删除名为“ COMODO RSA证书颁发机构”的额外证书，该证书没有引用AddTrust。完成此操作后，我所有网站证书的路径都更新为再次指向AddTrust / USERTrust。注意还可以从路径中打开错误的根证书，单击“详细信息”->“编辑属性”，然后以这种方式禁用它。这将立即更新路径。您可能还需要删除证书的多个副本，这些副本位于“个人”和“受信任的根证书颁发机构”下

良好的证书路径

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

完成所有这些操作后，ssl-checker开始显示链中的第三个证书，该证书指向“ AddTrust External CA Root”

具有所有证书的SSL Checker

最终，CloudFront接受了源服务器的证书和所提供的链被信任。我们的CDN重新开始正常工作！

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

— 埃迪·弗莱彻
source
4

另一个可能的解决方案：我有一个登台服务器，通过HTTP为站点和Cloudfront资产提供服务。我的来源设置为“匹配查看器”，而不是“仅HTTP”。我还使用HTTPS Everywhere扩展名，该扩展名将所有http://*.cloudfront.netURL重定向到该https://*版本。由于暂存服务器无法通过SSL使用，并且Cloudfront与查看器匹配，因此它找不到资产https://example.com并缓存了一堆502。

— 德文
source
2

我只是对这个问题进行了故障排除，就我而言，它确实与重定向有关，但与CloudFront Origin或Behavior中的错误设置无关。如果您的原始服务器仍重定向到原始URL，而不是您为cloudfront URL设置的URL，则会发生这种情况。如果您忘记更改配置，这似乎很常见。举例来说，假设您在自己的云发行版中拥有www.yoursite.com CNAME，且其来源是www.yoursiteorigin.com。显然，人们会来www.yoursite.com。但是，如果您的代码尝试重定向到www.yoursiteorigin.com上的任何页面，您将收到此错误。

对我来说，我的来源仍在将http-> https重定向到我的来源URL，而不是我的Cloudfront URL。

— 彼得
source
2

就我而言，这是因为我们的SSL证书无效。问题出在我们的登台盒上，我们也使用了产品证书。在过去的几年中，使用此配置一直有效，但是突然之间，我们开始收到此错误。奇怪。

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

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

— 彼得·P。
source
1

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

— 盖
source
1

通过串联我的证书以生成有效的证书链（使用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;

希望能帮助到你！

— 佩德罗
source
1

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

更具体地说，在Cloudflare的Crypto设置中，我已将“最小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。

— 约翰·韦伯德
source
1

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

要解决此问题，我必须：

  1. 前往ALB
  2. 在“侦听器”选项卡下，选择我的侦听器，然后选择“编辑”。
  3. 在默认SSL证书下，选择正确的原始证书。
— 帕可G
source
0

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

  1. 单击分发。
  2. 选择您的发行版。
  3. 单击来源标签。
  4. 选择您的原始服务器。
  5. 单击编辑。
  6. 在“原始SSL协议”下选择您的来源支持的所有协议
— 白血病
source
0

当心源协议策略：

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

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

请注意，这与查看器协议策略不同。您可以在此处详细了解两者之间的区别。

— 保罗·拉兹万·伯格
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.