サイトで「504 Gateway Timeout」エラーを解決する方法

「504 Gateway Timeout」エラーは、サイト所有者や訪問者が遭遇する可能性のある一般的なHTTP 500番台エラーです。WordPressブログやECサイトにおいて、このようなサーバーエラーの解決方法を知っておくことは非常に有益です。エラーを放置してしまうと、潜在顧客が競合サイトに流れてしまいます。

「504 Gateway Timeout」エラーは、発生理由が表示されないことから、原因をすぐに特定できないのが厄介です。そこでこの記事では、エラーの詳細を理解して原因を特定し、解決する方法をご紹介していきます。

以下にご紹介するトラブルシューティングを実行することで、すぐにサイトを復旧できるはず。

「504 Gateway Timeout」エラーとは

ブラウザでウェブサイトにアクセスすると、ブラウザはサイトをホストしているウェブサーバーにリクエストを送信します。サーバーはリクエストを処理し、要求されたリソースを返します。

サーバーからのレスポンスには、レスポンスの状態を表すHTTPステータスコードが含まれます。ただし、HTTPステータスコードがすべてエラーメッセージというわけではありません。例えば、ステータスコード「200 OK」は、サーバーが正常にリクエストを処理されたことを意味します。

HTTPステータスコードの500番台は、サーバーが何かしらの問題があり、クライアントのリクエストを実行できないことを示します。そのため、「サーバーエラー（5xx）」ステータスコードとも呼ばれます。

500番台には、5種類の公式ステータスコード（500、501、502、503、504）および非公式のステータスコードがあります（506、507、509、520など）。

Internet Engineering Task Force（IETF）では、「504 Gateway Timeout」エラーを次のように定義しています。

504（Gateway Timeout）ステータスコードは、ゲートウェイまたはプロキシとして動作しているサーバーが、リクエストの完了のためにアクセスする必要のある上流サーバーから、適時に応答を受信できなかったことを示す

簡単に説明すると、このエラーは1つのリクエスト処理に2つのサーバーが関与する場合に発生します。第1サーバー（通常はメインサーバー）が、第2サーバー（上流サーバー）からの応答を待っている間に、タイムアウトが発生しているのが原因です。

「504 Gateway Timeout」エラーの見え方はさまざまですが、以下のように表示されるのが一般的です。

「504 Gateway Timeout」エラーは、「502 Bad Gateway」エラーに似ており、このエラーは第1サーバーが第2サーバー（上流サーバー）から無効なレスポンスを受け取ったことを示します。

「504 Gateway Timeout」エラーメッセージの種類

「504 Gateway Timeout」エラーは、オペレーティングシステム、ウェブサーバー、ブラウザ、ユーザーエージェントによって、メッセージの種類が異なります。

一般的なメッセージには、以下のようなものがあります。

• 504 Gateway Timeout
• 504 Gateway Timeout NGINX
• NGINX 504 Gateway Timeout
• Gateway Timeout Error
• Error 504
• HTTP Error 504
• HTTP Error 504 — Gateway Timeout
• HTTP 504
• 504 Error
• Gateway Timeout (504)
• This page isn’t working — Domain took too long to respond
• 504 Gateway Time-out — The server didn’t respond in time
• A blank white screen

このように表記は異なりますが、これらはすべて同じ「504 Gateway Timeout」エラーを示しています。

ウェブサーバーやサイトでは、「504 Gateway Timeout」エラーの表示を変更することが可能です。ユーザーへの印象を考慮し、以下のようにおしゃれなページを用意しておくのも良いアイデアです。

「504 Gateway Timeout」エラーがSEOに与える影響

500番台エラーが発生すると、ウェブページが読み込まれなくなるため、ユーザーエクスペリエンスに悪影響を与えます。このため、Googleなどの検索エンジンでは、500番台エラーの発生もランキング要因になっています。エラーが長く続けば、インデックスから削除されてしまう恐れもあります。

