「504 Gateway Timeout」エラーは、ウェブサイトの所有者や訪問者が目にする最も一般的なHTTP 500番台エラーの1つです。多くのWordPressブログやECサイトにおいて、このようなサーバーエラーの修正方法を知っておくことは非常に重要です。放置すると苦労して獲得したお客様が競合サイトに流れてしまいます。
「504 Gateway Timeout」エラーは発生した理由を通知しないため、サーバータイムアウトの原因の特定は困難です。この記事では、エラーの詳細を理解し、原因を診断し、修正する方法を学びます。
ここで紹介する様々な解決策をすべて試してみれば、すぐにサイトを再開できるはずです。
では、はじめましょう！
「504 Gateway Timeout」エラーとは何か？
ブラウザでウェブサイトにアクセスすると、ブラウザはサイトをホストしているウェブサーバーにリクエストを送信します。サーバーはリクエストを処理し、要求されたリソースを返します。
サーバーからの応答には、多くのHTTPステータスコードのうちの1つが含まれ、ブラウザへ応答の状態を表します。ただし、HTTPステータスコードのすべてがエラーではありません。例えば、「200 OK」ステータスコードは、サーバーが正常にリクエストを処理し、「すべて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エラーメッセージのバリエーションを示します。
- 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番台エラーを深刻に受け取ります。エラーが長く続けば、検索エンジンの検索結果からウェブページのインデックスを削除する場合もあります。
例えば、Googleスパイダーは「503 Service Unavailable」エラーに遭遇した場合、このエラーはサイトのメンテナンスモードの有効時に使用することが多いため、一時的な問題であるとみなします。このため、後でそのページを再びクロールしようとします。
一方「504 Gateway Timeout」エラーは、複数の理由で発生する可能性があり、必ずしも一時的なエラーではありません。仮にサイトが数分ダウンし、その間、スパイダーが毎分何度かクロールしてエラーに遭遇しても、キャッシュからページを提供しようとするだけで、特に問題にはなりません。
しかし、サイトが6時間以上ダウンしている場合、Googleは504エラーをサイト全体の深刻な問題であり、早急に修正する必要があると判断します。これはSEOにマイナスの影響を与えます。
Google Search Consoleは、ウェブサイトのHTTP 500番台エラーの監視に最適なSEOツールの1つです。
「504 Gateway Timeout」エラーの原因
504エラーはサーバー間のタイムアウトが原因であり、おそらく問題はクライアントの機器やインターネット接続ではありませんし、ローカルの機器や接続にも問題ありません。
「504 Gateway Timeout」エラーは、ウェブサーバーが他のサーバーからの応答を長く待ち続け、「タイムアウト」したことを示します。このタイムアウトには、他のサーバーが正しく機能していない、過負荷である、ダウンしているなど、様々な理由が考えられます。
他のサーバーは必ずしも外部である（例：CDN、APIゲートウェイ）必要はありません。メインのウェブサーバー内のエンティティの場合もあります（例：リバースプロキシサーバー、データベースサーバー）。
「504 Gateway Timeout」エラーの修正方法
サーバー構成、ホスティングプラン、サードパーティ製プラグイン、流入トラフィックなど、WordPressサイトの詳細を正確に把握していなければ、「504 Gateway Timeout」エラーの修正には苦労します。
多くの変数が関係しているため、まずクライアント側の問題の解決から始めてください。ただしこれはかなり稀なケースです。次にサーバー側での解決を試みます。504エラーの原因は、たいていサーバー側にあります。
ウェブページを再読み込みしてみる
「504 Gateway Timeout」エラーが発生した場合に最初試すべき対策の1つが、数分待ってからページを再読み込みすることです。
ほとんどのブラウザでキーボードショートカット「F5」を押すと、ウェブページを更新、再読み込みします。また再読み込みの前にページのブラウザキャッシュを削除するには、代わりにショートカットコンボ「CTRL+F5」を押します。
また、別のブラウザでサイトを読み込んでみても問題を絞り込めます。504エラーの多くは、サーバーが一時的な過負荷状態にあった場合がほとんどのため、この方法を使えばサイトが表示されるはずです。
数分待ってサイトを再読み込みしても504エラーの問題が解決しない場合は、他の人もダウンしているのか、自分だけがダウンしているのかを確認してください。サイトのダウンタイムのテストに便利なオンラインツールに「Down for Everyone or Just Me」と「Is It Down Right Now?」の2つがあります。
ネットワーク機器を再起動する
しばしば、モデムやルーターなどのネットワーク機器の問題で「504 Gateway Timeout」エラーが発生します。これらの機器を再起動すると、問題が解決する場合があります。
ネットワーク機器は順番に関係なく電源を切れますが、電源を入れる順番は重要です。一般には「外側から内側」、インターネットサービスプロバイダからメインのクライアント機器へ接続順に電源を入れていきます。
プロキシの設定を確認する
プロキシサーバーは、機器とインターネットの間に設置されます。主に、ウェブサイトやウェブサーバーから個人情報（例：機器の位置情報）を隠すことで、オンラインでのプライバシーの強化に使用されます（例：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のバージョンによって異なります。詳細については、Kinstaの「フラッシュDNSチュートリアル」内の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 WordPressプラグインを使用してサイトのアセットをCDNのURLにリンクしている場合は、プラグインを無効にして、サイトの再読み込みをテストします。
CDNの接続に他のプラグインを使用している場合も同様です（例：WP Rocket、Breeze、W3 Total Cache）。
サイトの管理画面にアクセスできない場合は、SFTP経由でプラグインのフォルダ名を変更すればプラグインを無効化できます。
フルプロキシサービスを提供するCloudflareやSucuriのようなCDNは、エッジサーバーと元のサーバーの間に追加のファイアウォールを設置します。このため、これらのCDNを利用すると、HTTP 5xxエラーが多く発生する可能性があります。ほとんどのCDNは元のサーバーから返された5xxエラーをキャッシュするため、問題解決は容易です。
Cloudflareの無料プランでは、500番台エラーが発生しやすくなっています。残念ながら、これはフルプロキシサービスのため、無効化する簡単な方法はありません。しかし、そのことでCloudflareを悪く言う前に、Cloudflareが「504 Gateway Timeout」エラーの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の管理画面）。Kinstaブログの解説記事「WordPressのためのCloudflareの詳細な設定方法」をご覧ください。
解説記事「WordPressのためのCloudflare APO設定方法」もお勧めです。
サーバーの問題をホスティング会社と確認する
「504 Gateway Timeout」エラーの発生する、最も一般的な理由の1つがサーバーです。ほとんどのWordPressサイトはNginxまたはApacheウェブサーバーでホストされているため、NginxまたはApacheが何らかの応答を待ってタイムアウトしていることになります。
多くのお客様は、他の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ホスティングプランでさえ、中程度のトラフィックの静的サイトを処理できるようになっています。
PHPワーカープロセスの不足
PHPワーカープロセスは、WordPressサイトのコードの実行に使用されます。月間5万人の訪問者があるECサイトは、同じトラフィック量のシンプルなブログよりも多くのリソースを必要とします。サーバーのすべてのPHPワーカープロセスがビジーになると、待ち行列ができます。
待ち行列が大きくなりすぎると、サーバーは古いリクエストを無視し、「504 Gateway Timeout」エラーの原因になります。ホスティング会社にPHPワーカープロセス数の追加を依頼してください。これにより、サイトで複数のリクエストを同時に実行できるようになります。
ファイアウォールの問題
サーバーのファイアウォールに何らかのエラーがあるか、設定が不適切である可能性があります。おそらく、いくつかのルールがサーバーの接続を妨害しています。ファイアウォールが原因かどうかは、サーバーのエラーログで確認してください。
ネットワーク接続の問題
プロキシサーバーとウェブサーバー間の接続に問題があると、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ホスティングの重要性に関するKinstaの記事をご覧ください。
スパム、ボット、DDoS攻撃
悪意のある攻撃者は、リソースを要する大量のリクエストを送信することで、ウェブサーバーを停止させます。ボットによるスパム攻撃やDDoS攻撃を受けている場合は、サーバーに負荷がかかり、多くの一般ユーザーで「504 Gateway Timeout」エラーが起きる可能性があります。
サーバーのトラフィックと分析結果を見て、サイトのトラフィックに不規則なパターンがないかを確認してください。サイトのホスティングにKinstaを使用している場合は、MyKinstaの分析ダッシュボードを使用して分析データを簡単に参照できます。
上位のクライアントIPを調べるところから始めてください。これにより、誰が、どこから最大数のリクエストを生成しているかがわかります。サーバーが突然膨大な帯域幅を使用したり、大量の流入トラフィックがある場合、このレポートは非常に便利です。
次に、「キャッシュ分析」レポートを確認します。ここでは、何件のリクエストがキャッシュをバイパスしたか、ミスしたか、あるいはヒットしたかを参照できます。パフォーマンスと安定性の観点からはできるだけ多くのリクエストをキャッシュしたいところですが、必ずしも実現できるわけではありません。
例えば、WooCommerceのサイトでは、ショッピングカートやチェックアウトプロセスなどの機能に対して、多くのキャッシュできないリクエストが生成されます。
最後に、WordPressのセキュリティプラグインを使用して、気になるトラフィックやIPを検出し、ブロックすることで、ウェブサイトのセキュリティを強化します。また、特定のIPをブロックするようホスティング会社に依頼できます。
攻撃の長さや規模にもよりますが、IPのブラックリスト化は終わりのないプロセスになる可能性があります。多くの攻撃者はブロックされるとIPやプロキシアドレスを変更するためです。
注意：Kinstaでは、お客様によるWordPressのセキュリティプラグインのインストールを許可していません。プラグインのスキャン機能がサイトのパフォーマンスに大きな影響を与えるためです。また、KinstaではGoogle Cloud Platformでロードバランサーを使用しているため、IPをブロックしても意図した動作にならない可能性があります。
CloudflareやSucuriなどの専用セキュリティソリューションを使用して、DDoS攻撃やスパムボットからサイトを保護できます。詳細については、Kinstaの記事「WordPressサイトへのCloudflareのインストール方法」や「SucuriのDDoS攻撃を阻止した方法」をご覧ください。
破損したWordPressデータベース
「504 Gateway Timeout」エラーは、特にWordPressサイトにおいて、データベースの破損が原因で発生する場合があります。一般には、データベースのテーブルやファイルの破損が原因ですが、サイトやデータベースがハッキングされたなど、深刻なセキュリティ上の問題が原因の場合もあります。
破損したWordPressデータベースの修復方法は、問題の内容によって異なります。WP-DBManagerのようなプラグインを使えば、データベースの問題を簡単に診断して修復できます。まず最初に、Kinstaの詳細な解説記事「WordPressデータベース問題の修復」をお読みください。
サイトのプラグインとテーマを確認する
ほとんどの場合、サードパーティ製のプラグインやテーマが504エラーを起こすことはありません。しかし、わずかながらその可能性もあり、これはプラグインやテーマで生成された大量のキャッシュできないリクエストが待ち行列に入ることで発生します。サーバーのPHPワーカープロセスの多くが処理に必要なため、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を有効にすると、すべてのエラーは、MyKinstaの「error.log」ではなく、「debug.log」ファイルにルーティングされます。
また、WordPressの生のエラーログファイルはSFTPでもダウンロードできます。通常、エラーログはサーバーのルートディレクトリの「logs」フォルダにあります。
Kinstaユーザーは、MyKinstaからもWordPressデバッグモードを有効化できます。「サイト」>「ツール」>「WordPressデバッグ」に移動し、「有効化」ボタンをクリックします。この方法であればSSHやSFTPでデバッグモードを有効化しなくても、PHPのエラーや通知を参照できます。
最後に、サーバーのログファイルを確認します。WordPressサイトのホストにどのサーバーを使用しているかによりますが、一般には以下の場所にあります。
- 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 300PHPの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 reloadPHP-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」エラーのようなクライアント側の問題で発生する他のHTTPエラーも504エラーと同様です。Kinstaの詳細な解説記事とHTTPステータスコードのリストをご覧ください。
まとめ
WordPressサイトは様々な理由により「504 Gateway Timeout」エラーの影響を受けます。この記事では、それらすべてのトラブルシューティング方法を学びました。一般に、このエラーはサーバー側の問題が原因で発生しますが、この場合はホスティング会社に連絡して迅速に解決できます。
しかし、サードパーティ製のプラグイン、テーマ、サービス、非効率なデータベースクエリ、または、これらの2つ以上の組み合わせが原因の場合もあります。サーバーのリソース（例：PHPワーカープロセス）を最大限利用している場合は、サイトのパフォーマンスを最適化することを推奨します。
それでもウェブサイトがタイムアウトする場合は、ホスティングプランやPHPワーカープロセスの数をアップグレードする必要があります。ただしこのオプションは、この記事で説明した他の解決策をすべて試した後で、検討することをお勧めします。
シンプルな静的サイトから複雑なECサイトや会員制サイトまで、Kinstaのホスティングプランはあらゆるタイプのウェブサイト向けに設計されています。ホスティングプランで提供されるサーバーリソースより多くを必要とする場合も、Kinstaのオートスケール機能により、サイトは常に稼働し続けます。
何か書き忘れはありませんか？WordPressサイトの「504 Gateway Timeout」エラーを解決できない場合は、以下にコメントをお寄せください。
コメントを残す