我有一个 AWS Elastic beanstalk 环境，它可以从 2 到 3 个配置有应用程序负载均衡器的实例进行扩展。负载均衡器配置了 HTTP 运行状况检查以寻找 200 响应。
当环境自动扩展到 3 个实例时，新实例在准备好之前就开始接收流量。如果我手动检查运行状况检查 URL，我可以看到 3 次中有 1 次返回 404，因为新实例尚未准备好。应用程序的其他 URL 也出错，3 次中有 1 次是因为它们不存在。
据我了解，健康检查 URL 的全部意义在于处理这个问题。那么，请问是什么原因造成的？
一些可能相关的信息：
- 该实例需要很长时间才能准备就绪，因为它是一个需要安装 ARR 的 ASP.Net 应用程序。
- 在增强的运行状况检查概述中，两个工作实例被列为“严重”，即使它们工作正常。他们列出了几个 5xx 错误，我不知道为什么，因为发送给他们的流量很少，它占流量的很大比例。奇怪的是，未准备好的新实例被标记为“Ok”。我不认为增强的健康检查决定负载均衡器何时认为实例健康，但也许我不正确？
- 当我尝试联系 AWS 支持时，代理向我发送了大量有关不可变环境更新和滚动更新的信息。据我了解，这与在进行配置更改或新部署时如何使新实例联机有关，这与负载平衡健康检查和自动缩放不同，因此不相关。但是，也许我误解了，代理没有设法说明为什么这与这种情况有关。
当您碰巧通过平衡器访问其中一个节点时，健康检查 URL 对健康节点起作用这一事实不一定与平衡器访问它以进行健康检查时健康检查 URL 正常工作相同。
现代 HTTP 版本要求
Host每个传入请求中都存在标头，并且平衡器会将 HTTP 主机标头设置为实例的私有 IP 地址以进行健康检查请求，但将通过浏览器在正常请求中设置的值 - 和您的浏览器将相同的标头设置为您用于访问平衡器的主机名。如果您（和您的服务器/框架/应用程序）没有考虑到这一点，并且您的服务器以不同的方式对待它们，那么您的所有实例实际上可能一直未能通过它们的健康检查，尽管您在尝试它们时手动检查工作正常。当“所有目标都不健康”的情况发生时，ALB 假设最安全的做法是将流量转发到所有实例，就好像它们都是健康的（故障安全但不一定直观的设计），这将准确解释您所看到的情况。