例えば、「503 Service Unavailable」エラーはサイトのメンテナンスモードの有効時に使用されることが多いため、Googleのクローラーは一時的なものであると判断し、しばらくしてから再度クロールを行います。

一方で「504 Gateway Timeout」エラーが発生する原因はさまざまで、必ずしも一時的なエラーとは限りません。仮にサイトが数分ダウンし、その間、毎分数回クローラーがエラーに遭遇しても、キャッシュからページを提供しようとするだけで、特に問題にはなりません。

しかし、サイトが6時間以上ダウンしている場合は、サイト全体の深刻な問題とし、早急に解決が必要であると判断します。こうなるとSEOを損なうことになります。

Google Search Consoleは、サイトのHTTP 500番台エラーの監視におすすめのSEOツールです。

しかしながら、Google Search Consoleがすべてのエラーを特定できるとは限りません。より徹底した調査には、Sitecheckerのサイトクローラーをおすすめすます。

このツールは、HTTP 500番台エラーを含むサイト上のすべてのエラーを検出するように設計されており、SEOを維持するために修正が必要になる要素の包括的な概要を取得できます。

「504 Gateway Timeout」エラーの原因

504エラーはサーバー間のタイムアウトが原因であり、クライアントの機器やインターネット接続に原因がある可能性は低いです。また、ローカルの機器や接続にも問題はないはずです。

「504 Gateway Timeout」エラーは、ウェブサーバーが他のサーバーからの応答を長く待ち続け、「タイムアウト」したことを示します。このタイムアウトには、他のサーバーが正しく機能していない、過負荷が生じている、ダウンしているなど、様々な理由が考えられます。

他のサーバーは必ずしも外部である（例：CDN、APIゲートウェイ）必要はありません。メインのウェブサーバー内のエンティティの場合もあります（例：リバースプロキシサーバー、データベースサーバー）。

「504 Gateway Timeout」エラーの解決方法

サーバー構成、ホスティングプラン、サードパーティ製プラグイン、流入トラフィックなど、WordPressサイトの詳細を正確に把握していなければ、「504 Gateway Timeout」エラーの解決には苦労します。

多くの変数が関係しているため、まずクライアント側でトラブルシューティングを行いましょう。ただし、クライアント側に問題があることは極めてまれです。その後は、サーバーサイドに問題がないかを見ていきます。504エラーの原因は、高確率でサーバー側にあります。

ウェブページを再読み込みする

「504 Gateway Timeout」エラーが発生した場合に最初試すべきことは、数分待ってからページを再読み込みすること。

ほとんどのブラウザでキーボードショートカット「F5」を押すと、ウェブページが更新、再読み込みされます。また再読み込みの前にページのブラウザキャッシュをクリアするには、ショートカットコンボ「CTRL+F5」を押します。

また、別のブラウザでサイトを読み込んでみるのも手です。504エラーの多くは、サーバーが一時的な過負荷状態にあった場合がほとんどのため、別のブラウザを使用すればサイトが表示されるはずです。

数分待ってサイトを再読み込みしても504エラーの問題が解決しない場合は、サイトがダウンしているのか、自分の環境に問題があるのかを確認してみてください。「Down for Everyone or Just Me」または「Is It Down Right Now?」がおすすめです。

ネットワーク機器を再起動する

しばしば、モデムやルーターなどのネットワーク機器の問題で「504 Gateway Timeout」エラーが発生します。これらの機器を再起動すると、問題が解決することもあります。

電源を切るのは任意の順番でOKですが、電源を入れる順序は重要です。一般には「外側から内側」─インターネットサービスプロバイダからメインのクライアント機器へ接続順に電源を入れてください。

プロキシの設定を確認する

プロキシサーバーは、機器とインターネットの間に設置されます。主に、ウェブサイトやウェブサーバーから個人情報（例：機器の位置情報）を隠すことで、オンラインでのプライバシーの強化に使用されます（例：VPNの使用）。

