Azure 504エラー(Gateway Timeout Error)エラーの原因と対処法を解説

Azure環境でWebアプリケーションを運用していると、「504 Gateway Timeout」エラーに遭遇することがあります。このエラーは、ゲートウェイやプロキシとして機能するサーバーが、バックエンドサーバーからの応答を制限時間内に受け取れなかった場合に発生します。
504エラーの厄介な点は、原因がクライアント側ではなくサーバー側のタイムアウトチェーンのいずれかの段階にあることです。Application Gatewayの既定タイムアウトは20秒、Azure Front Doorは30秒、App Serviceのロードバランサーは230秒と、各レイヤーのタイムアウト値が異なるため、どの段階でタイムアウトが発生しているかの特定が重要です。
本記事では、504エラーの7つの発生原因、サービス別の対処法、診断ログを活用したトラブルシューティング手順、そしてオートスケールや監視アラートによる予防策まで体系的に解説します。
Microsoft Azureの基本知識や料金体系については、こちらの記事で詳しく解説しています。

Azureの504エラー（Gateway Timeout）とは

Azure環境で発生する504エラーは、HTTP標準のステータスコードであり、ゲートウェイまたはプロキシとして動作するサーバーが、上流（バックエンド）サーバーからのレスポンスを制限時間内に受信できなかったことを示します。クライアント側の問題ではなく、サーバー間通信におけるタイムアウトが根本原因です。

504エラーと他の5xxエラーの違い

504エラーは、他の5xxエラーと混同されやすいですが、それぞれ原因と対処法が異なります。以下の表で、Azure環境でよく発生する5xxエラーの違いを整理しました。

エラーコード	エラー名	意味	主な原因
500	Internal Server Error	サーバー内部でエラーが発生	アプリケーションのバグ、未処理の例外
502	Bad Gateway	バックエンドから無効なレスポンスを受信	バックエンドの異常終了、SSL証明書の不一致
503	Service Unavailable	サービスが一時的に利用不可	メンテナンス、リソース枯渇
504	Gateway Timeout	バックエンドからのレスポンスがタイムアウト	処理時間超過、タイムアウト設定不足

502エラーがバックエンドからの「不正な応答」を示すのに対し、504エラーは「応答そのものがなかった」（タイムアウト）という点が決定的な違いです。502であればバックエンドは応答を返したが中身が不正、504であればバックエンドが応答を返す前にタイムアウトが発生しています。

Azureにおけるタイムアウトチェーン

Azure環境では、クライアントからバックエンドまでの間に複数のレイヤーが存在し、各レイヤーに独自のタイムアウト値が設定されています。504エラーのトラブルシューティングでは、どのレイヤーでタイムアウトが発生しているかを特定することが最初のステップになります。

以下の表で、主要なAzureサービスの既定タイムアウト値を整理しました。リクエストが通過する順番に、各レイヤーのタイムアウト値が設定されています。

サービス	既定タイムアウト	最大設定値	備考
Azure Front Door	30秒	240秒（Standard/Premium）	originResponseTimeoutで設定
Application Gateway V2	20秒	制限なし（バックエンド設定で変更）	リクエストタイムアウトで設定
Azure Load Balancer	4分（240秒）	30分（TCP）	アイドルタイムアウト
App Service（ロードバランサー）	230秒	230秒（ハードリミット）	変更不可

ここで注目すべきは、App Serviceのロードバランサーに230秒というハードリミットが存在する点です。Application Gatewayのタイムアウトを300秒に設定していても、バックエンドがApp Serviceであれば230秒で強制的にタイムアウトが発生します。タイムアウト値は、チェーン全体の中で最も短い値がボトルネックになります。

Microsoftの公式ドキュメントで、Application GatewayのHTTPレスポンスコードの詳細を確認できます。

---

Azure 504エラーの主な発生原因

504エラーの原因は多岐にわたりますが、Azure環境では以下の7つのパターンが特に多く発生します。

バックエンドサーバーの過負荷

バックエンドサーバーが大量のリクエストやデータ処理に追いつかず、レスポンスを返すまでにタイムアウト値を超えてしまうケースです。セールスイベントやプロモーション期間中のトラフィック急増、バッチ処理との競合、データベースクエリの長時間化などが典型的なトリガーです。

