WordPressを運用してみると、500 Internal Server Errorやホワイトスクリーン（ホワイトスクリーン）などのエラーに遭遇することがあります。問題を解決するには、まず原因を特定する必要があります。 WordPressの場合、wp-config.phpファイルでWP_DEBUGをtrueに変更してデバッグモードを有効にすると、PHPエラーまたは警告メッセージが画面に表示されることがあります。ただし、デバッグモードを有効にしても白い画面が表示されたり、エラーメッセージが表示されないことがあります。
デバッグモードをオンにしてもエラー履歴を確認できない場合や、エラーメッセージが表示されても致命的なエラーに関する内容がない場合は、 WordPress 自体（コア・プラグイン・テーマ）の問題ではなく、サーバー環境（メモリー制限、PHP設定、.htaccess、タイムアウトなど）側の問題である確率が高いです。
参考としてクラウドウェイズを利用する場合は、該当するアプリケーション管理ページでエラーログとアクセスログを確認できます。 （👉 クラウドウェイズ WordPress エラーログの確認方法 参考）
WordPress wp-config.php デバッグモードをオンにしてもエラーログが表示されない場合
最近、Vultr HestiaCP環境の1つ WordPress ブログでInternal Server Errorの問題が発生したため、問題を解決しました。
まず、 WordPress 接続パスを特定した後、wp-config.phpファイルでデバッグモードを有効にしてエラーメッセージを確認しようとしました。ただし、画面にエラーメッセージは表示されず、エラーログをファイルとして保存するように設定してもログファイル自体は生成されませんでした。
WordPressに問題が発生した場合は、通常、エラーログを最初に確認して原因を推定してください。通常、致命的なエラーが発生したポイントを推測できるメッセージがログに残りますが、メッセージが残らないことがあります。このような場合には手がかり自体がないため、原因把握が容易ではなく、問題解決もそれだけ幕を閉じるしかありません。
デバッグモードを有効にしてもエラーメッセージも、ログもまったく残っていない場合、問題 WordPress（PHPコード）レベルではなく、それより前のWebサーバーレベルで発生している可能性が高いです。
エラーの発生位置が 'WordPress「ではなく」「Webサーバー」の場合
デバッグモードが沈黙する最も一般的で致命的な理由は、当初エラーが WordPress（PHP）に到達する前に発生した可能性があります。 WordPressのWP_DEBUGは、プラグインのクラッシュ、テーマミス、PHP関数のエラーなど WordPress 内部の問題だけをつかむことができます。
そのサーバーのアクセスログを確認してみると、ClaudeBotまたは セムラッシュボット 同じクローラボットが短時間で過度に接続し、サーバーに負荷を引き起こしているようです。このようにトラフィックが集中すると、サーバーのCPU・メモリリソースが枯渇し、PHP-FPMワーカープロセスが要求を正常に終了できず、タイムアウトしたり強制終了することがあります。この場合、PHPのエラーハンドラが介入する機会さえないため、 WordPressでデバッグモードを有効にしてもエラーメッセージが表示されなかったと推定されています。
画面出力オプション（WP_DEBUG_DISPLAY）
多くの場合、WP_DEBUGのみがtrueに設定されていても、ほとんどの環境では画面出力オプション（WP_DEBUG_DISPLAY）がtrueに設定され、画面にエラーが出力されます。
define( 'WP_DEBUG', true );運用中のサイトでは、訪問者にエラーコードが公開されないように、以下のように明示的にfalseに指定して画面露出をブロックし、代わりに/wp-content/debug.logファイルに静かに記録するようにすることが安全です。
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );デバッグモードをTrueに設定しても画面にエラーが表示されず、ログファイルも生成されない場合、これは出力オプションの問題ではありません WordPressこの設定を適用する時点に達する前に問題が発生したか、サーバーレベルで関連設定が強制的に制限されている可能性を疑ってください。
サーバーレベルのセキュリティ設定（php.ini）介入
HestiaCP、CyberPanelなどのサーバーコントロールパネルを使用したり、ホスティング会社のセキュリティ設定が厳しい環境では、PHP-FPMプール設定でphp_admin_value[display_errors] = offまたはphp_admin_flag [display_errors] = offの形でエラー出力が強制されます。
一般的なphp.iniまたは.htaccess設定の場合 WordPressがWP_DEBUG_DISPLAYを介して内部的に実行されるini_set（）呼び出しでいくらでも上書きできますが、php_admin_value / php_admin_flagで指定された設定はシステムレベルに固定され、実行時にどのコードにも変更できません。
したがって、このような場合、wp-config.phpでいくら画面にエラーを浮かべるように命令しても、これより上位権限を持つPHP-FPMプール設定がこれを源泉的に抑制してしまうのです。
正しい原因を特定して対処する方法
WordPress デバッグモードで原因が見つからない場合は、以下の順序でサーバー自体を確認してください。
- Webサーバーのエラーログ直接確認： WordPressではなく、NginxまたはApacheのerror.logファイルを確認する必要があります。 （例：/var/log/nginx/domains/domain.error.log）ここにupstream timed outのようなメッセージが残っている場合は、PHP-FPM応答の遅延によるタイムアウトです。
タイムアウトメッセージの代わりにrecv() failedやConnection reset by peerなどのメッセージが表示された場合、PHP-FPMワーカープロセスが予期せず終了した可能性があります。この場合、メモリ不足（OOM）が原因であることを確認するには、dmesgコマンドや/var/log/kern.log（またはjournalctl -k）などのカーネルログを一緒に確認する必要があります。 Out of memory: Killed process などの履歴がある場合は、サーバーリソース (メモリ) の問題で確定できます。 - サーバー設定のアップレギュレーション： コントロールパネルやSSHを介してPHPのmemory_limit、max_execution_timeなどを十分に（例えば512M、300秒）増やしてサーバーリソースを増やします。
- 悪意のあるボットトラフィックのブロック： エラーの根本的な原因がトラフィックの過負荷である場合、サーバーの仕様を高めるだけでは不足する可能性があります。 Cloudflare WAF（Webファイアウォール）などを活用して、サーバーリソースを食い止める不要なAIクローラーやスクレーパーのアクセスを事前にブロックすることを強制できます。
問題のサイトでは、サーバーレベルでアクセスログを確認し、SSHにエラーログを表示させることで問題の原因を特定しようとしました。
Webサーバーコントロールパネルを使用しない一般的なLinux（Ubuntu/ Debian、CentOSなど）環境のNginxの場合、デフォルトでは次のパスで接続ログとエラーログファイルを確認できます。
- 接続ログ：/var/log/nginx/access.log
- エラーログ：/var/log/nginx/error.log
ただし、複数のドメインを運用している場合は、このグローバルパスの代わりに /etc/nginx/sites-available/ などにある個々のドメイン設定ファイルにログパスが別々に指定されている可能性があるため、その設定を一緒に確認することをお勧めします。 （Apacheを使用している場合は、/var/log/apache2/error.logのようにパス自体が異なります。）
ヘスティアCPを使用している場合は、次のSSHからのコマンドで最新のエラーログ50行が表示されます。
tail -n 50 /var/log/nginx/domains/example.com.error.log
エラーログや接続ログなどをチェックして問題の原因を特定して対応できます。サーバーを直接運用している場合は、原因の原因を特定して対応するのが容易ではない可能性があります。
👉 WordPress またはWebホスティング関連のトラブルシューティングに問題がある場合 ここでサービス（有料）をご依頼することができます。
FAQ（質問と回答）
Q1. WP_DEBUGをtrueに設定すると、サイト訪問者にエラーメッセージが表示されますか？
はい、WP_DEBUG を true に設定すると WP_DEBUG_DISPLAY のデフォルト値も true なので、別途ブロックしないとサイトにアクセスするすべての訪問者にエラーメッセージがそのまま公開されます。運用中のサイトであれば、WP_DEBUG_DISPLAYをfalseに、WP_DEBUG_LOGをtrueに設定して画面には見えず、ログファイルにのみ記録されるようにすることが安全です。
Q2. debug.logファイルはどこに作成されますか？
WP_DEBUG_LOGをtrueに設定すると、デフォルトで WordPress ルートディレクトリベースの/wp-content/debug.logパスに作成されます。このパスにファイルが生成されない場合は、wp-contentディレクトリの書き込み権限の問題、または本文で扱ったようにエラーが発生します。 WordPress コードに到達する前（Webサーバーレベル）で発生している可能性を疑ってください。
Q3.デバッグモードはトラブルシューティング後に再びオフにする必要がありますか？
はい、原因を特定したら、WP_DEBUGを再びfalseに戻す必要があります。デバッグモードをオンにしておくと、debug.logファイルに警告メッセージまで蓄積され続けてファイル容量が増える可能性があり、WP_DEBUG_DISPLAYまでtrueのままになるとセキュリティ上の脆弱性が発生します。
Q4.私のサーバーがHestiaCPなのかCyberPanelなのか、どうすればわかりますか？
最も簡単な方法は、サーバー管理者のログインページのURLまたはポートを確認することです。 HestiaCPは通常8083ポート、CyberPanelは8090ポートを管理ページとして使用します。ホスティング会社やサーバーを設定してくれた担当者に問い合わせて確認する方法もあります。
Q5. Cloudflareなしでクローラボットトラフィックを防ぐ方法はありませんか？
Cloudflareを使用していない環境では、robots.txtに特定のボットのアクセスを制限するように指定するか（強制性はありません）、サーバーの.htaccessまたはNginx設定でUser-Agentに基づいて特定のボットからの要求をブロックする方法、またはfail2banなどのツールで過度の要求頻度を示すIPを自動ブロックする方法
WordPress レベルでは、Wordfenceなどのセキュリティプラグインをインストールして対応することも可能です。
Q6.このようなサーバーレベルの問題は WordPress 初心者でも自分で解決できますか？
ログファイルを開いて閲覧すること自体は誰でも可能ですが、PHP-FPMプール設定の変更、カーネルログの分析、サーバーリソースのアップコンディションなどは、SSHアクセスとLinuxサーバーの基本的な理解が必要な作業です。自分で解決するのが難しい場合は、ホスティング会社のテクニカルサポートチームにログの内容をキャプチャしてお問い合わせください。
参考までに クラウドウェイズを使用する場合は、ライブチャットを通じて WordPress 問題とサーバーの問題の両方に問い合わせることができます。ライブチャットで支援を要請する際に韓国語で入力することができ、質問の一番上や一番最後に「人間相談士に演奏してください。」と追加すれば人間エージェントと会話が可能です。 （相談内容をハングルで入力すると、AIが知って双方向言語に翻訳するようです。）
コメントを残す