プロキシサーバーが504エラーの原因となることは稀ですが、誤ったプロキシサーバーの設定が原因の場合があります。プロキシサーバーを無効にして、ウェブページを再読み込みし、エラーが解決するかを確認してください。

ほとんどのクライアントはプロキシサービスを使用していません。確実に使用していないと言える場合は、この手順をスキップできますが、気づかないうちに設定されている可能性もあります。この原因を確実に排除するため、機器とブラウザのプロキシ設定を確認することをお勧めします。

DNSの問題

「504 Gateway Timeout」エラーは、サーバーサイドまたはクライアントサイド、またはその両方のDNSの問題によっても発生します。

サーバー側のDNSの問題で最も可能性が高い原因は、FQDN（完全修飾ドメイン名）が正しいIPアドレスを解決していない、またはDNSサーバーが応答していない場合です。通常は、WordPressサイトを新しいサーバーやホストに移行した直後に発生します。したがって、ドメインのDNSレコードが完全に伝播するまで待つことが重要です。伝播には最大24時間かかる場合があります。

無料ツールの「whatsmydns.net DNS Checker」や「DNSMap」を使用して、DNSが世界中に伝搬したかを確認できます。

クライアント側のDNSの問題を解決するには、ローカルのDNSキャッシュをクリアしてみてください。ブラウザキャッシュと似ていますが、ここではOSのDNSキャッシュをクリアします。

Windowsを使用している場合、コマンドプロンプトを開き、以下のコマンドを実行して、DNSキャッシュをクリアします。

ipconfig /flushdns

正常に動作すると、「DNSリゾルバーキャッシュは正常にフラッシュされました」というメッセージが表示されます。

最新のmacOSバージョンの場合は、ターミナルを開いて以下のコマンドを実行します。

sudo killall -HUP mDNSResponder

プロセスが終了してもmacOSでは何の通知も表示されません。これを変更するには、コマンドにメッセージを追加してください。

sudo killall -HUP mDNSResponder; DNS Cache was cleared successfully

古いmacOSバージョンを使用している場合、実行するコマンドはmacOSのバージョンによって異なります。詳細はこちらをご覧ください。

Linux OSを使用している場合は、コマンドラインインターフェースとしてターミナルを使用していて、手順はmacOSとよく似ています。しかし、Linuxには多くのディストリビューションがあるため、実行するコマンドはディストリビューションごとに異なる場合があります。詳細についてはこちらをご覧ください。

最後に、クライアント側のDNSサーバーを一時的に変更できます。デフォルトでは、ISPがDNSサーバーを自動的に割り当てます。これを一時的にパブリックDNSのIPに変更できます。

テストで利用可能な、信頼できるDNSサーバーとしては、Google Public DNS、Cloudflare 1.1.1.1、Quad9 DNS、Cisco OpenDNSがあります。

サイトのCDNを一時的に無効化する

場合によっては、コンテンツデリバリネットワーク（CDN）に問題があるケースもあります。サイトの元のサーバーにアクセスできない場合、ほとんどのCDNはキャッシュからウェブページ全体を提供しようとしますが、多くの場合、この機能はデフォルトで有効にされていません。なぜなら、ほとんどのサイトで、動的なアセット（例：WordPressの管理画面）のキャッシュは複雑なためです。

この問題を解決する簡単な方法は、CDNの一時的な無効化です。例えば、無料のCDN Enablerを使用してサイトのアセットをCDNのURLにリンクしている場合は、プラグインを無効にして、サイトの再読み込みをテストします。

CDNの接続に他のプラグインを使用している場合も同様です（例：WP Rocket、Breeze、W3 Total Cache）。

サイトの管理画面にアクセスできない場合は、SFTP経由でプラグインのフォルダ名を変更すればプラグインを無効化できます。

フルプロキシサービスを提供するCloudflareやSucuriのようなCDNは、エッジサーバーと元のサーバーの間に追加のファイアウォールを設置します。このため、これらのCDNを利用すると、HTTP 5xxエラーが多く発生する可能性があります。ほとんどのCDNは、元のサーバーから返された5xxエラーをキャッシュするため、問題解決は容易です。