Azure Virtual MachinesのCPU使用率やメモリ使用率が90%以上に達している場合、レスポンス時間が大幅に遅延し504エラーが発生しやすくなります。Azure Monitorのメトリクスでリソース使用率を確認し、ボトルネックを特定してください。

Application Gatewayのリクエストタイムアウト

Application Gateway V2 SKUでは、バックエンド設定（Backend Setting）で構成されたタイムアウト値内にバックエンドが応答しない場合、504エラーが返されます。既定値は20秒であり、データベース検索やファイル処理など時間のかかる処理では不足する場合があります。

Application Gatewayは、最初のバックエンドプールメンバーへのリクエストがタイムアウトした場合、2番目のメンバーにリクエストを再試行します。この再試行も失敗した場合に、ユーザーに504エラーが返されます。つまり、バックエンドプール全体が過負荷の場合は再試行も効果がありません。

ヘルスプローブの失敗

Application Gatewayのヘルスプローブが、バックエンドサーバーの正常性を確認するHTTPリクエストに対してタイムアウト閾値内に応答を受け取れない場合、そのバックエンドは「異常（Unhealthy）」としてマークされます。すべてのバックエンドが異常としてマークされると、ルーティング先がなくなり504エラーが発生します。

ヘルスプローブがリダイレクト（301/302）を返す設定になっている場合も注意が必要です。Front Door Classicはヘルスプローブのリダイレクトをフォローしないため、プローブパスは200を返すエンドポイントを指定する必要があります。

Azure Front Doorのオリジンタイムアウト

Azure Front Doorがオリジン（バックエンド）に対してリクエストを送信し、設定されたタイムアウト期間内にレスポンスを受信できない場合に504エラーが発生します。既定のオリジンレスポンスタイムアウトは30秒です。Standard/Premiumティアでは16秒から240秒の範囲で設定可能です。

特に注意すべきは、Front DoorのKeepAliveタイムアウトが90秒に設定されている点です。バックエンドのWebサーバー（Apache、nginxなど）のKeepAliveTimeoutが90秒未満の場合、Front Doorが接続を再利用しようとした際にバックエンドが既に接続を切断しており、断続的な504エラーが発生します。この問題の詳細はFront Doorの公式トラブルシューティングガイドに記載されています。

App Serviceの処理時間超過

Azure Web Apps（App Service）には、フロントエンドのロードバランサーに230秒のハードリミットが存在します。この制限はユーザー側で変更できず、バックエンドの処理が230秒を超えると強制的に504エラーが返されます。

大容量ファイルのアップロード、複雑なレポート生成、大量のデータベースクエリなど、長時間の処理が必要なユースケースでは、この制限に抵触しやすくなります。230秒を超える処理は、非同期パターン（Azure Queue Storage + Azure Functions）に切り替えることが推奨されます。

ネットワーク構成の問題

NSG（ネットワークセキュリティグループ）のルールがバックエンドへの通信を遮断している場合や、ルーティングテーブルの設定ミスによってパケットが正しく転送されない場合に504エラーが発生します。

特にApplication GatewayやFront Doorを使用する場合、バックエンドのNSGでゲートウェイサブネットからのインバウンドトラフィックが許可されているか、またFront DoorのサービスタグAzureFrontDoor.Backendからのトラフィックが許可されているかを確認する必要があります。

外部依存関係の遅延

バックエンドアプリケーションが外部APIやデータベース、サードパーティサービスに依存している場合、これらの外部サービスの応答遅延が連鎖的に504エラーを引き起こします。アプリケーションは正常に動作していても、依存先のサービスが遅延しているだけでタイムアウトに到達する可能性があります。

Azure Monitorの分散トレーシング（Application Insights）を使用すれば、リクエストが外部依存関係のどの段階で遅延しているかを可視化できます。

---

Azure 504エラーのサービス別対処法

504エラーの対処法は、エラーが発生しているサービスレイヤーによって異なります。ここでは、主要なAzureサービスごとの対処法を解説します。

Application Gatewayの対処法

Application Gatewayで504エラーが発生している場合、バックエンド設定のリクエストタイムアウト値を調整します。Azure Portalで、Application Gatewayのバックエンド設定を開き、「リクエストタイムアウト（秒）」の値をバックエンドの実際の応答時間に合わせて増加させます。

