首页 文章

对于某些URL，Cloudfront自定义源分发返回502“ERROR请求无法满足 . ”

提问于
浏览 次
62

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

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

错误无法满足请求 . 由cloudfront生成（CloudFront）

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

其他一些数据点：

  • origin URLs工作得很好 . 据我所知，最近没有服务中断 .

  • 我特意使徽标URL无效，无效 .

  • 我已使分发的根URL无效，无效 .

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

UPDATE:

以下是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

12 回答

  • 1

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

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

    回复于
  • 0

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

    结果我的原始服务器（比如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重定向后没有立即工作 .

    希望有所帮助！

    回复于
  • 7

    在我们的例子中，所有内容都很好看，但是大部分时间都花了很多时间来解决这个问题：

    TLDR: 检查证书路径以确保根证书正确无误 . 对于COMODO证书，它应该说"USERTrust"并由"AddTrust External CA Root"发布 . 不"COMODO"由"COMODO RSA Certification Authority"发布 .

    来自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证书颁发机构”的证书，因此认为源服务器提供的证书是自签名的 .

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

    Bad certificate path

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

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

    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机器，默认情况下安装此证书 .

    回复于
  • 2

    我刚刚解决了这个问题，在我的情况下，它确实与重定向有关，但与我的CloudFront Origin或Behavior中的错误设置无关 . 如果您的源服务器是 still redirecting to origin URLs, and not what you have set up for your cloudfront URLs ，则会发生这种情况 . 如果您忘记更改配置，这似乎很常见 . 例如，如果您有www.yoursite.com CNAME到您的Cloudfront分发版，请访问www.yoursiteorigin.com . 显然人们会来www.yoursite.com . 但是，如果您的代码尝试重定向到www.yoursiteorigin.com上的任何页面，您将收到此错误 .

    对我来说，我的起源仍然是http-> https重定向到我的原始URL而不是我的Cloudfront URL .

    回复于
  • 2

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

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

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

    回复于
  • 2

    还有一个可能的解决方案：我有一个通过HTTP服务站点和Cloudfront资产的登台服务器 . 我的原点设置为"Match Viewer"而不是"HTTP Only" . 我还使用HTTPS Everywhere扩展，它将所有 http://*.cloudfront.net URL重定向到 https://* 版本 . 由于登台服务器在 https://example.com 找不到资产，而是缓存了一堆502s .

    回复于
  • 0

    在我们的案例中，我们已经放弃了对原始服务器上的PCI-DSS合规性的SSL3，TLS1.0和TLS1.1的支持 . 但是， you have to manually add support for TLS 1.1+ on your CloudFront origin server config . AWS控制台显示客户端到CF的SSL设置，但在向下钻取之前不会轻易显示CF到源的设置 . 要修复，请在CloudFront下的AWS控制台中进行修复：

    • 单击DISTRIBUTIONS .

    • 选择您的发行版 .

    • 单击“原点”选项卡 .

    • 选择原始服务器 .

    • 点击编辑 .

    • 在"Origin SSL Protocols"下选择原始支持的所有协议

    回复于
  • 0

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

    回复于
  • 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;

    希望能帮助到你！

    回复于
  • 30

    就我而言，我使用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

    回复于
  • 124

    在我看来，问题在于我正在使用亚马逊的Cloudflare和Cloudfront的Cloudfront，而Cloudfront并不喜欢我提供Cloudflare的设置 .

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

    要解决此问题，我必须在该Cloudfront分发的Origin Settings中禁用SSLv3支持，并启用TLS 1.2作为该源服务器的受支持协议 .

    为了调试这个问题，我使用curl的命令行版本来查看当你从CDN请求图像时Cloudfront实际返回的内容，并且我还使用了命令行版本的openssl，确定Cloudflare提供的确切协议（它不提供TLS 1.0） .

    TL：博士;确保一切都接受并要求TLS 1.2，或者在您阅读本文时所有人使用的最新和最好的TLS .

    回复于

相关问题