Cloudflareの無料プランでは、500番台エラーが発生しやすくなっています。Cloudflareはフルプロキシサービスのため、無効化する簡単な方法はありませんが、Cloudflareの504エラーには2種類あります。

Cloudflareの「504 Gateway Timeout」エラー1

Cloudflareでは、サイトの元のサーバーが標準のHTTP 504レスポンスを返すと、独自の「504 Gateway Timeout」エラー画面が表示されます。

この場合、問題はCloudflareではなく、サイトのウェブサーバーにあります。この記事でご紹介している解決策を実行してみるか、ご利用のホスティングサービスのカスタマーサポートに問い合わせてみてください。

Cloudflareの「504 Gateway Timeout」エラー2

Cloudflareで「504 Gateway Timeout」エラーが発生すると、エラー画面に「cloudflare」と表示されます。これは現在のすべてのCloudflareアセットの標準的なサーバー名です。通常、エラー画面は以下のように表示されます。

Cloudflare自体に反応がないため、Cloudflare独自のエラー画面は表示されません。

Cloudflareはすでにこの問題を認識し、対応している可能性が高く、これはCloudflare System Statusで確認可能です。またはより迅速に解決するには、Cloudflareのカスタマーサポートに連絡してみてください。

大量のアップロードに起因するCloudflareでの「504 Gateway Timeout」エラー

サイトにアップロードするファイルのサイズも、サーバータイムアウトの原因になります。Cloudflareでは、HTTP POSTリクエストごとのアップロードファイルのサイズを無料プラン、Proプランともにわずか100MBに制限しています。

この問題は、ホスト側に原因がある場合と、Cloudflareに原因がある場合があります。DNSのhostsファイルでCloudflareをバイパスし、再度アップロードを試すことで、正確な原因を見つけられます。

WordPressでCloudflareを使用している場合は、同社の無料プラグインを使用し、重要なURLをキャッシュから除外することをお勧めします（例：WordPressの管理画面）。あわせて、WordPressサイト向けのCloudflareの設定方法もご覧ください。

解説記事「WordPressのためのCloudflare APO設定方法」もお勧めです。

ウェブサーバーの問題をホスティング会社に問い合わせる

「504 Gateway Timeout」エラーの発生する、最も一般的な理由の1つがサーバーです。ほとんどのWordPressサイトはNginxまたはApacheウェブサーバーでホストされているため、NginxまたはApacheが何らかの応答を待ってタイムアウトしていることになります。

実はKinstaのお客様の多くは、別のWordPressホスティングサービスでこの問題に遭遇していたか、解決するためにKinstaに移行を決めており、以下のようなご相談を受けることがあります。

毎月約10万人のアクセスと20万回以上のビューがあって、今は（ホスティングサービス名）を利用しているのですが、サーバーの過負荷が原因で504エラーが頻繁に発生しています。（ホスティングサービス名）はこれに対して適切な対応を行わず、ただプランのアップグレードが必要としか回答してくれません。でもその必要はないと思うんです

トラフィック量の多いサイトやECサイトでは、キャッシュできないリクエストを多く生成するため、サーバーの過負荷により504エラーが発生しやすくなります。しかし、この問題は、シンプルなブログを含め、どのようなサイトでも発生する可能性があります。多くのホスティング会社では、この問題の解決に上位プランへのアップグレードを勧めますが、ほとんどの場合は不要です。

Kinstaは、各サイトにLXDマネージドホストとオーケストレーションされたLXCソフトウェアコンテナを使用しています。すべてのWordPressサイトは、実行に必要なすべてのソフトウェア（Linux、Nginx、PHP、MySQL）にアクセスできる独自の分離されたコンテナに収容されています。リソースは100％プライベートで、他のサイトや別のお客様のサイトと共有することはありません。

