504エラー（Gateway Timeout）完全ガイド！原因、解決法、再発防止策など徹底解説！

2025年7月22日

「また504エラーが出てサイトが見られない……」
「何度リロードしても直らないけど、原因がわからない」
「どこをチェックすればいいのか手順がまとまっていなくて困っている……」
「再発しないように対策を立てたいけど、何から始めればいいの？」

こんな不安や疑問を抱えたままでは、アクセスが途絶えたサイトを前に途方に暮れるばかりです。

特にビジネスサイトやブログであれば、表示できない時間＝機会損失。

早急な原因究明と確実な解決策が求められます。

本記事では「504エラー（Gateway Timeout）」が発生したときに

何が起きているのか
どこをどうチェックすればいいのか
即効性のある解決法と再発防止策

を初心者にもわかりやすくステップごとにご紹介します。

これを読めば、次に504エラーに遭遇したときも落ち着いて対処できるようになります！

エラーの基本と見分け方

Gateway Timeoutとは何か

「504 Gateway Timeout」は、ウェブサーバー（代理サーバー）が上位のサーバーからタイムリーに応答を受け取れなかった場合に返されるHTTPステータスコードです。

TCPレベルでは接続成功 していても、
アプリケーション層での処理がタイムアップ したときに発生します。

主な特徴：

クライアント（ブラウザ）は正常にサーバーにリクエストを送信できている
サーバー間通信で遅延や遮断が起きている
一時的な問題であるケースが多い

💡 Point: 一度だけでなく、何度かリロードしても同じエラーが続く場合は、サーバー側またはネットワーク設定の確認が必要です。

エラー画面の確認ポイント

初めて見たとき戸惑わないように、画面表示の要素をチェックしましょう。

スクロールできます

項目	確認内容
ステータスコード	「504」または「Gateway Timeout」の文言が含まれているか
サーバー名・ロゴ	どのホスティング会社／CDNのエラーページか
詳細メッセージ	「Request timed out」「The server didn’t respond in time」などの文言
リトライの案内	「再試行ボタン」や「管理者へ連絡してください」といった指示

チェック手順：

ブラウザのデベロッパーツールを開き、Networkタブでステータスコードを確認
エラーページ上の文言やボタンから、自己解決できるヒントを探す
エラーページのヘッダーやフッターを見て、利用中のサービス名を特定

🔍 これでわかること

問題が自社サーバーかCDNか
クライアント側の再読み込みで解決する一時的トラブルか
サーバー設定の見直しが必要か

504エラーが及ぼす影響

ウェブサイトの可用性とSEOへの影響

ウェブサイトが頻繁に504エラーを返すと、サーバーの稼働時間（可用性）が低下し、結果として検索エンジンからの評価にも悪影響が出ます。

インデックスの除外リスク
- クローラーがページに到達できず、インデックスから外される可能性があります
ランキング低下
- ページの表示速度や安定性はSEO評価の要素のひとつ。タイムアウトが多発すると順位が落ちやすくなります
ペナルティ対象に
- 長時間のダウンや繰り返しのエラーは「信頼性の低いサイト」と判断され、ペナルティを受けるリスクがあります

スクロールできます

影響項目	結果イメージ
クローラーの巡回	回数減少 → 新規コンテンツが反映されにくい
ページスコア	低下 → Core Web Vitals評価の悪化
オーガニック流入数	減少 → 検索経由の訪問者が減る

🚨 注意: 504エラー自体は一時的でも、頻繁に発生するとSEO指標に累積的なダメージを与えます。

ユーザー体験への悪影響

閲覧者がサイトにアクセスした際に504エラーに遭遇すると、信頼感の低下や離脱率の増加を招きます。

直帰率（Bounce Rate）の上昇
- ページが表示されないと即座に離脱されやすく、直帰率が急上昇します
ブランドイメージの悪化
- サイトの信頼性が損なわれ、ユーザーの印象が悪くなります
コンバージョン損失
- 商品購入やお問い合わせなど、重要なアクションを取る前に離脱されると売上機会を失います

