これがそのことです：
バックエンドは標準のWebサーバーに基づいていないため、問題の解決策を探していません。ELBヘルスチェックシステムによって送信されているメッセージの種類を誰かが知っている場合でも、これに関するドキュメントが見つからないためです。 、 どこでも。
ヘルプは大歓迎です。ありがとうございました。
Amazon ELBには、カスタマイズ可能なヘルスチェックシステムがありますが、ここで説明するように、自動システムとしても機能します。
カスタマイズ可能では、おそらくAWSマネジメントコンソール（ヘルスチェック設定の設定を参照）またはAPI（ConfigureHealthCheckを参照）を介して設定可能なヘルスチェックを参照しています。
このように構成されたヘルスチェックに合格するための要件は、HealthCheckデータ型ドキュメントのフィールドターゲットに概説されています。
チェックするインスタンスを指定します。プロトコルは、TCP、HTTP、HTTPS、またはSSLのいずれかです。有効なポートの範囲は1〜65535です。
ノート
TCPがデフォルトであり、TCP：ポートペアとして指定されます（例：「TCP：5000」）。この場合、ヘルスチェックは、指定されたポートでインスタンスへのTCP接続を開こうとするだけです。設定されたタイムアウト内に接続に失敗すると、異常と見なされます。
SSLは、SSL：ポートペアとしても指定されます（例：SSL：5000）。
HTTPまたはHTTPSプロトコルの場合、状況は異なります。文字列にpingパスを含める必要があります。HTTPはHTTP：port;/;PathToPing;として指定されます。グループ化、たとえば「HTTP：80 / Weather / us / wa/seattle」。この場合、HTTP GETリクエストは、指定されたポートとパスのインスタンスに発行されます。タイムアウト期間内に「200OK」以外の回答は不健康と見なされます。
HTTP pingターゲットの全長は、1024個の16ビットUnicode文字以下である必要があります。
[強調鉱山]
自動では、おそらく、 「原因」の段落で説明されているヘルスチェックを参照していると思われます。ヘルスチェックのURLがAPIおよびコンソールに表示されるURLと異なるのはなぜですか。：
ロードバランサー用に構成したヘルスチェックに加えて、登録解除せずにインスタンスが終了することによって引き起こされる潜在的な副作用から保護するために、サービスによって2番目のヘルスチェックが実行されます。このチェックを実行するために、ロードバランサーはヘルスチェックが使用するように構成されているのと同じポートでTCP接続を開き、ヘルスチェックが完了した後に接続を閉じます。[強調鉱山]
ソリューションの段落では、ペイロードがゼロであることを明確にしています。つまり、上記の構成可能なヘルスチェックで説明した非HTTP/HTTPSメソッドに似ています。
この追加のヘルスチェックは、バックエンドインスタンスにデータを送信しないため、アプリケーションのパフォーマンスに影響を与えません。このヘルスチェックを無効またはオフにすることはできません。
組み込みのHTTPパーサーを備えたRESTfulAPIサーバーが実際にHTTPのみを提供することになっていると仮定すると、2つのヘルスチェックを処理する必要があります。
HTTP GET応答する必要があります。200 OK結論として、サーバーはすでに完全に正常に動作している可能性があり、2回目のヘルスチェックの動作にイライラしているようです。ELBは実際にサーバーが異常であると見なしていますか？
私の知る限り、これは200OKhttp応答を探すHTTPGETリクエストです。