「さっきまで見られていたページが急に502エラーに……どうすればいいの？」
「サーバー管理しているのに、何度再起動しても直らないんです……」
「Webサイトの訪問者から『Bad Gateway』って言われて焦っています！」
こんな経験、ありませんか？
- ページのリロードを繰り返してもエラーが消えない
- サーバー側に問題がありそうだけど原因がわからない
- ビジネスのアクセスが急増して焦ってしまう
502エラー（Bad Gateway）は、ユーザーにも運営者にも突然のトラブルであり、サイトの信頼性低下やビジネス損失につながる恐れがあります。
本記事では、初心者の方にもわかりやすく、「なぜ起こるのか」→「どう解決すればいいのか」→「再発を防ぐにはどうすべきか」を順を追って解説します。
これを読めば、万が一502エラーが発生しても慌てずに対応できるようになります！
502エラーの概要
HTTPステータスコード502とは何か
Webブラウザがサーバーへアクセスを試みた際、クライアント（ユーザー）→プロキシサーバー（またはゲートウェイ）→実際のWebサーバー、という流れで通信が行われます。
502エラー（Bad Gateway）は、その途中にあるプロキシやゲートウェイが、上流のサーバーから不正な応答を受け取ったときに返されるステータスコードです。
- 発生タイミング：
- Webサーバー自体は稼働しているが、ゲートウェイ側が応答を解釈できない
- 中間サーバーの設定ミスやネットワーク障害で正しいレスポンスが返らない
- 初心者向けポイント
- 見た目は「502 Bad Gateway」と表示される
- 自分の端末や回線の問題ではなく、サーバー間の通信トラブル
- サイト運営者側での対応が必要になるケースがほとんど
ポイント：502エラーはクライアント側では解決困難です。ページの再読み込みやキャッシュクリアは一時的な対処にしかなりません。
表示パターンと他のエラーとの比較
502エラーはWebサーバーやサービスによって、メッセージの文言や見た目が異なります。
以下の表は代表的な表示例と、500（Internal Server Error）や503（Service Unavailable）との違いをまとめたものです。
| エラーコード | 表示例 | 原因イメージ | 対処の視点 |
|---|---|---|---|
| 502 | Bad Gateway 502 Proxy Error | 中間サーバーが上流から不正応答を受信 | 中継サーバー設定確認 ⚙️ |
| 500 | Internal Server Error | サーバー内部のプログラムや構成ファイルに異常 | サーバーログ調査 📝 |
| 503 | Service Unavailable 503 Temporarily Unavailable | サーバーがメンテナンス中、または過剰負荷で稼働停止 | メンテナンス予定確認 🔧 |
- 502 vs 500
- 500は「サーバー内部で処理に失敗した」
- 502は「中継役が不正応答を受け取った」
- 502 vs 503
- 503は「意図的にサービスを停止中（メンテナンス等）」
- 502は「予期せぬ通信エラー」
😊 まとめ：502エラーは“ゲートウェイの通信異常”を示すもの。中継役サーバーの設定やネットワーク経路を重点的に確認しましょう。
502エラーが発生する主な要因
サーバーへの過剰アクセスや一時的負荷
大量のアクセスが短時間に集中すると、サーバーの処理能力を超えてしまい、中継サーバー（ゲートウェイ）が適切な応答を受け取れなくなります。
- アクセスバースト：キャンペーンやSNS拡散による急激なトラフィック増加
- スロークライアント攻撃：意図的に接続を維持し続けるリクエスト
⚡️ 対策例：CDN導入やロードバランサーで負荷を分散する。
サーバー側メンテナンスや停止
サーバー自身がメンテナンス中、または予期せぬシャットダウンが発生すると、ゲートウェイは正常なレスポンスを取得できず502を返します。
- 定期メンテナンス：OSやミドルウェアのアップデート中
- ハードウェア障害：ディスク故障や電源トラブル
🛠 対策例：メンテナンスウィンドウの事前告知と冗長構成の実装。
ホスティングスペック不足
契約しているプランのCPU・メモリ・同時接続数が不足していると、本来の処理を完了できずゲートウェイが異常応答を受け取ります。
- CPU飽和：計算負荷の高い処理が常時動作
- メモリ枯渇：キャッシュやセッションの膨張
📈 対策例：プランアップグレードやオートスケール設定を検討。
DNS設定の不整合
DNSレコードの変更中や緩衝期間（TTL）内に古い情報がキャッシュされていると、間違ったサーバーへ問い合わせが行われ502を誘発する場合があります。
- TTL設定ミス：短期間で頻繁にレコードを変更
- ゾーン転送問題：セカンダリDNSが更新されない
🌐 対策例：変更前にTTLを短く設定し、完了後に戻す。
ファイアウォール設定の誤り
中継サーバーやWebサーバーのファイアウォールで、必要な通信ポートやIPレンジがブロックされていると、レスポンスが遮断されてしまいます。
- IP制限の過剰設定：プロキシ／ロードバランサーのIPを通し忘れ
- ポート閉塞：HTTP（80番）／HTTPS（443番）以外の必要ポートを遮断
🔒 対策例：通信フロー図を作成し、必須ポート・IPを整理。
ソースコード／プラグインの記述ミス
WebアプリケーションやCMSプラグインにバグや設定ミスがあると、サーバー側で異常終了を招き、ゲートウェイ経由で502が返ることがあります。
- 無限ループ：PHPスクリプトやプラグインが終了しない
- 依存モジュール不整合：バージョン違いでライブラリが動作停止
🐞 対策例：エラーログを解析し、問題箇所を特定して修正。
その他（IP変更、支払いトラブルなど）
想定外のトラブルも502を引き起こします。
- IPアドレスの移行中：新旧サーバーの切替が不完全
- 支払い遅延：レンタルサーバー停止による強制シャットダウン
❗️ 対策例：運用手順書の整備と、支払いアラートの設定。
以上が502エラーを誘発する代表的な原因です。状況に応じて一つずつ潰していくことで、再発防止と迅速な復旧が可能になります！
エラー発生時にまず確認すべきポイント
サイト稼働状況とステータス確認方法
- 外部監視サービスを活用
- UptimeRobot や Pingdom などで、サイトが正常応答しているかを即座に確認できます。
- アラート設定をしておくと、ダウン時に自動で通知を受け取れます。📩
- コマンドラインでの手動チェック
curl -I https://example.comで HTTP レスポンスヘッダー（ステータスコード）を取得。- ステータスが 200 以外（特に 502）なら、何らかの異常が発生しています。
- ステータスページやダッシュボード
- ホスティング会社の管理画面で、「サーバー稼働率」「リソース使用率」をチェック。
- メンテナンスモードや停止中の旨が表示されていないか確認しましょう。
サーバー／ネットワークログのチェック手順
- サーバーログの抽出
- Webサーバー（Apache, Nginx）のエラーログファイル（例：
/var/log/nginx/error.log）を開く。 - 発生時刻周辺のエントリを タイムスタンプ順に追いかけ、異常なメッセージを探します。
- Webサーバー（Apache, Nginx）のエラーログファイル（例：
- ネットワークログの解析
- ファイアウォールやロードバランサーのログ（例：AWS ELBログ）にて、異常なリクエストやタイムアウトをチェック。
- レスポンスタイムや ステータスコード分布を確認し、502発生パターンを特定。
- ログ可視化ツールの利用
| ツール名 | 特徴 |
|---|---|
| ELK Stack | 大量ログをインデックス化し、検索・可視化が容易 |
| Grafana＋Loki | メトリクスとログを同一ダッシュボードで管理 |
| Splunk | 大規模環境向けの商用ログ分析プラットフォーム |
ブラウザや端末側キャッシュ・設定の検証
- キャッシュクリア
- Windows/Linux：
Ctrl + F5で強制再読み込み - Mac：
⌘ + Shift + R - ブラウザキャッシュが古いレスポンスを保持している場合、502エラー画面が残ることがあります。🧹
- Windows/Linux：
- シークレット／プライベートモードでの再アクセス
- 拡張機能やキャッシュの影響を排除して、純粋なリクエストを試せます。
- 別端末・別ネットワークでの動作確認
- 社内ネットワークや社外（モバイル回線）など、異なる経路でアクセス。
- プロキシやVPN が影響しているかを切り分ける際に有効です。
これらを手順どおりに確認することで、502エラーの原因切り分けがスムーズに進みます。
問題箇所を早期に特定し、次の復旧アクションへつなげましょう！
502エラーの復旧手順
サーバー再起動やプラン見直しで負荷を緩和
- サーバー再起動
- 一時的に溜まったプロセスやキャッシュをクリアして、リソースをリセット。
- 管理パネルやSSHから
sudo rebootコマンドを実行し、サービスを再起動します。
- ホスティングプランの見直し
- 現行プランのCPU・メモリ・同時接続数が不足している場合、上位プランへアップグレード。
- 費用対効果を考慮しつつ、自動スケールやオートスケーリング機能の有無も確認しましょう。🚀
DNS設定の反映状況確認とキャッシュクリア
- DNSプロパゲーションの確認
dig example.com @8.8.8.8やオンラインツールで、各リージョンで最新レコードが見えているかをチェック。
- キャッシュクリア
- サーバー側キャッシュ（Varnish, Nginx FastCGI）をクリア：
sudo service varnish reload sudo nginx -s reload- DNSキャッシュもローカルでクリアすると効果的（例：
sudo systemd-resolve --flush-caches）。🧹
ファイアウォール／CDN設定の調整
- ファイアウォール
- ブロックリストやIP制限を一時的に緩和し、502が解消されるかを確認。
- 問題切り分け後、必要最小限のルールだけを再度適用します。
- CDN
- Cloudflare 等のキャッシュを「開発モード」に切り替え、オリジンサーバーへの通信を直接検証。
- キャッシュ設定のTTLを短くするか、一度バイパスして動作確認を行いましょう。☁️
コード・WordPressプラグインの修正・無効化
- エラーログ確認
- PHP エラーログやCMSログを読み、致命的エラーやプラグイン競合を特定。
- 修正／無効化
- 該当プラグインを一時停止し、502が消えるか試す。
- カスタムコードやテンプレートのバグを修正したら、段階的に再有効化して動作を確認します。🔧
PHPやバックエンド設定の最適化
- PHP設定
max_execution_timeやmemory_limitを見直し、リクエストタイムアウトを防止。- 必要に応じて PHP-FPM プロセス数を増やす。
- データベース／外部API
- クエリの最適化やコネクションプール設定を調整し、バックエンド処理の高速化を図ります。
✨ これらの手順を順に実践することで、502エラーの復旧を迅速かつ確実に進められます。
問題箇所を一つずつ潰して、再発防止策につなげましょう！
再発防止のための対策
モニタリング＆アラート導入で即時検知
- 監視ツールの設定
- サーバーのHTTPステータス、レスポンスタイム、エラーレートを常時監視
- Prometheus＋Grafana、Datadog、UptimeRobotなどを組み合わせて可視化
- アラートルールの策定
- 502エラー発生時に即座に通知（メール／Slack／SMS）
- CPU使用率や接続数の急上昇もトリガーに設定し、障害前兆を察知
- 障害対応フローの自動化
- アラート受信後、自動リトライや一時的にトラフィックを別サーバーへ誘導
- 自動スクリプトで基本的な復旧処理（キャッシュクリア、サービス再起動）を実行
定期バックアップとメンテナンス手順の共有
- バックアップ計画の立案
- データベース／ファイル／設定ファイルを定期的に保存
- バックアップ保存先はオンサイト＋オフサイトで二重化
- メンテナンスドキュメントの整備
- 実施手順、影響範囲、責任者を明確化したチェックリストを作成
- メンテナンス履歴をチームで共有し、ナレッジベースとして蓄積
- 定期レビューミーティング
- バックアップ／復元テスト結果を評価し、手順の改善ポイントを洗い出す
- 新たな脅威や構成変更に合わせてドキュメントを更新
スケーリング・ロードバランサー活用
- 自動スケーリングの導入
- トラフィックやCPU負荷に応じてインスタンス数を自動増減
- AWS Auto Scaling、GCP Instance Groupsなどで設定
- ロードバランサー配置
- 複数台のWebサーバーを背後に配置し、トラフィックを均等分散
- ヘルスチェック機能で異常サーバーを自動除外
- キャパシティプランニング
- 平常時／ピーク時のリソース使用量を把握し、閾値を設定
- 定期的な負荷試験で余裕度を検証し、計画的なアップグレードを実施
これらの施策を組み合わせることで、502エラーの兆候をいち早く察知し、手順化された対応で素早く復旧、さらにシステムの余裕度を高めて再発を防止できます。
SEO・ビジネスへの影響
検索順位の低下リスクとクローラー巡回への影響
サイトが頻繁に502エラーを返すと、検索エンジンのクローラー（例：Googlebot）は「安定してアクセスできないサイト」と判断し、巡回頻度の低下やインデックスの抹消につながる恐れがあります。
- クローラー巡回の減少：503や500と異なり、502は予期しない障害を示すため、再訪問間隔が長くなる場合があります。
- ランキング下落：クローラーのアクセス不足により、コンテンツの最新評価が遅れ、競合サイトに順位を奪われるリスクが高まります。
| 影響項目 | エラーなし時の挙動 | 502多発時の挙動 |
|---|---|---|
| クローラー巡回頻度 | 定期的（月～週1回程度） | 不定期～大幅に間隔が開く |
| インデックス状況 | 新規ページが速やかに登録 | 登録遅延、最悪抹消の可能性 |
| 検索順位 | 安定的・継続的に評価更新 | 徐々に下降傾向 📉 |
ユーザー離脱および広告収益への悪影響
502エラーがユーザー体験を損なうと、直帰率の上昇やページビュー減少を招き、結果的に広告収益やコンバージョン率が大きく落ち込みます。
- 直帰率アップ：エラー画面を見たユーザーはすぐに離脱し、再訪問の可能性も低下 😓
- 広告インプレッション減少：表示回数が減ることで、クリック数や収益（CPC／CPM）が減少 💸
- ブランドイメージ低下：繰り返す障害は信頼を損ね、長期的な顧客離れを引き起こす可能性もあります。
Tip: エラー発生時にはカスタムメンテナンスページを用意し、案内メッセージや再チャレンジボタンを設置することで、離脱を最小限に抑えましょう。
よくある質問（FAQ）
502エラーと他の500番台エラーの違いは？
- 500 Internal Server Error
サーバー内部で処理に失敗した場合に返されます。アプリケーションのバグやサーバー設定ミスが主な原因です。 - 502 Bad Gateway
プロキシやロードバランサーなど中継サーバーが、上流サーバーから不正な応答を受け取ったときに発生します。通信経路のトラブルやゲートウェイ設定の誤りが背景にあります。 - 503 Service Unavailable
サーバーがメンテナンス中、または過剰負荷で一時的にサービスを停止している場合に返されます。再読み込みすれば復旧することがほとんどです。
| エラーコード | 主な意味 | 特徴 |
|---|---|---|
| 500 | サーバー内部の異常 | アプリや設定のバグ |
| 502 | 中継役が不正応答を受信 | ネットワーク・ゲートウェイ関連 |
| 503 | 一時的なサービス停止・過負荷 | メンテナンス・負荷分散 |
ユーザー側で試せる対応は何？
- ページの再読み込み
Ctrl + F5（Windows/Linux）、⌘ + Shift + R（Mac）でキャッシュを無視して再読み込み。
- シークレット／プライベートモードでアクセス
- 拡張機能やキャッシュの影響を排除して、純粋なリクエストを試せます。
- 別のブラウザ・端末・ネットワークで確認
- 社外の回線やモバイル回線を使い、プロキシ・VPNの影響を切り分け。
- しばらく待って再アクセス
- 一時的な負荷やメンテナンスが原因の場合、数分～数十分で復旧することがあります。😊
ワンポイント：クライアント側でできることは限られるため、解消しない場合はサイト運営者に連絡するとスムーズです。
復旧にかかる時間の目安は？
- 一時的な負荷やメンテナンス：数分～数十分
- 設定ミスや小規模な構成変更：30分～数時間
- DNS切り替えによるプロパゲーション：最大でTTL時間（一般的に1〜48時間）
- 大規模なインフラ変更や調査対応：半日〜数日
🎯 目安：
- 短時間で復旧しない場合は、ログ調査や設定見直しを行い、再発防止策を検討しましょう。
まとめ
本ガイドでは、まず502エラーの仕組みと特徴を押さえたうえで、過剰アクセス／メンテナンス／DNS設定ミスなど代表的な原因を整理しました。
そして、サーバー再起動やプラン見直し、DNSキャッシュクリア、ファイアウォール・CDNの設定調整、プラグイン無効化など具体的な復旧手順をステップごとに紹介。
さらに、モニタリング＆アラート、定期バックアップ、自動スケーリング構成といった再発防止策も網羅しました。
502エラーは「起きると面倒」ですが、原因を正しく把握し、適切な手順を踏むことで迅速に復旧できます。
また、事前の準備と運用体制の強化があれば、発生そのものを未然に防ぐことも可能です。
本記事を参考に、万全の体制を整えて安心のサイト運営を実現してください！
