504エラーとは？ 10分でわかりやすく解説

UnsplashのAnkit Singhが撮影した写真

Webサイトを閲覧中に「504 Gateway Timeout」と表示され、ページが読み込めないことはありませんか？ 504は、ブラウザではなくサーバー側（サーバー間通信）で待ち時間が限界に達したときに返されるエラーです。この記事では、504エラーの原因と、利用者・運用者それぞれの対処ポイントを分かりやすく整理します。

504エラーとは何か？

504エラーは、Webサイトやアプリケーションにアクセスした際に返されるHTTPステータスコードの一つです。このエラーは、サーバー間の通信が時間内に完了しなかったことを示します。

504エラーの定義

504エラーはGateway Timeout（ゲートウェイ タイムアウト）とも呼ばれます。リクエストを受け取ったサーバー（例：ロードバランサー、リバースプロキシ、APIゲートウェイなど）が、上流（バックエンド）サーバーからの応答を待つ間にタイムアウトし、処理を打ち切って返すエラーです。

504エラーが発生するシナリオ

504エラーが起きる流れは、概ね次の通りです。

1. ユーザーがWebサイトやアプリケーションにアクセスする。
2. 入口となるサーバー（プロキシ／ロードバランサー等）が、バックエンドに処理を依頼する。
3. バックエンドの応答が遅い、または応答が返らない。
4. 入口のサーバーが待ち時間の上限に達し、504エラーを返す。

504エラーとタイムアウトの関係

504は「待ち時間（タイムアウト）」が直接のトリガーです。タイムアウトとは、あらかじめ設定された時間内に処理が完了しなかった状態を指します。サーバーは無限に待ち続けられないため、一定時間を超えるとタイムアウトとして処理を終了し、504を返します。

504エラーとほかのエラーコードの違い

504は似たエラーと混同されがちです。違いを整理しておくと切り分けがしやすくなります。

いずれもサーバー側の問題を示すことが多い一方で、504は「サーバー間通信の待ち時間切れ」である点が特徴です。

504エラーが発生する原因

504エラーは「上流からの応答が返らない／遅い」ことで発生します。背景には複数の原因があり得るため、切り分けが重要です。

サーバーの処理時間が長い

もっとも多い原因は、バックエンドの処理が遅く、タイムアウト時間を超えることです。サーバーのリソース不足、DBの重いクエリ、外部API呼び出しの遅延、ロック待ちなどが起点になります。

ネットワークの問題

サーバー自体が健全でも、ネットワークの遅延や断続的な切断で上流の応答が届かないことがあります。回線混雑、機器障害、DNSの不調、経路上のFW/プロキシ設定などが影響します。

アプリケーションの不具合

アプリケーションのバグや設定ミスにより、処理が長引くケースもあります。無限ループ、外部依存のリトライ過多、例外処理の抜けなどで、結果としてタイムアウトにつながります。

過負荷・DoS攻撃などの外的要因

アクセス集中や攻撃でサーバーが過負荷になると、正常系の処理が遅れやすくなります。大量リクエストによりCPU/メモリ/接続数が逼迫すると、上流応答が遅れ、504が出やすくなります。

504エラーへの対処方法

504は原因が一つとは限りません。ここでは「利用者側でできること」と「運用者側で行うこと」を分けて整理します。

利用者側でまず試すこと

• 数分待ってから再読み込みする（瞬間的な過負荷の場合があります）。
• 別の回線（モバイル回線など）で試す（回線側の問題切り分け）。
• ブラウザのキャッシュ削除やシークレットモードで試す（周辺要因の切り分け）。
• 頻発する場合は、サイト管理者へ時刻・URL・発生状況を添えて連絡する。

タイムアウト設定の見直し（運用者向け）

504の直接原因はタイムアウトです。入口（LB/プロキシ）とバックエンド双方のタイムアウト値を確認し、処理特性に合っているか見直します。

• 上流応答に必要な時間を確保するため、タイムアウト値を適切に延ばす。
• API／画面／バッチなど、処理タイプ別に個別設定できる場合は分ける。
• ロードバランサー、リバースプロキシ、アプリ、DB、外部APIなど、どこで待ち切れているかを揃えて確認する。

ただし、値を大きくし過ぎると接続が滞留し、別の不調を呼ぶことがあります。「処理を速くする」対策とセットで検討するのが安全です。

サーバーリソースの最適化（運用者向け）

504の背景にリソース不足がある場合、CPU・メモリ・I/O・接続数のボトルネックを潰すことが近道です。

• スケールアップ／スケールアウト（台数増・オートスケール）を検討する。
• 重い処理（DBクエリ、検索、集計）を最適化する。
• キャッシュ（アプリ／DB／CDN）を導入し、バックエンド負荷を下げる。
• 不要なプロセス停止や設定見直しで、無駄なリソース消費を抑える。