この機能を提供するWordPress向け共用サーバーはほとんどありません。そのため、サイトと同じサーバーにトラフィックの多い別のサイトがあると、504エラーが発生する可能性があります。

Kinstaは、各サイトをコンテナに隔離するだけでなく、何千もの同時接続を簡単に処理できるようにインフラを設計しました。またKinstaでは、MySQLデータベースをリモートサーバーではなくローカルホストでホストしています。これは、マシン間のレイテンシーがないことを意味し、その結果、クエリが速くなり、タイムアウトが発生する可能性が低くなります。

Kinstaに移行された多くのお客様のサイトで、全体の読み込み時間が大幅に短縮されています。

サーバーのタイムアウトの原因は、サーバーの過負荷だけではありません。504エラーには他にも様々な原因が考えられます。

低速なサーバーインフラ

WordPressサイトのホストに使用しているサーバーに、負荷を処理するだけの十分なリソースがない可能性があります。これは10年前のPCで最新のグラフィックを駆使したビデオゲームをプレイするようなものです。

サーバーはウェブサイトを提供しようとして単純にハングアップしています。この問題の唯一の解決策は、より良いインフラを持つサーバーへのアップグレードです。この理由からKinstaでは、最も基本的なWordPressホスティングプランでさえ、中程度のトラフィックの静的サイトを処理できるようになっています。

ワーカープロセスの不足

ワーカープロセスは、WordPressサイトのコードの実行に使用されます。月間5万人の訪問者があるECサイトは、同じトラフィック量のシンプルなブログよりも多くのリソースを必要とします。サーバーのすべてのワーカープロセスがビジーになると、待ち行列ができます。

待ち行列が大きくなりすぎると、サーバーは古いリクエストを無視し、「504 Gateway Timeout」エラーの原因になります。ホスティング会社に問い合わせて、ワーカープロセス数を増やしてください。これにより、サイトで複数のリクエストを同時に実行できるようになります。

ファイアウォールの問題

サーバーのファイアウォールに何らかのエラーがあるか、設定が不適切である可能性があります。おそらく、いくつかのルールがサーバーの接続を妨害しています。ファイアウォールが原因かどうかはサーバーのエラーログで確認してください。

ネットワーク接続の問題

プロキシサーバーとウェブサーバー間の接続に問題があると、HTTPリクエストへの応答が遅れる場合があります。また、ロードバランサーを使用している場合は、ロードバランサーのネットワーク接続に問題がある可能性があります。

HTTPタイムアウト

HTTPタイムアウトは、ウェブサーバとクライアント間の接続が長時間、維持された場合に発生します。WordPressサイトでは通常、WordPressのインポートの実行で発生します。この問題を解決する一つの方法は、より高速なインターネット接続への切り替えです。

また、WP-CLIツールを使えば完全にHTTP接続を回避して、サーバー上で直接スクリプトを実行できます。たとえば、wp import WP-CLIコマンドを使えば、WordPress Importerプラグインをコマンドラインインターフェースで直接実行できます。

重要）「504 Gateway Timeout」エラーは「503 Service Unavailable」エラーや「502 Bad Gateway」エラーに似ていますが、すべて異なるエラーです。Kinstaのお客様で、504エラーに遭遇した場合は、カスタマーサポートまでチャットにてご報告ください。

サイトの死活監視を行うには、「updown.io」のようなツールが便利です。HTTPリクエストを送信することで、定期的にウェブサイト（または任意のURL）の状態をチェックします。チェックの頻度は、15秒から1時間の間で設定可能で、サイトが正しく応答していない場合は、メールやSMSで通知を受け取ることができます。

updown.ioには一部無料で使える機能もありますが、より安価なツールが必要な場合は「WebGazer」や「UptimeRobot」もおすすめです。無料で5分ごとにサイトの動作を監視でき、一般的なサイトではこれで十分です。