ヘルスプローブの設定も確認が必要です。カスタムヘルスプローブを使用している場合、プローブのタイムアウト値とインターバルが適切か検証してください。プローブパスが200を返すエンドポイントを指しているか、リダイレクトが発生していないかも確認します。

バックエンドサーバー側のタイムアウト設定も、Application Gatewayの設定値と整合させる必要があります。IISの場合はconnectionTimeout属性、nginxの場合はproxy_read_timeoutの値が、Application Gatewayのリクエストタイムアウト値と一致するか、それを超えないように設定します。詳細はMicrosoftのバックエンドヘルストラブルシューティングガイドに記載されています。

Azure Front Doorの対処法

Front Doorで504エラーが発生している場合、まずオリジンレスポンスタイムアウトの設定値を確認します。Standard/Premiumティアでは、Azure PortalまたはAzure CLIでoriginResponseTimeoutを最大240秒まで設定可能です。

断続的な504エラーが発生している場合は、バックエンドWebサーバーのKeepAliveTimeoutを91秒以上に設定してください。Front DoorはバックエンドとのTCP接続を最大90秒間保持するため、バックエンド側のKeepAliveTimeoutが90秒未満だと、Front Doorが再利用しようとした接続が既に切断されている可能性があります。

Apacheの場合はKeepAliveTimeoutディレクティブ、nginxの場合はkeepalive_timeoutディレクティブで設定します。この設定変更により、断続的な504エラーの多くが解消されます。

App Serviceの対処法

App Serviceの230秒ハードリミットに抵触している場合は、アプリケーションの処理を最適化するか、非同期処理パターンに切り替える必要があります。web.configでrequestTimeoutを設定することでアプリケーションレベルのタイムアウトは変更できますが、フロントエンドロードバランサーの230秒制限は変更できません。

長時間処理が必要なケースでは、リクエストを受け付けた段階でジョブIDを返し、バックグラウンドでAzure FunctionsやAzure Queue Storageを使って非同期に処理する設計が推奨されます。クライアントはジョブIDを使ってポーリングで処理結果を取得します。

App Serviceの「Always On」設定を有効にして、アイドルタイムアウトによるコールドスタートを防ぐことも効果的です。コールドスタートが発生すると、最初のリクエストの応答時間が大幅に長くなり、タイムアウトに達しやすくなります。

---

Azure 504エラーのトラブルシューティング手順

504エラーが発生した場合、以下の4つのステップで体系的にトラブルシューティングを進めます。

Step 1 診断ログでタイムアウトの発生箇所を特定する

504エラーの原因を正確に特定するためには、診断ログの有効化が不可欠です。Application Gatewayの場合、診断設定で「アクセスログ」を有効にすると、各リクエストのバックエンド応答時間（timeTaken）が記録されます。この値がリクエストタイムアウトの設定値に近い場合、バックエンドの処理時間が実際にボトルネックになっています。

Front Doorの場合は、アクセスログをAzure Log Analyticsに送信し、originResponseTimeフィールドを確認します。このフィールドの値がタイムアウト設定に近ければ、オリジンの応答遅延が原因です。

Step 2 ヘルスプローブの状態を確認する

Application Gatewayのバックエンドヘルスを確認し、バックエンドプールのメンバーが「正常（Healthy）」であることを検証します。すべてのメンバーが「異常（Unhealthy）」の場合、プローブの設定（パス、タイムアウト、インターバル）を見直します。

プローブパスが正しいHTTPステータス（200）を返しているか、実際にブラウザやcurlでアクセスして確認してください。プローブパスがリダイレクトを返している場合や、認証が必要なパスを指定している場合は、プローブが失敗する原因になります。

Step 3 タイムアウト設定を整合させる

タイムアウトチェーンの各レイヤーの設定値を確認し、整合性を確保します。原則として、バックエンドに近いレイヤーほどタイムアウト値を短く、クライアントに近いレイヤーほど長く設定します。たとえば、バックエンドサーバーのタイムアウトが60秒の場合、Application Gatewayのリクエストタイムアウトは65秒以上に設定するのが適切です。

Azure Network Watcherの接続モニター機能を使えば、ゲートウェイからバックエンドまでのネットワーク遅延も測定できます。ネットワーク遅延が大きい場合は、タイムアウト値にネットワーク遅延分を上乗せする必要があります。

