当我们使用经典负载均衡器在已退役的Tomcat 8 上运行 Java 8 时，我们从未见过 HTTP 5xx 错误。
该平台已停用，因此我们创建了一个新环境“Tomcat 8.5，Corretto 11 在 64 位 Amazon Linux 2/4.1.3 上运行”，在此过渡期间，我们从 AWS Classic Load Balancer 迁移到了更新的Application Load Balancer。
从那以后，除了两个例外，一切都运行得非常顺利
1 - 引用 myapp.com//rest/something 的任何 URL 都失败（需要删除双斜杠，我不确定为什么这突然成为一个问题 - 但它已通过仅影响我们 UAT 测试的简单代码调整解决）
2 - 我注意到CloudFront 门户中显示了一堆HTTP 5xx 错误。这就是我在这个问题中所关注的。
您会注意到也有 2xx 响应，因此这排除了有关 SSL 配置不正确的最常见问题 - 我预计它们都会失败，而不是 50%。
我看到 2-4% 的错误率，我假设从流行对象表中它们都与深层链接相关。
我已经验证通过浏览器（和 curl）访问深层链接文件，页面返回 HTTP 200 状态。我已经尝试通过 CDN 并使用 AWS 公共弹性 beanstalk URL 直接连接到负载均衡器。
我已经看到有关错误配置 SSL 可能导致这些 502 错误的报告，但是我为不同的 URL 路径设置了多种行为，它们都使用相同的 SSL 证书。此外，您可以从第一个屏幕截图中看到，大约 50% 的请求命中缓存，其中 4,300 个是 HTTP 成功 2xx。
我已经使缓存失效，并且在 5-10 分钟后速率没有变得更糟，所以我必须得出结论，CDN 和源通信良好，至少有一半的时间。
我还看到有关服务器端重定向（HTTP 301）可能导致来自 CloudFront 的 HTTP 5xx 的报告，但我已经验证了对于深层链接 URL（例如 apple-app-site-association）它是静态 HTML文件，没有重定向过滤器妨碍。
我尝试比较 CloudFront 日志以比较那些具有 HTTP 2xx 和 5xx 响应的日志，但没有明显的模式可以解释它。例如，我看到相同 SSL 协议/密码的错误和成功（虽然我不太了解这个领域！），下面只是每个 HTTP 响应类别中的几个示例
502
13: 2020-12-27 00:00:03 AMS54-C1 1304 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /apple-app-site-association 502 - swcd%20(unknown%20version)%20CFNetwork/1126%20Darwin/19.5.0 - - Error TC10VGvkak58IlwqwCXpG9_GiR3HZR5vaouaC3AhiU6U5vFKbItI5g== mycompany.com https 230 0.073 - TLSv1.3 TLS_AES_128_GCM_SHA256 Error HTTP/1.1 - - 54519 0.073 OriginConnectError text/html 951 - -
50: 2020-12-27 00:00:05 WAW50-C1 1304 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /.well-known/apple-app-site-association 502 - swcd%20(unknown%20version)%20CFNetwork/976%20Darwin/18.2.0 - - Error lCjWcds-6t1jOt1GI1mII-7DoPVKEE8mIxtT5sGZpWN7vj6t2gqBcQ== mycompany.com https 241 0.096 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Error HTTP/1.1 - - 63785 0.095 OriginConnectError text/html 951 - -
51: 2020-12-27 00:00:05 WAW50-C1 1312 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /apple-app-site-association 502 - swcd%20(unknown%20version)%20CFNetwork/976%20Darwin/18.2.0 - - Error g8Zj46gI3HMK3KJehze1u9WYMlxCl8dlIjc3vZFat-Jx3HmZD_I17w== mycompany.com https 229 0.050 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Error HTTP/1.1 - - 63785 0.050 Error text/html 951 - -
200 的
23: 2020-12-27 00:00:08 LHR3-C2 598 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /.well-known/apple-app-site-association 200 - swcd%20(unknown%20version)%20CFNetwork/1128.0.1%20Darwin/19.6.0 - - Hit tdbpQ0zxszX4y70H9vniecKe9HP3xwd_KeI5SjrlckgrKNgsTJJFdA== www.mycompany.com https 250 0.001 - TLSv1.3 TLS_AES_128_GCM_SHA256 Hit HTTP/1.1 - - 10372 0.001 Hit - 193 - -
45: 2020-12-27 00:00:11 AMS54-C1 599 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /.well-known/apple-app-site-association 200 - swcd%20(unknown%20version)%20CFNetwork/1126%20Darwin/19.5.0 - - Hit QpbX2mGlhzXZR1gBC-HaZfBA-q5VWUC6t4NQgb6w3At4sCGhIz8ihQ== www.mycompany.com https 246 0.001 - TLSv1.3 TLS_AES_128_GCM_SHA256 Hit HTTP/1.1 - - 54526 0.001 Hit - 193 - -
53: 2020-12-27 00:00:07 WAW50-C1 599 [ip-redacted] GET d2yrbvancsuyx.cloudfront.net /.well-known/apple-app-site-association 200 - swcd%20(unknown%20version)%20CFNetwork/976%20Darwin/18.2.0 - - Hit UjQtTqnrlVbupxZmXj8RxwwISCfXgJ8viMD38vvEYXdmO-UWcFjk3A== www.mycompany.com https 245 0.002 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/1.1 - - 63787 0.002 Hit - 193 - -
当我启动我们的应用程序时，深层链接 URL 正在被正确处理；启动应用程序并按预期呈现详细信息，而不是显示浏览器。我什至删除了该应用程序并从应用程序商店重新安装它，并且深度链接已按预期注册。
弹性 beanstalk 已使用 Apache HTTP 服务器（而不是 NGINX）进行设置，它托管在欧洲/爱尔兰，带有 SSL 证书以匹配 *.mycompany www.mycompany 和其他一些子域。我可以使用弹性 beanstalk 公共 URL 直接访问它并给出证书警告，但这是可以预期的，因为证书是针对 mycompany 而不是针对 mycomapny.eu-west-1.elasticbeanstalk.com - 检查证书显示它是有效的（未过期）并且对于域 mycompany.com，我已将其添加到我的信任存储中以继续查看文件 - 它按预期返回 HTTP 200。
不幸的是，CloudFront CDN 没有引用 AWS EU/Ireland SSL 证书的选项，因此我使用 AWS 证书管理器 (ACM) 通过美国/东部（北弗吉尼亚）生成 SSL 证书。
CloudFront 在内部从源检索数据并设置为使用适当的 HTTP 或 HTTPs，然后它将使用欧盟/爱尔兰 SSL 证书访问源。
就像我说的，这一切都适用于所有其他 CDN 行为，但出于某种原因，流行对象表中显示 5xx（我相信都是 502 错误）仅适用于深度链接文件。
应用程序日志没有显示任何问题，但我认为它们甚至没有到达原点，因此出现 5xx 错误。
有谁知道我如何通过 CloudFront --> Application Load Balancer --> Apache --> Our static HTML pages 解决 5xx 错误？
需要明确的是，当我们使用 CloudFront --> CLASSIC Load Balancer时，我们没有看到这个问题。
这些行为都和以前一样，我所做的只是将新源添加到 CloudFront 分配，然后更改每个行为以引用新源。
仅供参考，我确实注意到 AWS 中存在一个错误，在编辑行为期间它清除了列入白名单的标头，因此我不得不重新选择“主机”，否则该页面出现验证错误“使用带有 ELB 来源的 SSL，转发所有标头或将 Host 标头列入白名单。如果您不想转发任何标头，请将源协议策略更改为仅 HTTP。