Cloudfront 自定义来源分发返回 502“错误无法满足请求。” 对于某些网址
[英]Cloudfront custom-origin distribution returns 502 "ERROR The request could not be satisfied." for some URLs
问题描述
我们有一个自定义来源的 Cloudfront 发行版，它已经运行了很长时间，为我们的一个站点提供了 static 项资产。 就在今天早上，我们注意到我们的徽标显示为断开的链接。
经过进一步调查，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>
16 个解决方案
解决方案1
128 2014-05-12 00:33:36
我今天在使用 Amazon Cloudfront 时遇到了这个错误。 这是因为我使用的 cname（例如 cdn.example.com）没有添加到“alternate cnames”下的分发设置中，我只将 cdn.example.com 转发到我的站点/托管控制面板中的 cloudfront 域，但是您还需要将其添加到 Amazon CloudFront 面板。
解决方案2
35 已采纳 2014-04-28 19:04:58
我最近遇到了类似的问题，结果证明是由于我使用的 ssl_ciphers。
“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;
解决方案3
13 2013-12-18 20:23:08
找到我的答案并在此处添加，以防它对大卫（和其他人）有所帮助。
原来我的源服务器（比如 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 重定向后没有立即工作。
希望有帮助！
解决方案4
9 2015-06-04 03:01:41
在我们的例子中，一切看起来都很好，但花了一天的大部分时间才弄明白：
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来自云前线。
我们按照以下要求启用了正确的密码： 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 域验证安全服务器 CA”，由“COMODO RSA Certification Authority”颁发
CloudFront 似乎没有“COMODO RSA Certification Authority”的证书，因此认为源服务器提供的证书是自签名的。
这已经工作了很长时间，然后显然突然停止了。 发生的事情是我刚刚更新了当年的证书，但在导入期间，所有以前证书的证书路径中发生了一些变化。 他们都开始引用“COMODO RSA Certification Authority”，而在链更长且根为“AddTrust External CA Root”之前。
因此，切换回较旧的证书并没有解决云前问题。
我不得不删除名为“COMODO RSA Certification Authority”的额外证书，该证书没有引用 AddTrust。 执行此操作后，我所有网站证书的路径都更新为再次指向 AddTrust/USERTrust。 注意也可以从路径中打开错误的根证书，单击“详细信息”->“编辑属性”，然后以这种方式禁用它。 这立即更新了路径。 您可能还需要删除“个人”和“受信任的根证书颁发机构”下的多个证书副本
最后我不得不在 IIS 中重新选择证书才能让它为新的证书链提供服务。
完成这一切之后，ssl-checker 开始显示链中的第三个证书，该证书指向“AddTrust External CA Root”
最后，CloudFront 接受源服务器的证书和提供的链作为受信任。 我们的 CDN 又开始正常工作了！
为了防止将来发生这种情况，我们需要从具有正确证书链的机器上导出我们新生成的证书，即不信任或删除“COMODO RSA Certification Authority”颁发的证书“COMODO RSA Certification Authority”（2038年到期） ）。 这似乎只影响 Windows 机器，默认情况下安装此证书。
解决方案5
4 2015-06-15 22:22:47
另一种可能的解决方案：我有一个临时服务器，通过 HTTP 为站点和 Cloudfront 资产提供服务。 我将我的原点设置为“Match Viewer”而不是“HTTP Only”。 我还使用 HTTPS Everywhere 扩展，它将所有http://*.cloudfront.net URL 重定向到https://*版本。 由于暂存服务器无法通过 SSL 使用并且 Cloudfront 与查看器匹配，因此它无法在https://example.com找到资产，而是缓存了一堆 502。
解决方案6
2 2014-12-20 02:06:25
我刚刚解决了这个问题，就我而言，它确实与重定向有关，但与我的 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。
解决方案7
2 2015-01-23 22:02:07
就我而言，这是因为我们的 ssl 证书无效。 问题出在我们的暂存箱上，我们也使用我们的 prod 证书。 它在过去几年中一直使用这种配置，但突然间我们开始收到此错误。 奇怪。
如果其他人收到此错误，请检查 ssl 证书是否有效。 您可以通过 AWS CloudFront Distribution 接口启用日志记录到 s3 以帮助调试。
此外，您可以在此处参考亚马逊关于此事的文档： http : //docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html
解决方案8
1 2014-04-01 04:42:54
我遇到了这个问题，在我停止使用代理后它自己解决了。 也许 CloudFront 将一些 IP 列入黑名单。
解决方案9
1 2015-11-13 16:31:40
通过连接我的证书以生成有效的证书链（使用 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;
希望有帮助！
解决方案10
1 2018-07-06 22:02:57
就我而言，问题在于我同时使用 Amazon 的 Cloudflare 和 Cloudfront 的 Cloudfront，而 Cloudfront 不喜欢我提供的 Cloudflare 设置。
更具体地说，在 Cloudflare 的加密设置中，我将“最低 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：博士； 确保一切都接受并要求使用 TLS 1.2，或者在您阅读本文时每个人都在使用的任何最新最好的 TLS。
解决方案11
1 2020-07-13 15:32:31
对于我的特殊情况，这是因为我的 CloudFront Behavior 背后的 Origin ALB 有一个指向不同域名的 DEFAULT ACM 证书。
为了解决这个问题，我不得不：
- 前往 ALB
- 在侦听器选项卡下，选择我的侦听器，然后编辑
- 在默认 SSL 证书下，选择正确的源证书。
解决方案12
0 2018-02-22 08:50:22
就我而言，我使用 nginx 作为 API 网关 URL 的反向代理。 我有同样的错误。
当我将以下两行添加到 Nginx 配置时，我解决了这个问题：
proxy_set_header Host "XXXXXX.execute-api.REGION.amazonaws.com";
proxy_ssl_server_name on;
解决方案13
0 2018-04-09 22:16:52
在我们的案例中，我们已经放弃了对 SSL3、TLS1.0 和 TLS1.1 的支持，以在我们的源服务器上实现 PCI-DSS 合规性。 但是，您必须在 CloudFront 源服务器配置上手动添加对 TLS 1.1+ 的支持。 AWS 控制台显示客户端到 CF SSL 设置，但在您向下钻取之前不会轻松显示 CF 到源设置。 要修复，请在 CloudFront 下的 AWS 控制台中：
- 单击分发。
- 选择您的发行版。
- 单击“来源”选项卡。
- 选择您的源服务器。
- 单击编辑。
- 在“源 SSL 协议”下选择您的源支持的所有协议
解决方案14
0 2020-08-12 18:54:49
当心原始协议政策：
对于 CloudFront 转发到此源的 HTTPS 查看器请求，源服务器上 SSL 证书中的域名之一必须与您为源域名指定的域名匹配。 否则，CloudFront 会使用 HTTP 状态代码 502（错误网关）响应查看器请求，而不是返回请求的对象。
在大多数情况下，您可能希望 CloudFront 使用“仅 HTTP”，因为它也从可能由 Amazon 托管的服务器中获取对象。 在这一步不需要额外的 HTTPS 复杂性。
请注意，这与Viewer Protocol Policy 不同。 您可以在此处阅读有关两者之间差异的更多信息。
解决方案15
0 2021-12-21 17:16:39
确保您已正确配置 SSL/TLS/Cipher 设置。 如果您的源服务器未与正确的 TLS 密码握手，则 CloudFront 将断开 HTTPS 连接。
我推荐以下设置：
# Apache
SSLCipherSuite 'ECDHE+AES:@STRENGTH:+AES256'
SSLCipherSuite 'ECDHE+AES:DHE+AES:@STRENGTH:+AES256:kRSA+3DES'
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLProtocol all -SSLv3
SSLHonorCipherOrder on
# Nginx
ssl_ciphers 'ECDHE+AES:@STRENGTH:+AES256';
ssl_ciphers 'ECDHE+AES:DHE+AES:@STRENGTH:+AES256:kRSA+3DES';
ssl_protocols all -SSLv3 -TLSv1 -TLSv1.1;
ssl_protocols all -SSLv3;
ssl_prefer_server_ciphers on;
@STRENGTH 指令将按强度顺序对密码进行排序。
(apache) 上的 SSLHonorCipherOrder 和 (Nginx) 上的 ssl_prefer_server_ciphers 将确保遵守顺序。
您可以通过在 shell 上运行以下命令来查看您的 openssl 版本支持的可用密码的完整列表：
$ openssl ciphers -v 'ALL'
您还可以以类似的方式按强度顺序列出上述建议指令的可用密码：
$ openssl ciphers -v 'ECDHE+AES:@STRENGTH:+AES256'
如果您遇到此类问题，我强烈建议您增加 Web 服务器日志的详细程度，尤其是与 SSL 相关的日志。
在 Apache 中，您必须在 conf 文件中使用以下指令执行此操作
LogLevel debug
以下是可能的 Apache LogLevel 指令列表：
emerg (emergencies - system is unusable)
alert (action must be taken immediately)
crit (critical conditions)
error (error conditions)
warn (warning conditions)
notice (normal but significant condition)
info (informational)
debug (debug-level messages)
trace1 (trace messages)
trace2 (trace messages)
trace3 (trace messages)
trace4 (trace messages)
trace5 (trace messages)
trace6 (trace messages)
trace7 (trace messages, dumping large amounts of data)
trace8 (trace messages, dumping large amounts of data)
一般来说，调试足以让您识别协商问题（可能是密码问题，也可能是证书问题）
CloudFront 无法与源服务器成功协商 SSL 的典型反应如下所示：
[ssl:info] [pid 25091] [client xxx.xxx.xxx.xxx:15078] AH01964: Connection to child 1 established (server example.com:443)
[ssl:debug] [pid 25091] ssl_engine_kernel.c(2372): [client xxx.xxx.xxx.xx:15078] AH02043: SSL virtual host for servername example.com found
[ssl:debug] [pid 25091] ssl_engine_io.c(1368): (104)Connection reset by peer: [client xxx.xxx.xxx.xxx:15078] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[ssl:info] [pid 25091] [client xxx.xxx.xxx.xxx.15078] AH01998: Connection closed to child 1 with abortive shutdown (server example.com:443)
在这种情况下，Apache 通过“提示：在浏览器中按下停止按钮？！”来解释 CloudFront 断开连接。 是的，有点滑稽。
另一方面，CloudFront 可能是一个棘手的野兽。 如果您在分配中强制使用 HTTPS 或将 HTTP 定向到 HTTPS，则必须确保 CloudFront 和源服务器之间的通信通过具有有效 SSL 证书的有效 SSL 连接运行。 这可能意味着通过将证书链接到弹性负载均衡器 (ELB) 来通过 Amazon ACM 获取证书。
...或者您也可以通过将 ACM 证书链接到您的发行版来获得所需的结果（确保您同时列出了顶级域和子域，例如：example.com 和 *.example.com）。 这会将 ACM 证书传播到分发中的源/目标，但是，源服务器中的 Apache/Nginx 服务器必须具有有效且有效的 SSL 证书，即使它是由 Letsencrypt/Certbot（我们的其他一些有效的非自签名证书）。 确保在 apache *.conf 设置中配置了完整的链。
您可以阅读有关 502 错误网关或 502 无法满足来自 AWS的请求以及需要 HTTPS 以在 CloudFront 和您的自定义源之间进行通信的问题的更多信息（ 这也可能有所帮助）。 这些有关密码的信息以及AWS 上支持的密码列表非常有用
其中一些命令也可能对调试 SSL 情况很有用：
openssl s_client -connect test.example.com:443 -tls1_1
（您可以尝试使用 -tls1_2 、 -tls1_3 或其他协议）
您可能还想尝试使用 http 命令行工具（您可能必须安装它），它会为您提供如下输出：
$ http https://example.com --head
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 251
Content-Type: text/html; charset=iso-8859-1
Date: Mon, 20 Dec 2021 19:20:15 GMT
Location: https://example.com
Server: Apache
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
Via: 1.1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.cloudfront.net (CloudFront)
X-Amz-Cf-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
X-Amz-Cf-Pop: GIG51-C2
X-Cache: Miss from cloudfront
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
祝调试顺利，记住：继续深入挖掘，不要放弃，增加日志的冗长！
解决方案16
0 2023-01-13 15:35:09
就我而言，我没有配置 nginx 来侦听端口 80 并将其发送到节点应用程序的端口。
AWS - CloudFront 和 EC2 SSL 证书之间的错误 502 - 移动应用程序
[英]AWS - Error 502 between CloudFront and EC2 SSL certificate - Mobile App
某些请求的 Apache https 请求状态未决并返回 502 状态
[英]Apache https request status pending for some requests and 502 status is returned
尝试通过Cloudfront在EC2实例上设置SSL时出现502错误
[英]Getting 502 error when trying to set up SSL on EC2 instance via Cloudfront
如何在Cloudfront之间将SSL设置为具有EC2自定义来源的反向代理缓存？
[英]How to set SSL between cloudfront as a reverse proxy cache with an EC2 custom origin?
CloudFront 分配和 AWS 颁发的证书提供 SSL_ERROR_NO_CYPHER_OVERLAP
[英]CloudFront distribution and AWS issued certificate gives SSL_ERROR_NO_CYPHER_OVERLAP
通过SSL通过HttpWebRequest发送请求时出现错误502（错误网关）
[英]Error 502 (Bad Gateway) when sending a request with HttpWebRequest over SSL
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
相关问题
502错误：CloudFront无法连接到源
Cloudfront Distribution：从自定义域发送
将 AWS cloudfront 放在 ec2 前面会引发 502 错误
Cloudfront 返回 502 错误
AWS - CloudFront 和 EC2 SSL 证书之间的错误 502 - 移动应用程序
某些请求的 Apache https 请求状态未决并返回 502 状态
尝试通过Cloudfront在EC2实例上设置SSL时出现502错误
如何在Cloudfront之间将SSL设置为具有EC2自定义来源的反向代理缓存？
CloudFront 分配和 AWS 颁发的证书提供 SSL_ERROR_NO_CYPHER_OVERLAP
通过SSL通过HttpWebRequest发送请求时出现错误502（错误网关）
相关标签