✨ ユーザー離脱を防ぐためのヒント

カスタムエラーページ を用意し、状況説明と再試行リンクを表示
自動リトライ機能 を組み込み、短時間で復旧した場合に再アクセスを試みる
通知システム でサイト運営者へアラートを送信し、迅速な対応を実現

以上のように、504エラーはサイトの信頼性・集客・売上に直結するため、早期発見と対策が重要です。

発生原因の整理

サーバー応答の遅延（処理時間オーバー）

サーバー側での処理が長時間かかり、タイムアウトの上限を超えてしまうケースです。

重いクエリや複雑な計算が実行されている
バックエンドでのデータベース検索がボトルネック
リソース不足（CPU／メモリ）で処理が滞留

💡 対策例：

クエリの最適化やインデックス追加
サーバーのスケールアップ／スケールアウト
非同期処理への切り替え

ネットワークやDNS設定の不具合

サーバー間やクライアント〜サーバー間の通信経路に障害がある場合です。

DNS解決の遅延や誤設定
経路上のパケットロスや断線
ルーティング設定ミス

💡 対策例：

DNSキャッシュをクリアして再解決
別のDNSサーバー（例：Public DNS）を試す
ネットワーク機器のログ確認と再起動

アプリケーション・プラグインの異常

導入しているプラグインやアプリケーション自身の不具合が原因で、処理が停止・遅延するケースです。

バグのあるプラグインがリクエストをハングアップ
アップデート後に互換性エラーが発生
メモリリークや無限ループ

💡 対策例：

プラグインを一つずつ無効化して原因切り分け
最新版へのアップデート or 公式パッチ適用
ログ出力を強化し、該当箇所を特定

CDN／プロキシ／ファイアウォールの制限

外部サービスや中継装置がタイムアウト閾値を短く設定している場合です。

CDNのタイムアウト値が小さい
プロキシサーバーの接続制限
ファイアウォールでのセッションタイムアウト

💡 対策例：

CDN設定でタイムアウト時間を延長
プロキシ／ファイアウォールのポリシー見直し
直接オリジンサーバーへアクセスして挙動チェック

大量アクセス・DDoS攻撃など外部要因

正当なトラフィック増加や悪意ある攻撃により、サーバーが過負荷状態になるケースです。

バースト的アクセスで同時接続数が急増
ボットやスクリプト攻撃によるリクエスト洪水
キャッシュを効かせられない動的リクエストの集中

💡 対策例：

WAFやDDoS防御サービスの導入
レートリミット／スロットリングの設定
ロードバランサーでの負荷分散

スクロールできます

原因カテゴリ	主な症状	確認ポイント
サーバー処理の遅延	特定ページだけタイムアウト	処理時間ログ、CPU／DB負荷
ネットワーク／DNS障害	全ページまたは特定経路で一貫した失敗	DNS応答時間、パケット損失率
プラグイン・アプリ異常	実装変更後に発生、特定機能のみ影響	エラーログ、バージョン履歴
CDN／プロキシ／FW制限	外部サービス一時停止時に発生	サービス側タイムアウト設定
大量アクセス・攻撃	アクセス数急増時に同時発生	アクセスログ、WAFアラート状況

各カテゴリごとに発生条件を把握し、優先順位をつけて調査・対応を進めましょう。

チェックリスト＆対処手順

ブラウザ再読み込み・別端末での確認

手順：ページ上で「再読み込み🔄」を数回実施
狙い：一時的な通信トラブルやキャッシュの不整合をリセット
別端末での確認：スマホや他のPCで同じURLにアクセスし、問題が再現するかチェック

ルーターやスイッチの再起動

手順：家庭内・社内ネットワーク機器の電源を一度OFF→ON
狙い：ネットワーク機器内部の不具合（メモリリークや過負荷）を解消
ポイント：再起動後、IPアドレスが変わる場合があるので、再度アクセスを確認

DNSキャッシュのクリアと設定見直し