Step 4 バックエンドアプリケーションの性能を調査する

タイムアウト設定に問題がない場合は、バックエンドアプリケーション自体の応答時間を調査します。Application Insightsを導入していれば、リクエストの処理時間、データベースクエリの実行時間、外部API呼び出しの応答時間をリクエスト単位で可視化できます。

データベースクエリが遅い場合はインデックスの最適化やクエリの改善を検討し、外部APIが遅い場合はキャッシュの導入やタイムアウト値の個別設定を検討します。問題が自社のコードではなくAzureインフラにある場合は、Azureサポートに問い合わせてください。

---

Azure 504エラーを未然に防ぐベストプラクティス

504エラーは、適切な設計と運用によって発生頻度を大幅に削減できます。ここでは、実務で効果の高い予防策を4つの観点から解説します。

オートスケール設定の最適化

トラフィックの急増によるバックエンドの過負荷を防ぐために、オートスケール設定を適切に構成することが重要です。Microsoftのオートスケールベストプラクティスでは、スケールアウトとスケールインの両方のルールを必ずセットで設定し、最大インスタンス数と最小インスタンス数の間に十分なマージンを確保することが推奨されています。

実装のアプローチとしては、まず手動スケーリングでベースラインメトリクスを確立し、次にCPU使用率70%でのスケールアウト（+1インスタンス）と30%でのスケールイン（-1インスタンス）を設定するのが基本です。その後、メモリ使用率やリクエスト数なども組み合わせて段階的に最適化していきます。

Azure Monitorアラートの設定

504エラーの発生を早期に検知するため、Azure Monitorでメトリクスアラートを設定します。Application Gatewayの場合は「バックエンド応答ステータス」メトリクスで504を監視し、Front Doorの場合は「オリジンレスポンスステータス」メトリクスで504の発生率を監視します。

アラートの閾値は、過去のベースラインデータに基づいて設定してください。たとえば、504エラーの発生率が全リクエストの1%を超えた場合にアラートを発火させるといった設定が一般的です。Microsoft Sentinelと連携すれば、504エラーの発生パターンをセキュリティインシデントの観点からも分析できます。

タイムアウト設計の原則

タイムアウトチェーンを設計する際は、以下の3つの原則に従います。第1に、バックエンドに近いレイヤーほどタイムアウトを短く設定します。第2に、各レイヤー間にバッファ（5〜10秒）を設けます。第3に、App Serviceの230秒ハードリミットなど、変更不可能な制約を最初に確認し、それを基準に他のレイヤーを設計します。

また、Azureリージョンをまたぐ通信がある場合は、リージョン間の遅延（数十ミリ秒〜数百ミリ秒）もタイムアウト設計に織り込む必要があります。

非同期処理パターンの導入

230秒を超える長時間処理が必要なユースケースでは、同期リクエスト/レスポンスパターンから非同期処理パターンへの切り替えを検討します。リクエスト受付時にジョブIDを即座に返し（HTTP 202 Accepted）、実際の処理はバックグラウンドで実行する設計です。

Azure Queue StorageとAzure Functionsを組み合わせたイベント駆動アーキテクチャが代表的な実装方法です。この設計により、ゲートウェイのタイムアウト制約に抵触することなく、長時間の処理を確実に完了させることができます。Azureのセキュリティ対策の観点からも、非同期処理はタイムアウトによるリトライ攻撃のリスクを軽減する効果があります。

---

Azure 504エラーの注意点と実務での落とし穴

本番環境では問題なく動作していたシステムが、ある日突然504エラーを返すようになった——そんなケースは珍しくありません。負荷テストでは検出できないタイムアウト関連の問題は、特定の条件が揃ったときにだけ顕在化するためです。ここでは、実務で陥りやすい落とし穴を4つ紹介します。

• App Serviceの230秒ハードリミット
  App Serviceのフロントエンドロードバランサーは230秒のハードリミットを持っており、この値はユーザー側では変更できません。Application Gatewayのタイムアウトを300秒に設定していても、バックエンドがApp Serviceであれば230秒で強制的に504エラーが返されます。この制限を見落として、「タイムアウト値を増やしたのに504エラーが解消しない」と悩むケースは非常に多いです。
  
  

