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

Question

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

Dav*_*Eyk 64 ssl cdn amazon-cloudfront

我们有一个Cloudfront发行版,其定制来源已经运行了很长时间,为我们的一个站点提供静态资产.就在今天早上,我们注意到我们的徽标显示为断开链接.

经过进一步调查,Cloudfront将返回一条我之前从未见过的有关URL的奇怪错误消息:

错误

请求无法满足.

由cloudfront生成(CloudFront)

此分发中的其他几个Cloudfront 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>

Run Code Online (Sandbox Code Playgroud)

Answer 1

adr*_*TNT 125

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

添加备用CNAME后,CloudFront分配状态(在"常规"选项卡下)需要一段时间才能从"InProgress"转到"已部署".在此期间,您仍会收到类似的CloudFront错误消息.在我的情况下花了大约半个小时. (4认同)
就我而言,它是CNAME中的拼写错误.咄! (3认同)
这解决了我,谢谢! (2认同)
谢谢，这就解决了！ (2认同)
对于某些人要查找更改 cname：转到“CloudFront”部分 => 选择您的 Cloudfront => 选择“常规”=>“编辑”=> 在“备用域名 (CNAME)”中添加您的 CNAME url（位于第 3 行） (2认同)

Answer 2

dmi*_*ner 31

最近我遇到了一个类似的问题,原因是我使用的是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配置,将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;

Run Code Online (Sandbox Code Playgroud)

您可能希望使用`AES128-SHA`而不是`RC4:HIGH`.使用`RC4:HIGH`将我的[Qualsys SSL实验室](https://www.ssllabs.com/ssltest/analyze.html)测试分数从A降级为C. (4认同)

Answer 3

小智 14

找到我的答案并将其添加到此处以防万一(和其他人).

结果我的原始服务器(比如www.example.com)上有301重定向设置,将HTTP更改为HTTPS:

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

Run Code Online (Sandbox Code Playgroud)

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

希望有所帮助!

Answer 4

Edd*_*fen 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域验证安全服务器CA",由"COMODO RSA证书颁发机构"颁发

似乎CloudFront不持有"COMODO RSA证书颁发机构"的证书,因此认为源服务器提供的证书是自签名的.

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

证书路径错误

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

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

良好的证书路径

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

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

SSL Checker包含所有证书

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

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

Answer 5

Dev*_*vin 6

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

归档时间：	11 年，8 月前
查看次数：	90129 次
最近记录：	6 年，1 月前