「504 Gateway Timeout」エラーは、サイト所有者や訪問者が遭遇する可能性のある一般的なHTTP 500番台エラーです。WordPressブログやECサイトを運営している場合、この手のサーバーエラーの解決方法を知っておくと非常に便利です。エラーを放置すると、潜在顧客が競合サイトに流れてしまいます。
「504 Gateway Timeout」エラーの場合、発生理由が表示されないため、原因をすぐに特定することができません。そこで今回は、このエラーの詳細を理解して原因を特定し、解決する方法をご紹介します。
以下にご紹介するトラブルシューティングを実行することで、サイトをスムーズに復旧できるはずです。
504エラーの解決法法について動画での解説もご用意しています。
| エラーコード | 504 Gateway Timeout Error |
| エラーの種類 | サーバーサイド |
| バリエーション | 504 Gateway Timeout504 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) |
| 発生原因 | サーバー接続の問題 ネットワーク接続の問題 DNSの問題 ファイアウォールの問題 |
「504 Gateway Timeout」エラーとは
「504 Gateway Timeout」エラーは、リクエストを処理するために必要なアップストリームサーバーから、サーバーが制限時間内に応答を受け取れなかった場合に発生します。これは、アップストリームサーバーが正常に動作していない場合や、高負荷の状態にある場合、または停止している場合などに起こります。
簡単に言うと、HTTP 504エラーは、リクエストの処理に2台のサーバーが関わっている場合に発生します。最初のサーバー（通常はメインサーバー）が、2台目のサーバー（アップストリームサーバー）からの応答を待ち続けた結果、タイムアウトしてしまうのです。
この仕組みを簡単に見てみましょう。ブラウザでサイトにアクセスすると、ブラウザはサイトがホストされているウェブサーバーにリクエストを送信します。ウェブサーバーはそのリクエストを処理し、要求されたリソースをブラウザに返します。
サーバーからのレスポンスには、レスポンスの状態を表すHTTPステータスコードが含まれます。ただし、HTTPステータスコードがすべてエラーメッセージというわけではありません。例えば、ステータスコード「200 OK」は、サーバーが正常にリクエストを処理されたことを意味します。
500番台のステータスコードは、サーバーが何かしらの問題があり、クライアントのリクエストを実行できないことを示します。そのため、「サーバーエラー（5xx）」ステータスコードとも呼ばれます。
500番台には、5種類の公式ステータスコード（500、501、502、503、504）および非公式のステータスコードがあります（506、507、509、520など）。
HTTP 504エラーの見え方は様々ですが、一般に以下のように表示されます。
HTTP 504エラーは、「502 Bad Gateway」エラーに似ています。502エラーは、第1サーバーが第2サーバー（上流サーバー）から無効なレスポンスを受け取ったことを示します。
「504 Gateway Timeout」エラーの種類
HTTP 504エラーは、オペレーティングシステム（OS）、ウェブサーバー、ブラウザ、ユーザーエージェントによって、メッセージの種類が異なります。
一般的なメッセージには、以下のようなものがあります。
- 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
上記のように表記は異なっても、すべて同じHTTP 504エラーを意味します。
ウェブサーバーやサイトでは、HTTP 504エラーの表示を変更することが可能です。ユーザーへの印象を考慮し、以下のように独自のエラーページを用意しておくのも名案です。
「504 Gateway Timeout」エラーの原因
HTTP 504エラーはサーバー間のタイムアウトによって発生するため、多くの場合、原因はクライアント側の端末やインターネット接続にはありません。もちろん、ご自身の端末やネットワーク環境が原因である可能性も低いと言えます。
HTTP 504エラーは、ウェブサーバーが別のサーバーからの応答を長時間待ち続けた結果、タイムアウトしたことを示します。このタイムアウトが発生する理由はさまざまで、応答先のサーバーが正常に動作していない、高負荷の状態にある、あるいは停止していることなどが考えられます。
なお、応答先のサーバーは、必ずしもCDNやAPIゲートウェイなどの外部サーバーとは限りません。リバースプロキシやデータベースサーバーなど、メインのウェブサーバー内部で動作するサーバー機能が応答先となる場合もあります。
「504 Gateway Timeout」エラーがSEOに与える影響
500番台エラーが発生すると、ウェブページが読み込まれなくなるため、ユーザーエクスペリエンスに悪影響を与えます。このため、Googleなどの検索エンジンでは、500番台エラーの発生もランキング要因になっています。エラーが長く続けば、インデックスから削除されてしまう恐れもあります。
例えば、「503 Service Unavailable」エラーはサイトのメンテナンスモードの有効時に使用されることが多いため、Googleのクローラーは一時的なものであると判断し、しばらくしてから再度クロールを行います。
一方、HTTP 504エラーが発生する原因はさまざまで、必ずしも一時的なエラーとは限りません。仮にサイトが数分ダウンし、その間、毎分数回クローラーがエラーに遭遇しても、キャッシュからページを提供しようとするだけで、特に問題にはなりません。
しかし、サイトが6時間以上ダウンしている場合は、サイト全体の深刻な問題とし、早急に解決が必要であると判断します。こうなるとSEOを損なうことになります。
サイトの500番台エラーの監視におすすめのSEOツールは、Google Search Consoleです。
しかし、Google Search Consoleがすべてのエラーを特定できるとは限りません。より徹底した調査には、Sitecheckerのサイトクローラーがおすすめです。
このツールは、500番台エラーを含むサイト上のすべてのエラーを検出するように設計されており、SEOを維持するために修正が必要になる要素の包括的な概要を取得できます。
「504 Gateway Timeout」エラーの解決方法
サーバー構成、サーバープラン、サードパーティ製プラグイン、流入トラフィックなど、WordPressサイトの詳細を正確に把握していなければ、HTTP 504エラーの解決には苦労します。
多くの変数が関係しているため、まずクライアント側でトラブルシューティングを行いましょう。ただし、クライアント側に問題があることは極めてまれです。その後は、サーバーサイドに問題がないかを見ていきます。504エラーの原因は、高確率でサーバー側にあります。
1. ウェブページを再読み込みする
「504 Gateway Timeout」エラーが発生した場合に最初試すべきことは、数分待ってからページを再読み込みすること。
ほとんどのブラウザでキーボードショートカット「F5」を押すと、ウェブページが更新、再読み込みされます。また再読み込みの前にページのブラウザキャッシュをクリアするには、ショートカットコンボ「CTRL+F5」を押します。
また、別のブラウザでサイトを読み込んでみるのも手です。504エラーの多くは、サーバーが一時的な過負荷状態にあった場合がほとんどのため、別のブラウザを使用すればサイトが表示されるはずです。
数分待ってサイトを再読み込みしても504エラーの問題が解決しない場合は、サイトがダウンしているのか、自分の環境に問題があるのかを確認してみてください。Down for Everyone or Just Me、またはIs It Down Right Now?がおすすめです。
2. ネットワーク機器を再起動する
しばしば、モデムやルーターなどのネットワーク機器の問題でHTTP 504エラーが発生します。これらの機器を再起動すると、問題が解決することもあります。
電源を切る順番はどの機器からでも構いませんが、再び電源を入れる順番は重要です。一般的には、インターネット回線から利用中の端末へと接続される順番に従い、インターネットサービスプロバイダ側に近い機器から順に電源を入れてください。
3. プロキシの設定を確認する
プロキシサーバーは、機器とインターネットの間に設置されます。主に、ウェブサイトやウェブサーバーから個人情報（例：機器の位置情報）を隠すことで、オンラインでのプライバシーの強化に使用されます（例：VPNの使用）。
プロキシサーバーがHTTP 504エラーの原因となることは稀ですが、誤ったプロキシサーバーの設定が原因の場合があります。プロキシサーバーを無効にして、ウェブページを再読み込みし、エラーが解決するかを確認してください。
ほとんどのクライアントはプロキシサービスを使用していません。確実に使用していないと言える場合は、この手順をスキップできますが、気づかないうちに設定されている可能性もあります。この原因を確実に排除するため、機器とブラウザのプロキシ設定を確認することをお勧めします。
4. DNSの問題
HTTP 504エラーは、サーバー側、クライアント側、またはその両方の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に変更できます。
Google Public DNS、Cloudflare 1.1.1.1、Quad9 DNS、Cisco OpenDNSのような信頼性の高いDNSサーバーを利用してみるのも手です。
5. サイトの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レスポンスを返すと、独自のHTTP 504エラー画面が表示されます。
この場合、問題はCloudflareではなく、サイトのウェブサーバーにあります。この記事でご紹介している解決策を実行してみるか、ご利用のサーバーサービスのカスタマーサポートに問い合わせてみてください。
Cloudflareの「504 Gateway Timeout」エラー（パターン2）
CloudflareでHTTP 504エラーが発生すると、エラー画面に「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設定方法
6. ウェブサーバーの問題をサーバー会社に問い合わせる
HTTP 504エラーの発生する、最も一般的な理由の1つがサーバーです。ほとんどのWordPressサイトはNginxまたはApacheウェブサーバーでホストされているため、NginxまたはApacheが何らかの応答を待ってタイムアウトしていることになります。
実はKinstaのお客様の多くは、別のWordPress専用サーバーサービスでこの問題に遭遇していたか、解決するためにKinstaに移行を決めており、以下のようなご相談を受けることがあります。
毎月約10万人のアクセスと20万回以上のビューがあって、今は（サーバーサービス名）を利用しているのですが、サーバーの過負荷が原因で504エラーが頻繁に発生しています。（サーバーサービス名）はこれに対して適切な対応を行わず、ただプランのアップグレードが必要としか回答してくれません。でもその必要はないと思うんです
トラフィック量の多いサイトやECサイトでは、キャッシュできないリクエストを多く生成するため、サーバーの過負荷によりHTTP 504エラーが発生しやすくなります。しかし、この問題は、シンプルなブログを含め、どのようなサイトでも発生する可能性があります。多くのサーバー会社では、この問題の解決に上位プランへのアップグレードを勧めますが、ほとんどの場合は不要です。
Kinstaは、各サイトにLXDマネージドホストとオーケストレーションされたLXCソフトウェアコンテナを使用しています。すべてのWordPressサイトは、実行に必要なすべてのソフトウェア（Linux、Nginx、PHP、MySQL）にアクセスできる独自の分離されたコンテナに収容されています。リソースは100％プライベートで、他のサイトや別のお客様のサイトと共有することはありません。
この機能を提供するWordPress向け共用サーバーはほとんどありません。そのため、サイトと同じサーバーにトラフィックの多い別のサイトがあると、HTTP 504エラーが発生する可能性があります。
Kinstaは、各サイトをコンテナに隔離するだけでなく、何千もの同時接続を簡単に処理できるようにインフラを設計しました。またKinstaでは、MySQLデータベースをリモートサーバーではなくローカルホストでホストしています。これは、マシン間のレイテンシーがないことを意味し、その結果、クエリが速くなり、タイムアウトが発生する可能性が低くなります。
Kinstaに移行された多くのお客様のサイトで、全体の読み込み時間が大幅に短縮されています。
サーバーのタイムアウトの原因は、サーバーの過負荷だけではありません。HTTP 504エラーには他にも様々な原因が考えられます。
低速なサーバーインフラ
サイトをホストしているサーバーのリソースが不足していると、アクセス負荷を処理しきれず、HTTP 504エラーが発生することがあります。これは、最新の高画質ゲームを10年前のパソコンで動かそうとするようなものです。
サーバーはリクエストを処理しきれず、応答しなくなってしまいます。この場合は、より高性能なインフラを備えたサーバーへ移行することが根本的な解決策です。そのため、Kinstaでは最も基本的なプランでも、中程度のアクセスがある静的サイトであれば十分に対応できます。
PHPスレッドの不足
PHPスレッドは、WordPressサイトのコードの実行に使用されます。月間5万人の訪問者があるECサイトは、同じトラフィック量のシンプルなブログよりも多くのリソースを必要とします。サーバーのすべてのPHPスレッドがビジーになると、待ち行列ができます。
待ち行列が大きくなりすぎると、サーバーは古いリクエストを無視し、HTTP 504エラーの原因になります。サーバーに問い合わせて、PHPスレッド数を増やしてください。これにより、サイトで複数のリクエストを同時に実行できるようになります。
ファイアウォールの問題
サーバーのファイアウォールに何らかのエラーがあるか、設定が不適切である可能性があります。おそらく、いくつかのルールがサーバーの接続を妨害しています。ファイアウォールが原因かどうかはサーバーのエラーログで確認してください。
ネットワーク接続の問題
プロキシサーバーとウェブサーバー間の接続に問題があると、HTTPリクエストへの応答が遅れる場合があります。また、ロードバランサーを使用している場合は、ロードバランサーのネットワーク接続に問題がある可能性があります。
HTTPタイムアウト
HTTPタイムアウトは、ウェブサーバとクライアント間の接続が長時間、維持された場合に発生します。WordPressサイトでは通常、WordPressのインポートの実行で発生します。この問題を解決する一つの方法は、より高速なインターネット接続への切り替えです。
また、WP-CLIツールを使えば完全にHTTP接続を回避して、サーバー上で直接スクリプトを実行できます。たとえば、wp import WP-CLIコマンドを使えば、WordPress Importerプラグインをコマンドラインインターフェースで直接実行できます。
重要）HTTP 504エラーは「503 Service Unavailable」エラーや「502 Bad Gateway」エラーに似ていますが、別物です。Kinstaをご利用で、HTTP 504エラーに遭遇した場合は、チャットよりカスタマーサポートまで後連絡ください。
サイトの死活監視を行うには、updown.ioのようなツールが便利です。HTTPリクエストを送信することで、定期的にサイト（または任意のURL）の状態をチェックします。チェックの頻度は、15秒から1時間の間で設定可能で、サイトが正しく応答していない場合は、メールやSMSで通知を受け取ることができます。
updown.ioには一部無料で使える機能もありますが、より安価なツールが必要な場合は、WebGazerやUptimeRobotもおすすめです。無料で5分ごとにサイトの動作を監視でき、一般的なサイトではこれで十分です。
サイトを監視することで、どのくらいの頻度でダウンタイムが発生しているかを把握できます。これは特に、共用レンタルサーバーを利用している場合に役立ちます。一方、アプリケーションサーバーやデータベースサーバー、WordPress専用マネージドサーバー（Kinstaなど）では、こうした監視は通常サービス側で自動的に行われます。そのため、このようなマネージドサービスを利用することをおすすめします。
KinstaのWordPress専用マネージドサーバーを利用するメリットはこちらで詳しくご紹介しています。
7. スパム、ボット、DDoS攻撃をチェックする
悪意のある攻撃者は、リソースを要する大量のリクエストを送信することで、ウェブサーバーを停止させます。ボットによるスパム攻撃やDDoS攻撃を受けている場合は、サーバーに負荷がかかり、多くの一般ユーザーで「504 Gateway Timeout」エラーが起きる可能性があります。
サーバーのトラフィックと分析結果を見て、サイトのトラフィックに不規則なパターンがないかを確認してください。Kinstaをご利用の場合は、MyKinstaの分析機能を使用して分析データを簡単に参照できます。
上位のクライアントIPを調べるところから始めましょう。これにより、誰がどこから最大数のリクエストを生成しているかがわかります。サーバーが突然膨大な帯域幅を使用したり、大量の流入トラフィックがある場合、このレポートは非常に便利です。
次に、「キャッシュ分析」レポートを確認します。ここでは、何件のリクエストがキャッシュをバイパスしたか、ミスしたか、あるいはヒットしたかを参照できます。パフォーマンスと安定性の観点からはできるだけ多くのリクエストをキャッシュしたいところですが、必ずしも実現できるわけではありません。
例えば、WooCommerceサイトでは、ショッピングカートや決済機能などでキャッシュできないリクエストが数多く発生します。
最後に、WordPressのセキュリティプラグインを使用して、気になるトラフィックやIPを検出し、ブロックすることで、サイトのセキュリティを強化します。また、サーバー会社に特定のIPをブロックしてもらうのも手です。
攻撃の長さや規模にもよりますが、IPのブラックリスト化は終わりのないプロセスになる可能性があります。多くの攻撃者はブロックされるとIPやプロキシアドレスを変更するためです。
注）Kinstaでは、セキュリティプラグインのインストールを推奨していません。セキュリティプラグインは、特にスキャン機能によってサイトのパフォーマンスに大きな影響を与える可能性があるためです。また、Kinstaではロードバランサーを使用しているため、IPアドレスのブロックが期待どおりに機能しない場合があります。
CloudflareやSucuriなどの専用セキュリティソリューションを使用して、DDoS攻撃やスパムボットからサイトを保護できます。WordPressサイトへのCloudflareのインストール方法やSucuriのDDoS攻撃を阻止する方法をご覧ください。
8. WordPressデータベースの破損を修復する
HTTP 504エラーは、特にWordPressサイトにおいて、データベースの破損が原因で発生する場合があります。一般には、データベースのテーブルやファイルの破損が原因ですが、サイトやデータベースがハッキングされたなど、深刻なセキュリティ上の問題が原因の場合もあります。
破損したWordPressデータベースの修復方法は、問題の内容によって異なります。WP-DBManagerのようなプラグインを使えば、データベースの問題を簡単に診断して修復できます。詳しくは、WordPressデータベースの問題を修復する方法をご覧ください。
9. サイトのプラグインとテーマを確認する
ほとんどの場合、サードパーティ製のプラグインやテーマが504エラーを起こすことはありません。しかし、わずかながらその可能性もあり、これはプラグインやテーマで生成された大量のキャッシュできないリクエストが待ち行列に入ることで発生します。サーバーのPHPスレッドの多くが処理に必要なため、504エラーが発生する可能性があります。
その代表例が、WordPressサイトへのEC機能追加のためにインストールされるWooCommerceプラグインです。
この問題を解決する最も簡単な方法は、すべてのプラグインの無効化です（プラグインを無効化してもデータは失われません）。
管理画面にアクセスできる場合は、「プラグイン」に移動し、一括操作メニューから「無効化」を選択し、すべてのプラグインにチェックを入れ、「適用」をクリックします。これですべてのプラグインが無効化されます。
管理画面にアクセスできない場合は、前述の方法でSFTPを使用してプラグインを無効化できます。プラグインフォルダの名前を変更すると、すべてのプラグインを一括で無効化できます。また、MyKinstaでは、一括操作機能を使用してすべてのプラグインを一度に無効化することも可能です。
すべてのプラグインを無効化したら、サイトが正常に表示されるか確認してください。問題が解消した場合は、プラグインを1つずつ有効化し、その都度サイトの動作を確認して原因となっているプラグインを特定します。
また、プラグイン、テーマ、WordPress本体が最新バージョンに更新されていることも確認してください。Kinsta自動アップデートアドオンを利用すると、このような問題を未然に防ぎやすくなります。設定したスケジュールに従ってプラグインやテーマを自動更新し、更新後にはビジュアルテストを実行して問題の有無を確認します。問題が検出された場合は、サイトを元の状態に自動でロールバックします。
あわせて、推奨されているPHPバージョンを使用していることも確認してください。
ご自身での対応が難しい場合は、サーバー会社にサポートを依頼するのもひとつの方法です。Kinstaでは、Kinsta APMをはじめとする各種診断ツールやトラブルシューティング手法を活用し、エラーの原因となっているプラグインやデータベースクエリ、スクリプトの特定をサポートしています。
また、非効率なデータベースクエリやプラグイン・テーマの不具合などが原因の場合は、WordPress開発者に修正を依頼することも検討してください。
10. エラーログを確認する
エラーログは、WordPressサイトのHTTP 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のロギング関連のドキュメントをご覧ください。
11. 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のリバースプロキシとして使用している場合は、サーバーの設定を調整することでHTTP 504エラーを防止できます。
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 504エラーと同様に、ほかの５００番台エラーもサーバー側で発生するエラーです。例えば、以下のようなものがあります。
- 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」エラーの影響を受けます。今回は、トラブルシューティング方法を包括的にご紹介しました。基本的に、このエラーはサーバー側の問題が原因で発生しますが、その場合はご利用のサーバー会社に問い合わせて速やかに解決してもらうことができるはずです。
しかし、サードパーティ製プラグイン、テーマ、サービス、非効率なデータベースクエリなどが原因になっている可能性もあります。サーバーのリソース（PHPスレッドなど）を最大限利用している場合は、サイトのパフォーマンスを最適化することをおすすめします。
それでもサイトがタイムアウトする場合は、サーバープランをアップグレードするか、PHPスレッドの数を増やす必要があります。今回ご紹介した解決策をすべて試し、それでも解決しない場合には検討してみてください。
シンプルな静的サイトから複雑なECサイトや会員制サイトまで、Kinstaのクラウドサーバーソリューションは、あらゆるサイト向けに設計されています。プランで利用できるサーバーリソースがさらに多く必要になる場合も、オートスケーリング機能でサイトがダウンすることはありません。
Brianの最大の情熱の一つは10年以上使用してきたWordPressです。複数のプレミアムプラグインさえ開発しています。Brianの趣味はブログや映画やハイキングなどです。TwitterでBrianとつながりましょう。
