502、503、504 エラー: それぞれの実際の意味

502、503、および 504 はすべて、大まかに「現時点ではサーバーが本当の答えを提供できませんでした」という意味なので、互いに混同されることがよくあります。ただし、コードごとに問題の絞り込み方が異なるため、数値を正しく読み取ることで、間違ったレイヤーのトラブルシューティングにかかる​​時間を節約できます。

簡単な違い

• 502 Bad Gateway — ゲートウェイまたはプロキシとして機能するサーバーが、その背後のサーバーから 無効な 応答を受け取りました。
• 503 Service Unavailable — サーバーは稼働していますが、現在リクエストの処理を意図的に拒否しています (過負荷またはメンテナンス中)。
• 504 ゲートウェイ タイムアウト — ゲートウェイまたはプロキシとして機能するサーバーが、制限時間内に背後のサーバーから応答を *得られませんでした。

パターン: 502 と 504 には両方とも 2 つのサーバー (前にプロキシ/ロード バランサー/CDN、その後ろにアプリケーション サーバー) が含まれます。 503 は通常、準備ができていないことを直接通知する 1 つのサーバーにすぎません。

502 不正なゲートウェイ

何が起こっているのか: リバース プロキシ、ロード バランサー、または CDN (ゲートウェイとして機能する Cloudflare や Nginx など) がリクエストを実際のアプリケーション サーバーに転送し、理解できない応答、または不正な応答を返しました。沈黙ではなく、実際には壊れた応答です。

一般的な原因:

• アプリケーション サーバー (ノード、PHP-FPM、バックエンド プロセス) がリクエスト中にクラッシュまたは再起動しました。
• 誤って設定されたリバース プロキシが間違ったポートまたはアドレスを指している。
• バックエンドが基本的な HTTP 形式に違反する応答を返しました。
• サイトの前の CDN または WAF が正しく構成されておらず、正当なバックエンド応答を拒否しています。

自分のサイトであるかどうかを確認する必要があります: アプリケーション サーバーのログを調べて、エラー発生時刻付近でクラッシュまたは再起動が発生していないかどうかを確認します。リバース プロキシ構成 (nginx proxy_pass、ロード バランサー ターゲットなど) が、予想されるポートで実際に実行されているバックエンドを指していることを確認します。

503 サービスが利用できません

何が起こっているのか: サーバーはリクエストを正常に受信しましたが、現在リクエストを処理できないことを明示的に伝えています。 502/504 とは異なり、これは通常は意図的です。プロキシが背後にあるものについて文句を言うのではなく、サーバーが独自の状態を示します。

一般的な原因:

• 計画されたメンテナンス - 多くのプラットフォームは、展開または更新中に意図的に 503 を返し、多くの場合、Retry-After ヘッダーが付きます。
• 過負荷 — サーバーの容量に対して同時リクエストが多すぎます。トラフィックの急増時 (セール、バイラル投稿、DDoS) によく見られます。
• リソースの枯渇 — サーバーは、新しいリクエストを処理するためのメモリ、データベース接続、またはワーカー プロセスを使い果たしました。
• レート制限 - クライアント (またはアップストリーム サービス) がリクエストを送信する速度が速すぎる場合、一部のセットアップは 429 ではなく 503 を返します。

自分のサイトであるかどうかの確認事項: デプロイ中にこの問題が発生した場合は、数秒から数分以内に自動的に解決される可能性があります。問題が解決しない場合は、サーバー リソースの使用状況 (CPU、メモリ、接続プールの制限) と、起動に失敗したワーカーまたは強制終了されたワーカーがないかプロセス マネージャーのログを確認してください。

504 ゲートウェイのタイムアウト

何が起こっているのか: 502 と同じ 2 サーバー設定ですが、プロキシはバックエンドから壊れた応答を取得する代わりに、割り当てられた待機時間内に何も取得しませんでした。これは、プレーン接続タイムアウトの「ゲートウェイ」の兄弟です。

一般的な原因:

• バックエンドがリクエストを処理するのに時間がかかりすぎる - 遅いデータベース クエリ、最適化されていないスクリプト、またはそれ自体が遅いか停止している依存関係 (API、サードパーティ サービス)。
• クラッシュしていないにもかかわらず、バックエンドが過負荷になり、応答が間に合わなくなっています。
• 大きなファイルのアップロードや大量のレポートの生成など、正当に遅い (ただし動作​​する) 操作に対してプロキシ タイムアウト設定が強すぎる。

自分のサイトかどうかの確認事項: プロキシをバイパスして、遅いエンドポイントを直接プロファイリングして、バックエンド自体が遅いのか、それとも問題が純粋にプロキシ層にあるのかを確認します。特定の依存関係 (データベース、外部 API) が低下しているかどうかを確認します。これは、バックエンドが完全にクラッシュするのではなく、バックエンドが遅くなる最も一般的な根本原因であるためです。

それはあなたですか、それとも彼らですか?

これら 3 つはすべて、定義上サーバー側のエラーです。ブラウザ、DNS、ローカル ネットワークが原因ではないため、ERR_CONNECTION_TIMED_OUT や DNS_PROBE_FINISHED_NXDOMAIN] などの問題とは明確に区別されます。 502、503、または 504 が表示されている場合、修正 (修正できるものがある場合) がお客様側で行われることはほとんどありません。一時的な 503 では更新が機能する場合がありますが、永続的なものではサイトが解決するのを待つだけです。

それがあなただけではないことを確認するには、一部の CDN または地域エッジ ノードでは、時々不正なゲートウェイ エラーが発生しますが、他のノードは正常です。独立ステータス チェック] を通じてサイトを実行し、同じビューで応答時間と SSL ステータスとともに、独自のネットワーク外のサーバーからのライブ HTTP ステータス コードを確認します。