根据https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.healthstatus.html，Web服务应以200 OK HTTP状态代码进行响应，以发出运行状况良好的应用程序信号，或发出其他任何状态不正常的信号。
我的问题是哪种HTTP状态最适合不健康的应用程序？
以下所有HTTP状态类中的
1xx Informational response 2xx Success 3xx Redirection 4xx Client errors 5xx Server errors 简单的逻辑表明，这应该是服务器错误，而不是其他任何错误，并且在所有5xx Server errors代码503 Service Unavailable中最自然地适合，但是我找不到任何支持此错误的文档。
答案 0 :(得分：1)
我的问题是哪种HTTP状态最适合不健康的应用程序？
503 Service Unavailable或较低级别的TCP RST是服务宣布其当前不可用的完全令人满意的方法。如果您想建议一个等待时间，可以使用Retry-After。我还没有看到任何文档表明ELB客户端会尊重该标头。
GCP和Azure相似； 200健康，其他没有。 Azure文档建议使用500 Internal Server Error作为可能的候选者，这当然很好（Y00是所有Yxx代码的粗粒度近似值）。
Consul checks的协议与此类似-2xx表示健康，429 Too Many Requests表示警告（这是一个很奇怪的选择），其他则表示失败。
我不太喜欢使用Client Error来描述什么是服务器问题；但我不知道这真的会伤害任何人。 Retry-After的语义实际上仅针对3xx和429/503进行了明确定义，因此，如果您希望利用它，则应将自己限制在这些代码中。
否则，您可以深入研究status code registry，看看是否有您认为更合适的代码。