WordPress サイトで ERR_TIMED_OUT エラーは PHP メモリ限度超過や PHP-FPM プロセス不足などのサーバーリソースの問題、プラグイン衝突・無限ループ・WP-Cron 過負荷など WordPress 関連問題、max_execution_timeまたはfastcgi_read_timeout設定値が不足、Cloudflare 524エラー、ファイアウォールブロック、DNS遅延などのネットワークおよびインフラストラクチャの問題、外部APIまたはSMTPメールの送信待ちによる応答遅延（ブロッキング）、およびCache Stampede CDN オリジン設定エラーなど、さまざまな原因によって発生します。
この WordPress ブログにアクセスしたときに一時的にERR_TIMED_OUTエラーが表示され、原因を調べて、サーバーにホストされているサイトの1つに特定のIPが異常に過度に接続しようとしたときに、サーバー全体にトラフィックの過負荷が発生したことを確認しました。サーバーを再起動して問題のIPアドレスをブロックするとエラーが解決し、再発防止のためにWordfenceセキュリティプラグインをインストールし、レート制限設定を適用しました。
サーバーの過負荷による WordPress ERR_TIMED_OUTエラーの解決
ERR_TIMED_OUTエラー
ERR_TIMED_OUTは、ブラウザがWebサイトサーバーに要求を送信し、サーバーが応答するまでに時間がかかりすぎて接続がタイムアウトしたことを意味します。
このエラーは、次のようなさまざまな原因が原因で発生します。
- インターネット接続の不安定または遅延
- Webサーバーの過負荷またはダウン
- ファイアウォール・ワクチン・VPN・プロキシ干渉
- DNS設定エラーまたはDNSキャッシュの問題
- ブラウザ拡張プログラムの競合
- 破損したキャッシュ・クッキーデータ
- ネットワーク機器（共有機・モデム）の問題
- ブラウザプラグインの競合
- プラグインの競合または無限ループ
- Windowsシステムサービス/設定の問題
- ネットワークポリシーによるサイトのブロック
サーバーの過負荷によるERR_TIMED_OUTエラー
最近 WordPress ブログにアクセスしようとすると、一時的に次のエラーが発生しました。
このブログは、 クラウドウェイズでホストされていますが、サーバー管理ページ » Monitoringをチェックすると、CPU使用量が突然100％に急増したことが確認できました。
まず、サーバーを再起動すると、問題が解決され、CPU使用率も正常化されました。
これは一時的な措置であるだけなので、正確な原因を把握して適切に対応したいので、ライブチャットに連絡してCPU使用量暴走の原因について聞いてみました。 （質問を韓国語にすると韓国語に、英語にすると英語で答えを与えます。韓国語で質問すると、おそらくAIが自動的に翻訳して英語に伝え、英語の答えを同様に韓国語に自動翻訳するようです。）
クラウドウェイズ担当者によると、CPU急増（Spike）現象は 特定IPの異常な動的要求暴走とサーバの重い処理過程が噛み合って発生したそうです。
サーバー内に10を超えるサイトがあり、そのうちの1つが頻繁に問題を引き起こしています。いくつかの対策である程度最適化しましたが、まだ問題になっています。今回は、49.247.9.21というIP一つが対応するアプリケーション（WordPress サイト）に短時間で膨大な数のリクエストを送り、サーバーダウンにつながりました。
まず、CPU爆症の原因となったIPをブロックしました。これらの措置は短期的に効果がありますが、より原論的な対策が必要なようです。
- 潜在的なリスク： 悪意のあるボットやスクレーパー（データコレクター）は通常 IPを変えて攻撃します。明日別のIPで同じ攻撃が入ると、CPUが再び上昇する可能性があります。
- 補完対策： IPブロックに加えて、 構造防御システムを構築する必要があります。 （クラウドウェイズ担当者の推奨事項）
- Cloudflare WAF設定： そのIPブロックはもちろん、/wp-json/、xmlrpc.phpなど、ボットが頻繁に狙う動的エンドポイントのレート制限（Rate Limiting）やチャレンジ（Cloudflareマネージドチャレンジ）をかけておく必要があります。
- 過度の404要求防御： 存在しないページを突き続ける行為自体も WordPress404ページを動的に生成するためにCPUをたくさん書き込みます。 Cloudflare で 404 のリクエストを多く引き起こすユーザーを自動的にブロックまたは制限するルールを検討してください。
このサイトはクラウドフレアと連動していましたが、「速度制限」措置を取っていなかったため、その攻撃を防ぐことができなかったようです。
「速度制限」を設定する方法として Wordfenceプラグインを利用することも可能であることがわかり、ワードフェンスプラグインをインストールしました。
最後に、Wordfenceのレート制限設定を次のように設定しました。😄
上記の設定について、ジェミナイは次のように分析します。
現在の設定は「最も保守的で安全なSEOに優しい設定」です。しかし、今回経験した「悪性ボットによるCPU急増問題」を解決する観点からは、長所と短所がはっきりしています。
- 利点（安全性）： 本物のユーザーがリンクをクリックするか、通常のクローラが過度にアクセスしたときに誤って「永久にブロック」される仏像を100％予防します。誤診による訪問者の離脱はまったくありません。
- 欠点（CPU防御の制限）： 制限モードは、悪意のあるボットが侵入したときに要求を完全に打ち出すのではなく、 WordPress 内部（PHP）から 「少しだけゆっくり要請してください」と待機戦術を書きます。もし Naver クラウドサーバーのような場所でプログラム（ボット）に毎秒数十回動的クエリを入れると、サーバーはその待機要求をプロセスに尋ねます。 CPUとRAMを使い続けるになります。
もし攻撃が入ってきて効率的に対応できないなら、ジェミナイが推奨するオプションを適用してみようと思います。
- クローラーのページが見つかりません（404）エラー... ➔それからブロックをブロックに変更
- 人のページが見つかりません（404）エラー... ➔それからブロックをブロックに変更
ワードフェンスプラグインはサイトの速度に悪影響を及ぼす可能性があるため、インストールすることを躊躇しましたが、今回の事態を経験しながら問題となるサイトとこのブログにWordfenceをインストールして速度制限設定を指定しました。時間を置いて効果があるかどうかを監視するつもりです。
悪意のあるIPやスパムボット（SEOボット）のためにCPUの急増が頻繁に発生する場合は、次の措置も役立ちます。以下の対策と一緒に Wordfence をインストールして速度制限設定をすると、より効果的に対処ができないかと思います。
コメントを残す