手順：
1. コマンドプロンプト／ターミナルで ipconfig /flushdns（Windows）または sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder（Mac）
2. ブラウザのDNSキャッシュもクリア（例：Chromeなら chrome://net-internals/#dns）
狙い：古いIP情報や誤ったレコードを排除し、最新のDNS設定を取得
代替DNSの利用：Google Public DNS（8.8.8.8／8.8.4.4）などを一時的に設定

プロキシ／CDNの一時停止検証

手順：
- CDN：管理画面からバイパスモードや開発モードに切り替え
- プロキシ：ブラウザやOSのプロキシ設定を無効化
狙い：中継サーバー由来のタイムアウトかどうかを切り分け
ヒント：停止後にエラーが解消すれば、CDN／プロキシ設定の調整が必要

ホスティング会社へのサーバー状況問い合わせ

手順：
1. 事象発生時刻や再現手順をまとめる
2. コントロールパネルまたはサポート窓口へ連絡
伝えるべき情報：
- 発生日時・頻度
- 対象URL
- 手元で試した対処内容
狙い：サーバー側ログやネットワーク機器異常の有無を確認

プラグイン・テーマの停止とログ解析

手順：
1. CMS（例：WordPress）で全プラグインを一時停止
2. テーマをデフォルトテーマに切り替え
3. 再発するかテスト
ログ取得：サーバーのエラーログ（Apache／Nginx）やアプリケーションログを参照
狙い：追加機能による負荷や不具合の有無を切り分け

Apache／nginx／FastCGI設定の最適化

主な設定項目：
- Timeout（Apache）/ proxy_read_timeout（Nginx）
- max_execution_time（PHP）/ request_terminate_timeout（PHP-FPM）
手順：設定ファイルを編集後、再起動して挙動を確認
狙い：タイムアウト閾値を適切に調整し、長時間処理への耐性を強化

スクロールできます

手順	主な目的	実施タイミング
ブラウザ再読み込み・別端末確認	一時的トラブルの排除	まず最初に
ルーター／スイッチ再起動	ローカルネットワーク不具合の解消	ネットワーク全般が疑わしいとき
DNSキャッシュクリア	名前解決トラブルの解消	DNSエラーが疑われる場合
プロキシ／CDN一時停止検証	中継サーバー要因の切り分け	CDN・Proxy利用時
サポート窓口への問い合わせ	サーバー側トラブルの確認	自力対処で解決しないとき
プラグイン・テーマ停止・ログ確認	アプリケーション要因の切り分け	CMSサイトでエラー継続時
サーバー設定の最適化	長時間処理対応の強化	根本対策として

以上の手順を順番に実施し、再現性を確認しながら最適な対処を進めていきましょう。

再発防止に向けたベストプラクティス

定期的なパフォーマンステスト＆監視体制の構築

定期的な負荷テストを実施し、ピーク時の応答時間やスループットを測定🔍
監視ツール（例：Prometheus, Grafanaなど）を導入し、CPU使用率・メモリ消費・レスポンスタイムをリアルタイムで可視化
アラート設定により、閾値超過時に自動通知📫
定期レポートで傾向を把握し、問題の兆候を早期発見

スクロールできます

項目	ツール例	目的
ロードテスト	JMeter, k6	同時接続数による影響測定
リソース監視	Prometheus	CPU／メモリのボトルネック検出
レスポンスタイム監視	Grafana	時系列データの可視化
アラート機能	Alertmanager	異常時の通知

適切なタイムアウト値とサーバーリソース管理

タイムアウト設定の見直し
- アプリケーション／DB／プロキシそれぞれに最適な値を設定し、過度な短縮を避ける
自動スケーリングを利用し、負荷増加時にリソースを動的に追加🛠️
キャッシュ活用（RedisやMemcached）で同一リクエストの負荷を軽減
コンテナオーケストレーション（Kubernetesなど）でリソース配分を効率化

負荷分散（ロードバランサー）とバックアップ構成

