WordPressの管理画面に「外部と通信できない」という警告が出てしまう……。有料プラグインのライセンス認証がなぜか通らない……。
サイトの開発用のステージング環境で、2026年10月上旬にこうした現象が起こりました。サイト側の設定は変えておらず、サーバー会社からの障害情報もありません。それでも、WordPressから外のサービスへの通信だけが、半日以上にわたって失敗し続けました。
調べた結果、原因はサーバーの故障でも、サイトの不具合でもありませんでした。サーバー上に「使い終わったあとも動き続けていた作業用のプログラム」がたまり、サーバーが1つの契約に割り当てている処理枠を使い切っていたのです。開発用の環境で起きたことですが、同じ条件がそろえば本番のサイトでも起こります。この記事では、この事例を一般化して、同じ症状が出たときに何を疑い、どう確認すればよいかをまとめます。
チェックポイント
- WordPressの「サイトヘルス」で、WordPress.orgへの接続やループバック（自分自身への通信）が失敗する症状でした。表示されたのは「cURL error 6」というエラーです。
- 原因は、共用サーバーが1契約あたりに設けている「同時に動かせる処理の数」の上限に達していたことです。サーバー側の障害や設定変更ではありませんでした。
- 上限を使い切っていたのは、サーバー上で作業するためのツールが、作業終了後も終了されずに数十個残っていたためです。
- 不要なプログラムを止めただけで、サイトやデータベースには一切手を加えずに復旧しました。
- 同じ症状が出たら、サーバー会社に問い合わせる前に「自分たちが動かしているものが残っていないか」を確認する価値があります。
何が起きていたのか
WordPressは、サイトを表示する以外にも、さまざまな場面でインターネット上の他のサービスと通信しています。本体やプラグインの更新確認、有料プラグインのライセンス認証、管理画面の自己診断機能「サイトヘルス」などがその例です。今回の環境では、こうした通信がすべて同じエラーで失敗していました。
| 失敗していた操作 | 表示されていた内容 |
|---|---|
| 有料プラグインのライセンス認証 | 認証サーバーに接続できない旨のエラー |
| サイトヘルス「WordPress.orgへの接続」 | cURL error 6: getaddrinfo() thread failed to start |
| サイトヘルス「ループバックリクエスト」 | 同上 |
cURL（カール）は、WordPressを動かすPHPが外部と通信するときに使う部品です。getaddrinfo（ゲットアドレスインフォ）は、「wordpress.org」のような名前から実際の接続先（IPアドレス）を調べる処理を指します。エラー文を直訳すると「接続先を調べる作業員（スレッド）を起こせなかった」という意味で、「接続先が見つからない」「回線が切れている」とは別の状態です。
同じサーバー会社の別のサーバーで動くサイトでは同じ操作が正常だったため、サイトやプラグインではなく、このサーバー上のPHP全体に何かが起きていると絞り込めました。
原因は「同時に動かせる処理の数」の上限
共用のレンタルサーバーは、1台を多くの契約者で分け合っています。そのため、1つの契約が同時に動かせるプログラムの数（正確にはスレッドの合計数）に上限が設けられています。たとえるなら、契約ごとに「作業員の席」が決まった数だけ用意されている状態です。WordPressが外部と通信するときは、この席から作業員を1人呼んで接続先の調査を任せます。
今回は、この席がほぼ埋まっていました。埋めていたのは、サーバー上で保守作業を行うために起動したコマンドライン型のツールです。作業が終わった後も終了されず、数十個が数日間動き続けていました。1つあたり十数〜数十席を占めるため、合計では上限を超える数になっていたのです。席が空いていないので、WordPressが「作業員を1人お願いします」と頼んでも断られ、エラーになっていました。
なぜ気づきにくかったのか
- サーバーの上限は、Webサイトを動かすPHPと、管理者がSSHでログインして使う環境とで別々に設定されていることがあります。今回はSSH側の上限のほうが大きく、コマンドラインから通信テストをすると成功しました。そのため「サーバーは正常」に見えてしまいました。
- 作業用のツールは、手元のパソコンの画面では「終わった作業」に見えても、サーバー側のプログラムは明示的に終了するまで動き続けるものがあります。
- エラー画面に接続先のIPアドレスが表示されていたため、「名前の解決はできている」と誤解しやすい状況でした。実際には、その情報は別の経路で取得されたもので、WordPress本体の通信はその手前で止まっていました。
どう調べたか：変更を加えない確認を先に
原因が分からない段階で設定を変えたり、プラグインを入れ直したりすると、問題を広げるおそれがあります。今回はまず、サーバーに一切変更を加えない「読み取りのみ」の確認を4項目行い、結果を突き合わせました。
| 確認項目 | 結果 | 分かったこと |
|---|---|---|
| 契約内で動いているプログラムの一覧 | 作業用ツールが数十個、最長で約8日間動き続けていた | WordPress側のPHPに滞留はなく、別のものが枠を使っている |
| 同時処理数の上限値 | Web側のPHPの上限が、SSH側より低い | 現在の使用量がWeb側の上限を超えていた |
| コマンドラインのPHPから外部へ通信 | 成功 | PHPやcURLのプログラム自体は壊れていない |
| curlコマンドから外部へ通信 | 成功 | ネットワークや名前解決の仕組みは正常 |
通信の部品そのものは正常で、使用量だけが上限を超えている。この2つがそろったことで、「Web側のPHPだけが席不足で失敗している」と判断できました。
対応と結果
対応は、1日以上動き続けていた作業用のプログラムに終了の合図を送ることだけでした。WordPressの設定、データベース、サイトのファイル、メールには触れていません。終了後、契約全体の使用量は上限の6割程度まで下がり、サイトヘルスの2つのエラーは消えました。ライセンス認証も通る状態に戻りました。
サーバー会社への問い合わせは行いませんでした。上限の値は共用サーバーとして標準的なもので、サーバー側の変更や障害はなかったためです。問い合わせていれば「お客様側の処理が上限に達しています」という回答になっていたと考えられます。原因が自分たちの使い方にある場合、問い合わせは解決を早めるどころか、復旧までの時間を延ばしてしまいます。
速やかに確認しておくこと
- サイトヘルスを開く。WordPress管理画面の「ツール」→「サイトヘルス」で、「WordPress.orgへの接続」「ループバックリクエスト」に問題が出ていないかを見ます。ここが失敗していると、更新の確認や通知が止まっている可能性があります。
- サーバー上で動かしているものを棚卸しする。自社や制作会社がサーバー上で使っている常駐ツール、バッチ処理、作業用のコマンドライン環境を一覧にします。「誰が」「何のために」「いつ止めるか」が決まっていないものは、止める手順を決めます。
- 作業後に終了する運用を決める。サーバー上で作業するツールは、作業が終わったら明示的に終了・アーカイブすることを手順に含めます。「同時に開いておく数」の目安も決めておくと、積み重なりを防げます。
- 問い合わせの前に自分側を確認する。外部通信のエラーが出たら、サーバー会社に連絡する前に、上記の棚卸しリストに照らして「残っているものはないか」を確認します。障害情報が出ていない場合は、特にこの順番が有効です。
- 保守会社との連絡ルートを確認する。サイトの保守を外部に任せている場合、サーバーへのログイン権限を持つ担当者が誰か、緊急時にどこへ連絡するかを確認しておきます。調査には、サーバーに入って状況を読み取れる人が必要です。
おわりに
「サーバーが悪いのではないか」と疑いたくなる症状でも、原因は自分たちの使い方にあることがあります。今回は、サイトにもサーバーにも手を加えず、不要なプログラムを止めるだけで復旧しました。大切なのは、原因が分かるまで設定を変えないこと、そして「サーバー上で何を動かしているか」を把握しておくことです。
エディトルでは、WordPressサイトの保守として、更新やバックアップのほか、サイトヘルスの確認やサーバー上の状態把握も行っています。他社で制作されたサイトの保守のみのご依頼もお受けしています。保守で何をしているかは、サイトの保守費は何に使われているのかでも紹介しています。「管理画面に見慣れない警告が出ている」「原因が分からないエラーが続いている」といった場合は、お気軽にお問い合わせください。