これにより、サイトがダウンする頻度を把握することができます。これは、共用サーバーをお使いの方には特に有用です。なお、ほとんどのマネージドWordPressホスティングでは、このようなツールなしで死活監視が自動的に行われます（マネージドホスティングをお勧めする理由の1つ）。

マネージドWordPressホスティングの重要性はこちらでご紹介しています。

スパム、ボット、DDoS攻撃

悪意のある攻撃者は、リソースを要する大量のリクエストを送信することで、ウェブサーバーを停止させます。ボットによるスパム攻撃やDDoS攻撃を受けている場合は、サーバーに負荷がかかり、多くの一般ユーザーで「504 Gateway Timeout」エラーが起きる可能性があります。

サーバーのトラフィックと分析結果を見て、サイトのトラフィックに不規則なパターンがないかを確認してください。Kinstaをご利用の場合は、MyKinstaの分析機能を使用して分析データを簡単に参照できます。

上位のクライアントIPを調べるところから始めましょう。これにより、誰がどこから最大数のリクエストを生成しているかがわかります。サーバーが突然膨大な帯域幅を使用したり、大量の流入トラフィックがある場合、このレポートは非常に便利です。

次に、「キャッシュ分析」レポートを確認します。ここでは、何件のリクエストがキャッシュをバイパスしたか、ミスしたか、あるいはヒットしたかを参照できます。パフォーマンスと安定性の観点からはできるだけ多くのリクエストをキャッシュしたいところですが、必ずしも実現できるわけではありません。

例えば、WooCommerceストアでは、ショッピングカートやチェックアウトプロセスなどの機能に対して、多くのキャッシュできないリクエストが生成されます。

最後に、WordPressのセキュリティプラグインを使用して、気になるトラフィックやIPを検出し、ブロックすることで、サイトのセキュリティを強化します。また、ホスティング会社に特定のIPをブロックしてもらうのも手です。

攻撃の長さや規模にもよりますが、IPのブラックリスト化は終わりのないプロセスになる可能性があります。多くの攻撃者はブロックされるとIPやプロキシアドレスを変更するためです。

注意）Kinstaでは、お客様によるWordPressのセキュリティプラグインのインストールを許可していません。これは、プラグインのスキャン機能がサイトのパフォーマンスに大きな影響を与えるためです。KinstaではGoogle Cloud Platformでロードバランサーを使用しているため、IPをブロックしても意図した動作にならない可能性があります。

CloudflareやSucuriなどの専用セキュリティソリューションを使用して、DDoS攻撃やスパムボットからサイトを保護できます。WordPressサイトへのCloudflareのインストール方法やSucuriのDDoS攻撃を阻止する方法をご覧ください。

WordPressデータベースの破損

「504 Gateway Timeout」エラーは、特にWordPressサイトにおいて、データベースの破損が原因で発生する場合があります。一般には、データベースのテーブルやファイルの破損が原因ですが、サイトやデータベースがハッキングされたなど、深刻なセキュリティ上の問題が原因の場合もあります。

破損したWordPressデータベースの修復方法は、問題の内容によって異なります。WP-DBManagerのようなプラグインを使えば、データベースの問題を簡単に診断して修復できます。詳しくは、WordPressデータベースの問題を修復する方法をご覧ください。

サイトのプラグインとテーマを確認する

ほとんどの場合、サードパーティ製のプラグインやテーマが504エラーを起こすことはありません。しかし、わずかながらその可能性もあり、これはプラグインやテーマで生成された大量のキャッシュできないリクエストが待ち行列に入ることで発生します。サーバーのワーカープロセスの多くが処理に必要なため、504エラーが発生する可能性があります。

その代表例が、WordPressサイトへのEC機能追加のためにインストールされるWooCommerceプラグインです。

この問題を解決する最も簡単な方法は、すべてのプラグインの無効化です（プラグインを無効化してもデータは失われません）。

管理画面にアクセスできる場合は、「プラグイン」に移動し、一括アクションメニューから「無効化」を選択し、すべてのプラグインにチェックを入れ、「適用」ボタンを押します。これですべてのプラグインが無効化されます。

