HTTP とサーバーのエラー

このエラーカテゴリーについて

# HTTP とサーバーのエラー

HTTP エラーやサーバーエラーは、リクエストを正常に完了できないときに発生します。500、502、503、504 などの HTTP ステータスコードを返す障害もあります。一方、ブラウザが HTTP レスポンスを受け取る前に発生し、ERR_CONNECTION_REFUSED や ERR_CONNECTION_TIMED_OUT などのメッセージが表示される障害もあります。

ブラウザのメッセージが示すのは症状であり、対処が必要なコンポーネントを必ずしも示しているとは限りません。まず、ブラウザからネットワーク、ネットワークから待ち受け中のサービス、プロキシからバックエンド、アプリケーションから依存サービスのどの境界で失敗しているかを特定します。

まず障害の種類を特定する

HTTP ステータスコードが返された場合

数値のステータスコードは、HTTP に対応したコンポーネントが応答したことを意味します。そのコンポーネントは、アプリケーション自体ではなく、オリジン Web サーバー、リバースプロキシ、ロードバランサー、CDN のいずれかである可能性があります。

• 500 Internal Server Error: リクエストの処理中に、サーバーで予期しない状態が発生しました。まずアプリケーションと Web サーバーのログを確認します。[500 Internal Server Error の解説](/http-500-internal-server-error)も参照してください。
• 502 Bad Gateway: プロキシがバックエンドから無効、空、または利用できないレスポンスを受け取りました。バックエンドのプロセス、上流ホストとポート、プロキシとオリジン間の接続を確認します。[502 Bad Gateway の解説](/http-502-bad-gateway)も参照してください。
• 503 Service Unavailable: その時点でサービスがリクエストを処理できません。メンテナンスモード、容量不足、利用できないプロセス、依存サービスの障害などが考えられます。[503 Service Unavailable の解説](/http-503-service-unavailable)も参照してください。
• 504 Gateway Timeout: ゲートウェイがリクエストを転送したものの、タイムアウト時間が過ぎるまでにレスポンスを受け取れませんでした。バックエンドは稼働していても、処理が遅い、過負荷状態、または別のサービスを待機している可能性があります。[504 Gateway Timeout の解説](/http-504-gateway-timeout)も参照してください。

ステータスコードだけでは、どのレイヤーで障害が発生したかは判断できません。レスポンスのブランディング、ヘッダー、タイムスタンプ、ログを確認し、レスポンスがオリジンから返されたのか、中間コンポーネントから返されたのかを特定します。

ブラウザが接続エラーを報告する場合

接続レベルのエラーは、ブラウザが想定されたエンドポイントから通常の HTTP レスポンスを受け取れなかったことを意味します。

• ERR_CONNECTION_REFUSED: 宛先には到達しましたが、接続が拒否されました。想定されたポートでサービスが待ち受けているか、ローカルまたはネットワークのセキュリティルールがアクセスに影響していないかを確認します。開発環境については、[localhost での ERR_CONNECTION_REFUSED](/err-connection-refused-localhost)を参照してください。
• ERR_CONNECTION_TIMED_OUT: ブラウザが待機したものの、利用可能なレスポンスを受け取れませんでした。アプリケーションが生成した HTTP エラーを調べる前に、ネットワーク経路、ルーティング、フィルタリング、DNS、サーバーへの到達性、リソースの利用可能性を確認します。[ERR_CONNECTION_TIMED_OUT の解説](/err-connection-timed-out)も参照してください。

実践的な診断手順

1. 障害を再現して記録する

一度だけページを再読み込みし、その後、同じ URL をプライベートウィンドウまたは別のデバイスで試します。正確な URL、エラーテキスト、ステータスコード、おおよその発生時刻、表示されたレスポンスページを記録します。CDN やプロキシのブランディングがあるページが表示される場合、リクエストは中間コンポーネントまで到達した可能性があります。一般的なブラウザメッセージの場合は、利用可能な HTTP レスポンスが届かなかった可能性があります。

1 台のブラウザまたはデバイスだけで失敗する場合は、そのプロキシ、VPN、DNS キャッシュ、拡張機能、ローカルのセキュリティソフトを確認します。同じ URL が複数のデバイスやネットワークで失敗する場合は、サーバー、プロキシ、オリジン、または共有ネットワーク経路に原因がある可能性が高くなります。

2. 影響範囲を定義する

