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

我们有一个自定义起源的Cloudfront发行版,在很长一段时间内工作得很好,为我们的网站之一提供静态资产。 就在今天上午,我们注意到我们的标志显示为一个断开的链接。

经过进一步调查,Cloudfront正在返回一个奇怪的错误消息,我从来没有见过这个url :

错误

请求不能满足。



由云端产生(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> 

最近我有一个类似的问题,原来是由于我正在使用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将无法build立SSL连接来源于你“。

我不得不改变我的Nginx confg添加AES128-SHA(弃用RC4:高)ssl_ciphers修复302错误。 我希望这有帮助。 我已经从我的ssl.conf中粘贴了该行

 ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:AES128-SHA:!ADH:!AECDH:!MD5; 

今天我与亚马逊Cloudfront有这个错误。 这是因为我使用的cname(例如cdn.example.com)未添加到“alternate cnames”下的分发设置中,我只有cdn.example.com转发到我的网站/托pipe控制面板中的cloudfront域,但您还需要将其添加到Amazon CloudFront面板。

find我的答案,并在这里添加它,以帮助大卫(和其他人)。

原来我的原始服务器(比如www.example.com)上有一个301redirect设置,将HTTP更改为HTTPS:

 HTTP/1.1 301 Moved Permanently Location: https://www.example.comhttp://img.dovov.comFoo_01.jpg 

但是,我的Origin协议策略被设置为仅HTTP。 这导致CloudFront找不到我的文件并引发502错误。 此外,我认为它caching了5分钟左右的错误502,因为它不能立即工作后,删除301redirect。

希望有所帮助!

在我们的例子中,一切看起来都不错,但大部分时间花在了这一点上:

TLDR:检查您的证书path以确保根证书是正确的。 在COMODO证书的情况下,应该说“USERTrust”,并由“AddTrust External CA Root”发布。 不是由“COMODO RSAauthentication机构”颁发的“COMODO”。

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

如果源服务器返回无效证书或自签名证书,或者源服务器以错误顺序返回证书链,则CloudFront将丢弃TCP连接,返回HTTP错误代码502,并将X-Cache标头设置为Error从云端。

我们按照以下方式启用了正确的密码: http : //docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomEncryption

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

SSL检查器结果没有所有必需的证书

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

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

这显然突然停止之前,工作了很长时间。 发生了什么是我刚刚更新了一年的证书,但是在导入期间,证书path中的所有以前的证书发生了一些变化。 他们都开始引用“COMODO RSA证书颁发机构”,而在此之前,链是更长的,根是“AddTrust外部CA根”。

错误的证书路径

因此,切换回较旧的证书没有解决的前沿问题。

我不得不删除名为“COMODO RSAauthentication机构”的额外证书,这个证书没有引用AddTrust。 这样做后,我的所有网站证书的path更新指向AddTrust / USERTrust再次。 注意还可以从path中打开坏根证书,点击“详细信息” – >“编辑属性”,然后以这种方式禁用它。 这立即更新了path。 您可能还需要删除在“个人”和“受信任的根证书颁发机构”下find的证书的多个副本

良好的证书路径

最后,我不得不重新selectIIS中的证书来获取新的证书链。

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

带有所有证书的SSL检查器

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

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

我刚刚解决了这个问题,在我的情况下,它确实与redirect有关,但与我的CloudFront Origin或Behavior中的错误设置无关。 如果您的原始服务器仍然redirect到原始url,而不是您为云端url设置的内容,则会发生这种情况。 似乎这是很常见的,如果你忘记改变configuration。 例如,假设您将www.yoursite.com CNAME添加到您的cloudfront发行版,并且源自www.yoursiteorigin.com。 显然人们会来www.yoursite.com。 但是如果你的代码试图redirect到www.yoursiteorigin.com上的任何页面,你将会得到这个错误。

对我来说,我的起源仍然在做http-> httpsredirect到我的原始url,而不是我的Cloudfronturl。

就我而言,这是因为我们有一个无效的SSL证书。 问题出在我们的舞台上,我们也使用我们的prod证书。 在过去的几年里,这个configuration已经工作了,但突然之间,我们开始出现这个错误。 奇怪。

如果其他人得到这个错误,请检查ssl证书是否有效。 您可以通过AWS CloudFront Distribution界面启用日志logging以帮助debugging。

此外,你可以在这里参考亚马逊的文档: http : //docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html

还有一个可能的解决scheme:我有一个登台服务器,通过HTTP为站点和Cloudfront资产提供服务。 我有我的起源设置为“匹配查看器”而不是“仅HTTP”。 我还使用HTTPS Everywhere扩展,将所有http://*.cloudfront.net URLredirect到https://*版本。 由于登台服务器不能通过SSL访问,Cloudfront与查看器匹配,因此无法在https://example.comfind资产,而是caching了一堆502。

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

通过连接我的证书来生成一个有效的证书链(使用GoDaddy Standard 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; 

希望能帮助到你!