管理画面にアクセスできない場合は、上述した方法でSFTP経由でプラグインを無効化できます。メインのプラグインフォルダ名を変更するだけで、すべてのプラグインを一括して無効化できます。

すべてのプラグインを無効化したら、サイトが正しく読み込まれるかを確認します。正常に動作した場合は、プラグインを一つずつ有効化しながら、サイトをテストする必要があります。

最後に、プラグイン、テーマ、WordPressコアが最新の状態であることを確認してください。また、推奨されているバージョンのPHPでサーバーが動作していることも確認してください。

これらの作業を行うのにあまりに手間がかかる、というような状況であれば、お使いのホスティングサービスに問い合わせてサポートを受けてください。Kinstaでは、New Relicやその他のトラブルシューティング技術を使用して、エラーの原因となるプラグイン、クエリ、スクリプトの絞り込みをお手伝いしています

プラグインやテーマの非効率なクエリや、質の低いコードが原因となっている深刻な状況では、信頼できるWordPress開発者に解決を依頼することをおすすめします。

エラーログを確認する

エラーログは、WordPressサイトの504エラーをトラブルシューティングし、デバッグする際に非常に役立ちます。エラーログを参照することで、サイトの問題、特に必須のプラグインが原因である場合に素早く切り分けできます。

Kinstaのお客様であれば、MyKinstaのログビューアでエラーを簡単に確認できます。

利用しているホスティングサービスがロギングツールを提供していない場合は、「wp-config.php」ファイルに以下のコードを追加し、WordPressのデバッグモードを有効化してください。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG定数は、WordPressのデバッグモードを有効化/無効化します。この定数には、オプションで機能を拡張する2つの似た定数があります。WP_DEBUG_LOG定数は、すべてのエラーを/wp-content/ディレクトリ内の「debug.log」ファイルに保存するように指示します。このファイルが見つからない場合は、いつでも作成できます。

WP_DEBUG_DISPLAY定数は、デバッグログをHTMLページに表示するかどうかを制御します。この定数をfalseに設定すると、すべてのエラーが表示されなくなりますが、WP_DEBUG_LOGをtrueに定義すれば、後でエラーを確認できます。

重要）KinstaでWP_DEBUGを有効にするとと、すべてのエラーが「error.log」ではなく「debug.log」ファイルにルーティングされます。

また、WordPressの生のエラーログファイルはSFTPでもダウンロードできます。通常、エラーログはサーバーのルートディレクトリの「logs」フォルダにあります。

MyKinstaからもWordPressデバッグモードを有効化できます。「サイト」＞「ツール」に移動して、「WordPressデバッグ」セクションの「有効化」をクリックしてください。これでSSHやSFTPでデバッグモードを有効化しなくても、PHPのエラーや通知を参照することができます。

最後に、サーバーのログファイルを確認します。ご利用のウェブサーバーによりますが、基本的には以下の場所にあります。

• Apache：/var/log/apache2/error.log/
• Nginx：/var/log/nginx/error.log/

詳細は、ApacheやNginxのロギング関連のドキュメントをご覧ください。

ApacheやNginxを適切に設定する

サーバーの構成ファイルを編集して、特定のディレクティブのリソース制限を増やします。これにより、「504 Gateway Timeout」エラーを解決できます。

Apacheウェブサーバー

まず、「httpd.conf」に以下のコードを追加します。

TimeOut 600

この設定は、サーバがネットワークタイムアウトの問題としてマークするまでの、リクエストに対する待ち時間を定義します。初期値は60秒です（Apacheバージョン2.4の場合）。

このディレクティブは、.htaccessファイルではなく、「httpd.conf」ファイルにのみ追加できます。ほとんどの共用サーバーは、「httpd.conf」ファイルの変更を許可していないため、代わりに「.htaccess」ファイルでLimitRequestBodyディレクティブの値を増やしてください。

