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

UnsplashのAnkit Singhが撮影した写真

Webサイトを閲覧中に「504 Gateway Timeout」と表示された場合、その多くは入口となるサーバーやプロキシが、上流サーバーの応答を時間内に受け取れなかった状態です。まず利用者は再読み込みや別回線で切り分け、運用者は上流側の遅延やタイムアウト設定を確認します。

504はブラウザの表示不具合ではなく、HTTPの途中経路で待ち時間切れが起きたときに返されるエラーです。原因を切り分けるには、どの層で待ち時間が切れたのかを見る必要があります。ここから、504エラーの意味、起きやすい原因、利用者・運用者それぞれの対処ポイントを順に整理します。

504エラーとは何か？

504エラーは、Webサイトやアプリケーションにアクセスした際に返されるHTTPステータスコードの一つです。このエラーは、途中経路のゲートウェイやプロキシが、上流の応答を時間内に受け取れなかったことを示します。

504はどこで発生するエラーか

504が返るのは、利用者が直接見ている入口側のサーバーやプロキシが、さらに先の上流サーバーを待っている場面です。CDN、ロードバランサー、リバースプロキシ、APIゲートウェイなどが前段にある構成では、どこで待ち切れなかったのかを切り分けることが重要になります。

504エラーの定義

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

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

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

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

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

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

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

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

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

504エラーが発生する原因

504エラーは「上流からの応答が返らない／遅い」ことで発生します。原因は一つではないため、処理、ネットワーク、アプリ、負荷のどこで遅れているかを分けて見る必要があります。

まず疑う場所を切り分ける

このように、504は一つの原因名ではなく「待ち切れなかった結果」です。どの層で待ち時間が膨らんでいるかを先に見ると、調査の順番がぶれにくくなります。

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

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

ネットワークの問題

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

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

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

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

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

504エラーへの対処方法

504は一つの対処で片づくエラーではありません。利用者は再試行と閲覧環境の切り分け、運用者は上流側の遅延箇所の特定から始めます。

まず切り分けるポイント

一時的な混雑でたまたま起きたのか、特定の操作で再現するのか、サイト全体で続いているのかで、次に見る場所は変わります。利用者は再試行と状況整理、運用者はログとタイムアウト箇所の特定から入るのが基本です。

利用者側でまず試すこと

• 数分待ってから再読み込みする（瞬間的な過負荷の場合があります）。
• 別の回線（モバイル回線など）で試す（回線側の問題切り分け）。
• VPNや社内プロキシを使っている場合は、その設定やDNS解決を確認する（閲覧環境の例外要因の切り分け）。
• 頻発する場合は、サイト管理者へ時刻・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はサーバーダウンと同じですか？

同じとは限りません。サーバーが完全に停止している場合だけでなく、上流の応答遅延や経路上のタイムアウト設定により、入口側が待ち切れず504を返すこともあります。

504 Gateway Timeoutとは何ですか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

レスポンスタイムやエラー率の継続監視、負荷テスト、ボトルネックの改善、冗長化、ログを継続的に確認する運用が再発防止に役立ちます。

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

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

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

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