• Front DoorのKeepAliveタイムアウト90秒問題
  Azure Front Doorはバックエンドとの接続を最大90秒間保持します。バックエンドのWebサーバー（Apache、nginxなど）のKeepAliveTimeoutが既定値のまま（Apacheは5秒、nginxは75秒）の場合、Front Doorが再利用しようとした接続が既にバックエンド側で切断されており、断続的な504エラーが発生します。この問題はKeepAliveTimeoutを91秒以上に設定するだけで解消しますが、原因の特定が難しい典型的なケースです。
  
  

• ヘルスプローブの応答コード
  ヘルスプローブが200以外のHTTPステータスコード（301リダイレクト、401認証要求など）を返している場合、Application Gatewayはバックエンドを「異常」と判定します。特にHTTPSへのリダイレクトを強制しているアプリケーションで、ヘルスプローブがHTTPでアクセスする設定になっている場合にこの問題が発生します。
  
  

• 診断ログの未有効化
  504エラーの原因特定には診断ログが不可欠ですが、本番環境で診断ログが有効化されていないケースは少なくありません。エラーが発生してから慌てて有効化しても、過去のエラーログは取得できません。Azure Firewallのログと合わせて、Application GatewayとFront Doorの診断ログは本番環境では常時有効にしておくべきです。

過去のAzureの障害事例でも、タイムアウト設定の不整合に起因するサービス障害が複数報告されています。タイムアウトチェーンの設計は、システム全体の可用性に直結する重要な設計要素です。

---

Azureサポートプランの料金比較

504エラーが継続的に発生し自力で解決できない場合や、タイムアウトチェーンの設計に関する専門的な支援が必要な場合には、Microsoftの技術サポートへの問い合わせが有効です。ここでは、2026年3月時点でのAzureサポートプランの料金と特徴を比較します。

以下の表で、5つのサポートプランの違いを整理しました。504エラーのトラブルシューティングでは、Application GatewayやFront Doorの設定最適化、バックエンドの性能調査など、ネットワークレイヤーにまたがる技術支援が必要になることが多いため、Standard以上のプランが推奨されます。

プラン	月額料金	技術サポート	初期応答時間（重大度A）	特徴
Basic	無料	なし（課金・サブスクリプションのみ）	-	セルフサービスのドキュメントとコミュニティフォーラム
Developer	$29/月	メールのみ（営業時間内）	-	開発・テスト環境向け。本番環境には非推奨
Standard	$100/月	電話・メール（24時間365日）	1時間以内	本番環境の基本サポート。504エラー調査対応可
Professional Direct	$1,000/月	電話・メール（24時間365日）+ プロアクティブガイダンス	1時間以内	アーキテクチャレビュー、タイムアウト設計の助言
Unified Enterprise	個別見積もり	全Microsoft製品の統合サポート	15分以内	指定テクニカルアカウントマネージャー

本番環境で504エラーが発生している場合、Standard以上のプランに加入していれば重大度Aとして1時間以内の初期応答が得られます。最新の料金情報はAzureサポートプランの公式ページで確認できます。

---

まとめ

本記事では、Azure 504エラー（Gateway Timeout）の原因と対処法について、7つの発生パターン、サービス別の対処法、体系的なトラブルシューティング手順、そしてベストプラクティスを解説しました。

504エラーはタイムアウトチェーンのいずれかのレイヤーで発生しており、Application Gateway（既定20秒）、Front Door（既定30秒）、App Service（230秒ハードリミット）など、各レイヤーのタイムアウト値を正確に把握することが解決の第一歩です。特にFront DoorのKeepAliveタイムアウト90秒問題やApp Serviceの230秒ハードリミットは、見落としやすい典型的な落とし穴です。

まずはApplication GatewayまたはFront Doorの診断ログを有効化し、504エラー発生時のバックエンド応答時間（timeTakenやoriginResponseTime）を確認してみてください。タイムアウト値に近い値が記録されている場合は、タイムアウト設定の見直しが必要です。230秒を超える処理が必要な場合は、非同期処理パターンへの切り替えを検討してください。

Azure Backupによる定期的なバックアップと、可用性ゾーンを活用した冗長構成を組み合わせることで、504エラーだけでなくシステム全体の可用性を向上させることができます。