ロードバランサー導入
- 複数のアプリケーションサーバー間でトラフィックを均等に分散🌐
- ヘルスチェック機能で不健康ノードを自動除外
冗長構成の設計
- マルチAZ配置や複数リージョンへのレプリケーションで単一障害点を排除
定期バックアップと障害復旧訓練
- データベース／設定ファイルを自動取得し、障害時には迅速にリストア
- DR（Disaster Recovery）演習を通じて手順の精度を維持🏥

スクロールできます

構成要素	ポイント
ロードバランサー	セッション保持の有無、SSLオフロード対応
マルチリージョン	データ同期方法、レイテンシ考慮
バックアップ頻度	RPO（目標復旧時点）に合わせたスケジュール
DR演習	年1回以上の実施、結果のドキュメント化

これらの施策を組み合わせることで、504エラーの再発リスクを大幅に低減し、安定したサービス運用を実現できます。

エラーコード	主な意味	発生タイミング
500	サーバー内部の異常処理	アプリケーション例外発生時
502	上位サーバーからの不正応答	プロキシ・ゲートウェイ間通信時
503	サービスが一時的に利用不可	メンテナンス中・過負荷時

よくある質問（FAQ）

504エラーはどのくらいで復旧する？

復旧までの時間は原因や環境により異なりますが、短時間のリロードで直るケースと、サーバー設定の調整やインフラ対応が必要なケースがあります。

一時的ネットワーク障害：数秒～数分で復旧
CDNやプロキシ設定変更：数分～十数分
サーバーリソース増強や設定見直し：数十分～数時間

🔄 ヒント: まずはブラウザ再読み込みや別端末でのチェックを行い、一時的トラブルかどうかを見極めましょう。

最優先で見直すべき設定項目は？

タイムアウト値
- Apache/NginxやPHP‑FPMの Timeout／proxy_read_timeout／request_terminate_timeout を確認
DNS設定
- TTLやキャッシュが古いと、誤ったサーバーにリクエストが飛ぶ可能性あり
CDN／プロキシの挙動
- バイパスモードで直にオリジンサーバーへ接続し、タイムアウト閾値を検証
サーバーリソース
- CPU・メモリ・データベース接続数など、負荷状況をモニタリング

他のGateway Timeoutエラーとの違いは？

HTTP標準で504は「ゲートウェイ役が時間内に応答を得られなかった」ことを示しますが、サービスやミドルウェアによって細かな名称や表示が異なります。

スクロールできます

種類	表示例・特徴
標準504	“504 Gateway Timeout”
Cloudflare固有504	“Error 504 Ray ID: …” + Cloudflareロゴが表示
Nginxプロキシでの504	“upstream timed out (110: Connection timed out)”
FastCGI（PHP‑FPM）での504	“Primary script unknown”や “recv() failed (104: Connection reset by peer)”

これらはすべて根本原因がタイムアウトである点で共通しますが、ログや管理画面のメッセージから発生箇所を特定しやすくなる違いがあります。

まとめ

504エラーの本質は「サーバー同士の連携がタイムアウトした状態」であり、ブラウザやユーザー側の問題ではないことをまず理解
初動対応としては、ブラウザ再読み込みや別端末での確認、ネットワーク機器のリセットなどで一時的トラブルを切り分け
原因特定は「サーバー処理の遅延」「ネットワーク／DNS異常」「アプリ・プラグインの不具合」「CDN／プロキシ設定」「大量アクセス・攻撃」の5大要因を順にチェック
恒久対策としては、適切なタイムアウト値の設定、リソース管理、負荷分散構成、監視体制＆定期テストの整備が不可欠

504エラーは発生頻度が低くても、サイト運営に重大な影響を及ぼします。

本ガイドの手順とベストプラクティスを参考に、「見えない敵」に強いインフラと運用フローを構築しましょう。

次回からは慌てずに、この記事を頼りにスマートに復旧対応できるはずです！✨

504エラー（Gateway Timeout）完全ガイド！原因、解決法、再発防止策など徹底解説！