問題が 1 つのルート、1 つのホスト、アプリケーション全体、サービス全体のどこに影響しているかを確認します。

• 1 つのルートだけが失敗する場合は、アプリケーションコード、ルート固有の依存サービス、または遅いクエリが原因の可能性があります。
• すべてのルートで 500 が返る場合は、アプリケーションまたはサーバー設定のより広範な問題が考えられます。
• プロキシ全体で 502 または 504 が発生する場合は、オリジンのプロセス、上流接続、またはプロキシ設定を確認します。
• 1 つのポートで接続が拒否され、他のサービスは利用できる場合、想定されたサービスだけが待ち受けていない可能性があります。

可能であれば、正常に動作するエンドポイントと失敗するエンドポイントを比較します。ルーティング、認証、依存サービス、デプロイ状態の違いは、関係のないクライアント設定を変更するよりも有用な情報になることがあります。

3. レスポンスを生成したコンポーネントを確認する

500 の場合は、障害発生時刻とアプリケーションおよび Web サーバーのログを照合します。502、503、504 の場合は、プロキシまたはゲートウェイのログとバックエンドのログを両方確認します。停止したプロセス、失敗したデプロイ、依存サービスへの接続失敗、リソース不足、関連するタイムアウトを超えるリクエストがないか調べます。

ローカルで ERR_CONNECTION_REFUSED が発生した場合は、Apache または Nginx が実行中で、設定されたポートが利用可能かを確認します。XAMPP、Laragon、MAMP では、Web サーバーが起動していない場合や、別のプログラムが想定されたポートへのバインドを妨げている場合に、この症状が発生することがあります。

4. オリジンと依存サービスを個別にテストする

サービスを管理している場合は、プロキシ接続が成功したからといってアプリケーションが正常だと判断せず、バックエンドが接続を受け付け、単純なエンドポイントに応答するかを確認します。次に、データベースなどの必須サービスや、設定されているその他の依存サービスを確認します。

稼働していても一貫して遅いバックエンドは、停止しているバックエンドや利用できないレスポンスを返すバックエンドよりも 504 と整合します。後者は 502 の原因になる可能性があります。サービスが意図的に利用できない場合や、必要な依存サービスを利用できない場合は、アプリケーションのリクエストが処理される前に 503 が発生することがあります。

トラブルシューティングの方法として、繰り返しページを再読み込みするのは避けてください。根本のプロセス、依存サービス、タイムアウトの問題を調査している間に負荷を増やす可能性があります。

エラーの詳細からレイヤーを特定する

レスポンス本文、ヘッダー、タイムスタンプから、どのコンポーネントが障害を処理したかが分かることがあります。

• 一般的なブラウザメッセージは、通常、利用可能な HTTP レスポンスが受信されなかったことを示します。
• プロキシまたは CDN のブランディングがあるページは、中間コンポーネントがエラーを生成または表示したことを示します。
• アプリケーション固有のエラーページは、オリジンアプリケーションをより直接的に示している可能性があります。

断続的な障害の場合は、デプロイ、トラフィックの増加、プロセスの再起動、依存サービスのレイテンシーと発生時刻を照合します。継続的な障害の場合は、サーバー設定を変更する前に、正常なリクエストと失敗するリクエストを比較し、設定の違いを確認します。

Cloudflare を利用しているサイトでは、Cloudflare のブランディングが付いた 504 は通常、エッジが適用されるタイムアウト時間内にオリジンからレスポンスを取得できなかったことを意味します。[Cloudflare 配下での 504 Gateway Timeout の解説](/504-gateway-timeout-cloudflare)では、オリジンの問題と、別のゲートウェイまたはオリジン自体が生成したタイムアウトを切り分ける方法を説明しています。

サポートを依頼するときに含める情報

役立つ報告には、次の情報が含まれます。

• 正確なエラーテキストとステータスコード
• URL のパスとおおよその障害発生時刻
• 他のユーザー、デバイス、ネットワークにも影響しているかどうか
• プロキシ、CDN、ロードバランサーが関与しているかどうか
• 関連する Web サーバー、プロキシ、アプリケーションのログエントリ（パスワード、トークン、その他の秘密情報は削除する）

目的は、障害が発生している境界を特定することです。その境界が分かれば、ブラウザ、ネットワーク、プロキシ、バックエンドの原因を同一視せずに、関連するエラーガイドでより的確な確認を行えます。