对于某些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。
“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检查链中的最后一个证书是由“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”
最后，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;
希望能帮助到你！