次に、「php.ini」ファイルに以下の行を追加してください。

max_execution_time 300

PHPのmax_execution_timeディレクティブのデフォルト値は30秒です。これを増やすと、サイトのPHPスクリプトの実行時間を長く設定できます。

Nginxウェブサーバー

WordPressサイトをNginx+FastCGI Process Manager（PHP-FPM）で運用している場合や、NginxをApacheのリバースプロキシとして使用している場合は、サーバーの設定を調整することで「504 Gateway Timeout」エラーを防止できます。

Nginx+FastCGI（PHP-FPM）での「504 Gateway Timeout」エラー

まず、PHP-FPMプール設定ファイルを編集する必要があります。このファイルは、Nginxサーバの/etc/php7.4/fpm/pool.d/www.confにあります（正確なパスはPHPのバージョンによって異なります）。また、ターミナルで以下のコマンドを実行しても、PHP-FPMプール設定ファイルを編集できます。

sudo nano /etc/php/7.2/fpm/pool.d/www.conf

次に、以下のディレクティブを設定します。

request_terminate_timeout = 300

この後、「php.ini」ファイルを編集する必要があります。ファイルの場所は、/etc/php.iniです。このファイルを開き、max_execution_timeディレクティブの値を300秒に追加、または変更します。

max_execution_time = 300

最後に、「nginx.conf」ファイルのlocationブロックに以下のコードを追加します。

location ~ .php$ {
...
fastcgi_read_timeout 300;
}

NginxとPHP-FPMをリロードして、変更を有効にします。

sudo service nginx reload
sudo service php7.4-fpm reload

PHP-FPMを再読み込みする正確なコードは、サーバーにインストールされているPHPのバージョンによって異なります。サイトをテストして、問題が修正されたかを確認してください。

Nginxプロキシでの「504 Gateway Timeout」エラー

ApacheのリバースプロキシサーバーとしてNginxを使用している場合は、「nginx.conf」ファイルに以下のディレクティブを追加することで、サーバーのタイムアウトを緩められます。

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

変更後は、忘れずにNginxを再読み込みしてください。

sudo service nginx reload

「504 Gateway Timeout」エラーに類似したHTTPエラー

この記事の前半で触れた通り、その他のHTTP 500番台エラーの多くは、サーバーサイドで発生するため、「504 Gateway Timeout」エラーに似ています。例えば、以下のようなものが挙げられます。

• 500 Internal Server Error
• 501 Not Implemented Error
• 502 Bad Gateway Error
• 503 Service Unavailable Error

「404 Not Found」エラーのようなクライアント側の問題で発生するものも、504エラーと同様です。各HTTPステータスコードの解説はこちらをご覧ください。

まとめ

WordPressサイトは様々な理由により「504 Gateway Timeout」エラーの影響を受けます。今回は、トラブルシューティング方法を包括的にご紹介しました。基本的に、このエラーはサーバー側の問題が原因で発生しますが、その場合はご利用のホスティング会社に問い合わせて速やかに解決してもらうことができるはずです。

しかし、サードパーティ製プラグイン、テーマ、サービス、非効率なデータベースクエリなどが原因になっている可能性もあります。サーバーのリソース（ワーカープロセスなど）を最大限利用している場合は、サイトのパフォーマンスを最適化することをおすすめします。

それでもサイトがタイムアウトする場合は、ホスティングプランをアップグレードするか、ワーカープロセスの数を増やす必要があります。今回ご紹介した解決策をすべて試し、それでも解決しない場合には検討してみてください。

シンプルな静的サイトから複雑なECサイトや会員制サイトまで、Kinstaのホスティングソリューションは、あらゆるサイト向けに設計されています。プランで利用できるサーバーリソースがさらに多く必要になる場合も、オートスケーリング機能でサイトがダウンすることはありません。

WordPressサイトの「504 Gateway Timeout」エラーの解決方法について、ご質問がありましたら以下のコメント欄でお知らせください。