さて、これがシナリオです。API リクエストを NGINX サーバーに送信すると、バックエンド サーバーを指すターゲットを持つ AWS Elastic Load Balancer にリダイレクトされます。バックエンド サーバーはリクエストを処理し、レスポンスを返します。異常なことは何もありませんよね？
なんらかの理由で、特定の API リソースからの POST リクエストが 403 で終了することがあります。プロキシ サーバーのログ (/var/log/nginx/access.log) で、403 が返されていることがわかります。ロード バランサのログ (アクセス ログ、S3 への書き込み) にも 403 と表示されます。ただし、バックエンド サーバー (catalina.out) には、リクエストが到着したことを示すログはまったくありません。これにより、ロード バランサーが何らかの理由で一部のリクエストを破棄し、バックエンドに到達しないと思われます。もちろん、これは表面レベルの仮定にすぎません。リクエストがどこでスタック/破棄されているのか本当にわかりません。
403 のシナリオでは、リクエストが 403 を返すのに 60 ミリ秒未満しかかからないことに注意してください。200 が返される場合、通常は約 250 ミリ秒かかります。そのため、ロード バランサーはバックエンド サーバーにそれを持ち込もうともせず、どこかで 403 を想定しているようです。
問題を特定するのがさらに難しくなるため、断続的であることは問題をさらに悪化させるだけです。
私たちは実際に最新の Application Load Balancer への移行を試みましたが、しばらくの間、問題は煮詰められていました。しかし、更新されたロード バランサーを使用しても、断続的な 403 が再び発生するようになりました。
この問題はほぼ 1 年前のものですが、403 Forbidden の可能性を 0% 近くにする解決策はまだ見つかっていません。
ここで完全に途方にくれました。任意のアイデアをいただければ幸いです。