ネットワーク環境の改善（運用者向け）

ネットワーク起因の場合は、遅延・パケットロス・DNS・経路を疑います。監視で異常が出ていないかを確認しつつ、必要なら冗長化も検討します。

• ネットワーク機器やプロキシの設定・ファームウェアを見直す。
• 障害点になっている経路や機器がないか確認する。
• 冗長回線やマルチAZ構成などで単一障害点を減らす。

アプリケーションの修正とデバッグ（運用者向け）

アプリ側が原因の場合は、ログと計測で「どこに時間がかかっているか」を特定します。タイムアウトを伸ばす前に、遅い理由を潰すのが基本です。

• 発生時刻のログ（アプリ／プロキシ／LB）を突き合わせて原因箇所を絞る。
• 外部API呼び出しに上限時間・リトライ制御・フォールバックを設ける。
• 非同期処理（ジョブ化）やキュー導入で、ユーザー応答を先に返す設計にする。

504エラー対策のベストプラクティス

定期的なシステムモニタリング

504の予兆は、レスポンスタイムの悪化やエラー率の増加として現れます。重要指標を継続監視し、閾値を設けて通知することで、影響が広がる前に手が打てます。

パフォーマンステストの実施

負荷テスト／ストレステストで限界点を把握し、タイムアウト値・スケーリング・DB設計などを事前に調整しておくと、運用中の504を減らしやすくなります。

冗長化とフェイルオーバーの整備

単一障害点があると、そこが詰まった瞬間に504が連鎖します。冗長化、ヘルスチェック、フェイルオーバーを整備し、落ちた先を切り離せる設計にしておくことが重要です。

エラーログの解析と共有

504が出たら、原因は「入口」ではなく「上流」にあることが多いです。ログ（プロキシ／LB／アプリ／DB）を時刻で突き合わせ、どこで待たされているのかを共有できる形にすると、復旧も再発防止も早くなります。

まとめ

504 Gateway Timeoutは、入口となるサーバーが上流サーバーの応答を待ち切れず、タイムアウトしたときに返されるエラーです。原因は、バックエンド処理の遅延、ネットワーク問題、アプリ不具合、過負荷（攻撃・アクセス集中）など多岐にわたります。利用者側では再試行や回線切り分けが有効です。運用者側では、タイムアウト設定の確認に加え、処理の最適化、監視、冗長化、ログ分析を組み合わせて、発生頻度と影響を抑えていきましょう。

よくある質問

504 Gateway Timeoutとは何ですか？

入口となるサーバー（プロキシ／ロードバランサー等）が、上流サーバーの応答を待つ間にタイムアウトし、処理を打ち切って返すHTTPエラーです。

504は自分（閲覧者）側の問題ですか？

多くの場合はサーバー側（サーバー間通信やバックエンド処理）の問題です。ただし回線やDNSなど閲覧環境の影響がゼロとは限りません。

504が出たとき、まず何をすればよいですか？

少し待って再読み込みし、可能なら別回線でも試してください。頻発する場合は、発生時刻とURLを添えて管理者に連絡すると切り分けが進みます。

502や503との違いは何ですか？

502は「上流から無効な応答が返った」、503は「サーバーが一時的に利用できない」、504は「上流応答が時間内に返らず待ち切れない」という違いがあります。

タイムアウト値を増やせば解決しますか？

改善する場合はありますが、根本原因が処理遅延なら先に最適化が必要です。タイムアウトを伸ばし過ぎると接続が滞留し、別の不調を招くこともあります。

どこでタイムアウトしているかはどう調べますか？

プロキシ／LB／アプリ／DBのログを時刻で突き合わせ、入口のタイムアウト設定と一致する箇所を確認します。APMや分散トレーシングがあると特定が早くなります。

よくある原因は何ですか？

重いDBクエリ、外部APIの遅延、リソース不足、ネットワーク遅延、過負荷（アクセス集中・攻撃）などが代表例です。

運用で再発を減らすには何が効きますか？

継続監視（レスポンスタイム・エラー率・リソース）、負荷テスト、ボトルネック改善、冗長化、ログ分析の仕組み化が効果的です。

クラウドでも504は起きますか？

起きます。ロードバランサーやAPIゲートウェイ、サーバレスの待ち時間上限など、構成要素ごとの制約が原因になることがあります。

一時的に504が増えるのはどんなときですか？

急なアクセス集中、バッチ処理の重なり、外部サービス障害、ネットワーク不調、リリース直後の不具合などで、一時的に応答が遅れて504が増えることがあります。