502 Bad Gatewayとは？原因と解決方法をわかりやすく解説
与謝秀作
Webサイトを閲覧しているとき、突然「502 Bad Gateway」というエラー画面が表示された経験はないでしょうか。このエラーはサイト訪問者だけでなく、サイト運営者やマーケティング担当者にとっても深刻な問題です。本記事では、502 Bad Gatewayの意味から原因の特定方法、具体的な解決策までをわかりやすく解説します。
502 Bad Gatewayとは
502 Bad Gatewayは、HTTPステータスコードの一つで、ゲートウェイやプロキシとして機能しているサーバーが、上流のサーバーから無効なレスポンスを受け取ったことを示すエラーです。簡単に言えば、中継役のサーバーが「バックエンドのサーバーから正しい応答をもらえなかった」という状態を意味します。
たとえば、ユーザーがWebサイトにアクセスすると、リクエストはまずロードバランサーやリバースプロキシ（NginxやCloudflareなど）を経由し、その後ろにあるアプリケーションサーバーに転送されます。このとき、バックエンド側のサーバーがダウンしていたり、応答に時間がかかりすぎたりすると、中継サーバーが502エラーを返します。
502 Bad Gatewayのよくある原因
502エラーの原因は多岐にわたりますが、大きく分けるとサーバー側の問題、ネットワーク側の問題、そしてクライアント側の問題に分類できます。
サーバー側の原因
最も多い原因はバックエンドサーバーの過負荷やダウンです。アクセスが急増してアプリケーションサーバーが処理しきれなくなった場合や、サーバーのメモリ不足、PHPやNode.jsなどのアプリケーションプロセスがクラッシュした場合に発生します。また、サーバーのメンテナンスや再起動のタイミングでも一時的に502エラーが出ることがあります。
WordPressなどのCMSを利用している場合、プラグインの不具合やPHPのバージョン不整合が原因になるケースも少なくありません。
ネットワーク側の原因
ロードバランサーやCDN（コンテンツデリバリーネットワーク）の設定ミスも502エラーの原因になります。リバースプロキシのタイムアウト設定が短すぎる場合、バックエンドが応答を返す前に接続が切れてしまい、502が発生します。DNSの設定変更直後に一時的にエラーが出ることもあります。
ファイアウォールやセキュリティソフトがバックエンドサーバーへの通信をブロックしているケースも確認すべきポイントです。
クライアント側の原因
502 Bad Gatewayはサーバー側のエラーですが、まれにブラウザのキャッシュや拡張機能が原因で表示される場合があります。古いキャッシュデータが残っていたり、特定のブラウザ拡張がリクエストを変更してしまったりするケースです。
サイト訪問者としての解決方法
502 Bad Gatewayに遭遇した場合、サイト訪問者の立場で試せる対処法をいくつか紹介します。
ページを再読み込みする
502エラーは一時的なものであることが多いため、まずはページをリロードしてみましょう。数秒から数分待ってから再度アクセスすると解消されている場合があります。
ブラウザのキャッシュをクリアする
古いキャッシュが原因の可能性がある場合は、ブラウザのキャッシュとCookieをクリアしてから再度アクセスしてみてください。シークレットモード（プライベートブラウジング）で開いてみるのも有効な確認方法です。
別のブラウザやデバイスで試す
特定のブラウザや拡張機能が原因かどうかを切り分けるために、別のブラウザやスマートフォンからアクセスしてみましょう。別の環境でも同じエラーが出る場合は、サーバー側の問題である可能性が高くなります。
DNSサーバーを変更する
DNSの問題が疑われる場合は、Google Public DNS（8.8.8.8）やCloudflare DNS（1.1.1.1）など、別のDNSサーバーに切り替えてアクセスしてみてください。
サイト運営者としての解決方法
自社サイトで502 Bad Gatewayが発生した場合、以下のステップで原因を特定し、対処していきます。
サーバーのステータスとログを確認する
まず、バックエンドサーバーが正常に稼働しているかを確認します。Webサーバー（NginxやApache）のエラーログ、アプリケーションのログ、システムのリソース使用状況（CPU・メモリ・ディスク）をチェックしましょう。多くの場合、ログにエラーの直接的な原因が記録されています。
アプリケーションプロセスを再起動する
PHP-FPM、Node.js、Pythonなどのアプリケーションプロセスがクラッシュしている場合は、プロセスの再起動で復旧できることがあります。WordPressの場合はPHP-FPMの再起動、Railsアプリの場合はPumaやUnicornの再起動などが該当します。
タイムアウト設定を見直す
Nginxのproxy_read_timeoutやproxy_connect_timeoutの値が短すぎると、バックエンドの処理が完了する前にタイムアウトしてしまいます。重い処理が必要なページ（レポート生成や大量データの取得など）がある場合は、タイムアウト値の調整を検討しましょう。ただし、むやみに値を大きくするのではなく、アプリケーション側のパフォーマンス改善も並行して行うことが重要です。
CDNやロードバランサーの設定を確認する
CloudflareやAWS ALBなどのCDN・ロードバランサーを利用している場合、オリジンサーバーへの接続設定やヘルスチェックの設定を確認しましょう。オリジンサーバーのIPアドレスやポート番号が正しいか、SSL設定に不整合がないかもチェックポイントです。
サーバーリソースを増強する
アクセス増加が原因で502エラーが頻発する場合は、サーバーのスペックアップやオートスケーリングの導入を検討しましょう。クラウド環境（AWS、GCPなど）であれば、トラフィックに応じてサーバー台数を自動的に増減できるため、突発的なアクセス増にも対応できます。
502 Bad Gatewayを予防するためのベストプラクティス
502エラーは事後対応だけでなく、事前の予防が重要です。以下のポイントを押さえておくと、エラーの発生頻度を大幅に下げられます。
サーバー監視を導入することで、CPU・メモリ・ディスク使用率やアプリケーションの応答時間を常時モニタリングし、異常を早期に検知できます。UptimeRobotやDatadogなどの外部監視ツールを活用すれば、ダウンタイムの発生時にアラートを受け取れるため、迅速な対応が可能です。
キャッシュ戦略の最適化も効果的です。CDNやページキャッシュを適切に設定することで、バックエンドサーバーへのリクエスト数を減らし、サーバー負荷を軽減できます。静的コンテンツ（画像、CSS、JavaScript）はCDN経由で配信し、動的ページにもキャッシュを活用することで、アクセス集中時の耐性が高まります。
冗長構成の採用も重要な予防策です。単一のサーバーに依存する構成では、そのサーバーがダウンすると即座にサイト全体が停止します。ロードバランサーを介して複数のサーバーにトラフィックを分散し、1台がダウンしても残りのサーバーでサービスを継続できる構成にしておきましょう。
定期的なアップデートとメンテナンスも欠かせません。OS、Webサーバー、アプリケーション、CMSやプラグインを最新の状態に保つことで、既知の不具合による502エラーを防げます。メンテナンス時にはメンテナンスページ（503レスポンス）を表示するように設定し、502エラーがユーザーに表示されないようにすることも大切です。
502エラーがSEOに与える影響
502 Bad Gatewayが短時間で解消される場合、検索エンジンへの影響は限定的です。Googleのクローラーは一時的なサーバーエラーに対して再クロールを試みるため、数時間程度の障害であればインデックスや検索順位に大きな影響はありません。
しかし、502エラーが長時間（数日以上）続いたり、頻繁に発生したりすると話は変わります。クローラーがページにアクセスできない状態が続くと、該当ページがインデックスから一時的に除外される可能性があります。また、ユーザー体験の悪化はサイトの信頼性評価にも影響し、間接的に検索順位に悪影響を与えるリスクがあります。
サイト運営者はGoogle Search Consoleの「クロール統計情報」を定期的に確認し、サーバーエラーの発生頻度をモニタリングすることをおすすめします。
まとめ
502 Bad Gatewayは、中継サーバーがバックエンドから正常な応答を得られなかったときに発生するエラーです。原因はサーバーの過負荷やプロセスのクラッシュ、ネットワーク設定のミス、タイムアウト設定の不備など多岐にわたります。サイト訪問者はページのリロードやキャッシュクリアで解消できる場合がありますが、サイト運営者はサーバーログの確認、プロセスの再起動、タイムアウト設定の見直し、リソースの増強といった対策が必要です。また、サーバー監視の導入、キャッシュ戦略の最適化、冗長構成の採用、定期メンテナンスを通じて502エラーを予防し、安定したサイト運営と健全なSEOパフォーマンスを維持していきましょう。
