WordPress の管理画面で、プラグイン更新、テーマ更新、サイトヘルス、翻訳更新などが失敗する場合、原因は WordPress 本体だけにあるとは限りません。特に WordPress を Kubernetes 上で動かしている場合は、Pod、Node、DNS、Proxy、Firewall、外部ネットワークを分けて確認する必要があります。
この記事では、WordPress が wordpress.org に接続できない時の切り分け方を整理します。単に「WordPress の通信エラー」と見るのではなく、どの層で止まっているのかを順番に見ます。
発生する症状
典型的には、WordPress 管理画面で次のような問題として見えます。
- プラグインやテーマの更新情報を取得できない
- WordPress 本体の更新確認に失敗する
- サイトヘルスで REST API や外部通信の警告が出る
wordpress.orgやapi.wordpress.orgへの接続に失敗する- コンテナ内からは名前解決できるが、HTTPS 接続で止まる
ここで重要なのは、管理画面上のエラーだけでは原因が分からないことです。WordPress は最終的な結果だけを表示するため、DNS で失敗しているのか、TCP 接続で失敗しているのか、TLS で失敗しているのか、Firewall で落とされているのかを別途確認する必要があります。
WordPress が wordpress.org に接続する場面
WordPress は、管理画面の裏側で複数の外部通信を行います。代表的なのは、更新確認、プラグイン情報の取得、テーマ情報の取得、翻訳ファイルの取得です。
| 用途 | 主な接続先 | 確認したいこと |
|---|---|---|
| 本体更新 | api.wordpress.org | HTTPS で到達できるか |
| プラグイン情報 | api.wordpress.org | WordPress Pod から名前解決と接続ができるか |
| テーマ情報 | api.wordpress.org | 外部向け通信が Firewall で止まっていないか |
| 翻訳ファイル | downloads.wordpress.org | DNS、TLS、Proxy 経由の通信が成立するか |
そのため、単一の URL だけでなく、WordPress が実際に使う複数の宛先を前提に切り分けます。
切り分けるレイヤー
Kubernetes 上の WordPress では、切り分ける場所を明確にします。WordPress 管理画面で失敗しているからといって、すぐに PHP やプラグインを疑うと遠回りになることがあります。
| レイヤー | 確認すること |
|---|---|
| WordPress | サイトヘルス、更新画面、プラグインの通信エラー |
| Pod | コンテナ内から DNS 解決と HTTPS 接続ができるか |
| Node | Kubernetes ノードから外部へ通信できるか |
| DNS | A / AAAA レコード、内部 DNS、外部 DNS、DoH の影響 |
| Proxy | 環境変数、透過 Proxy、外部通信の経路 |
| Firewall | 外向き TCP/443、IPv4 / IPv6、クラウド側の通信制御 |
Pod から確認する
まず、WordPress の Pod 内から確認します。アプリケーションが実際に動いている場所で確認しないと、Node では通るが Pod では通らない、という差分を見落とします。
コマンド
kubectl -n wordpress-ext-system get pod
kubectl -n wordpress-ext-system exec -it deploy/wordpress -- sh
getent hosts api.wordpress.org
curl -Iv https://api.wordpress.org/
curl -Iv https://downloads.wordpress.org/ここでは、名前解決、TCP 接続、TLS ハンドシェイク、HTTP 応答をまとめて見ます。curl -I だけで分からない場合は、-v を付けてどこで止まっているかを確認します。
Node から確認する
Pod で失敗した場合でも、すぐに WordPress の問題とは限りません。次に Kubernetes ノードから同じ宛先へ接続できるかを確認します。
コマンド
getent hosts api.wordpress.org
curl -Iv https://api.wordpress.org/
curl -Iv https://downloads.wordpress.org/Node からは通るが Pod からは通らない場合、Kubernetes の CNI、NetworkPolicy、Pod の DNS 設定、Proxy 環境変数、コンテナイメージ内の CA 証明書などを疑います。Node からも通らない場合は、より外側の Firewall、Proxy、DNS、回線側の制御を見ます。
DNS と IPv4 / IPv6 を分ける
名前解決では、IPv4 と IPv6 を分けて確認します。WordPress 側のエラーは単に「接続できない」と出ることがありますが、実際には IPv6 側だけ失敗している、AAAA レコードの経路だけ詰まっている、ということがあります。
コマンド
dig api.wordpress.org A
dig api.wordpress.org AAAA
curl -4 -Iv https://api.wordpress.org/
curl -6 -Iv https://api.wordpress.org/IPv4 では通るが IPv6 では失敗する場合、IPv6 のルーティング、Firewall、NAT、Proxy、DNS の返し方を確認します。逆に、IPv6 を使う設計であれば、安易に IPv4 だけへ逃がすのではなく、IPv6 経路のどこで止まっているかを見る方が本筋です。
Proxy を使う環境で見ること
外部通信を Proxy 経由にしている場合は、WordPress Pod に Proxy 設定が渡っているかを確認します。CLI では Proxy が使われているのに、PHP-FPM や Web サーバーの実行環境では使われていない、という差分も起こります。
コマンド
env | grep -i proxy
php -r 'var_dump(getenv("HTTP_PROXY"), getenv("HTTPS_PROXY"), getenv("NO_PROXY"));'Proxy を使う場合、NO_PROXY の設定も重要です。内部サービス、Kubernetes Service、Pod CIDR、ClusterIP、内部ドメインを Proxy に送ると、別の問題を作ることがあります。
Firewall で見ること
Firewall 側では、外向きの TCP/443 が許可されているかだけでなく、通信元がどこに見えているかを確認します。Kubernetes の Pod から出た通信は、Node の IP、NAT 後の IP、外部ロードバランサー、Proxy の IP など、設計によって見え方が変わります。
- Pod の通信が Node で SNAT されているか
- Firewall のログにどの送信元 IP として出ているか
- IPv4 と IPv6 のルールが同じ意図で設定されているか
- FQDN フィルタリングや DNS フィルタリングだけに依存していないか
- Proxy 経由にする通信と直接出す通信が混ざっていないか
特にクラウドや VPS、外部 Firewall を使う場合、OS 内の設定だけでなく、クラウド側のセキュリティグループ、ネットワーク ACL、上流 Firewall のログも確認します。
WordPress 側で確認すること
ネットワーク側に問題がない場合は、WordPress 側を確認します。プラグイン、テーマ、PHP 拡張、CA 証明書、REST API、cron の実行状態などが関係することがあります。
- サイトヘルスの外部通信エラー
- PHP の OpenSSL / cURL 拡張が有効か
- コンテナ内の CA 証明書が古くないか
- セキュリティ系プラグインが外部通信を止めていないか
- WP-Cron や更新確認の実行タイミング
ただし、ここに進む前に Pod と Node からの通信確認を終えておく方が切り分けは早くなります。ネットワークで止まっている状態で WordPress 側だけを調べても、原因に届きにくいためです。
参考書籍
書籍
WordPress の管理画面、テーマ、プラグイン、運用まわりを体系的に確認したい場合の参考書籍です。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
FQDN 指定の通信制御を、DNS、CDN、DoH、SNI、URL 制御の違いから整理しています。
DNS クエリ制御だけに依存したセキュリティ設計の限界を整理しています。
プロキシ環境で外部通信が直接出ようとする場合の調査例です。
まとめ
WordPress が wordpress.org に接続できない場合、WordPress の画面だけを見ても原因は分かりません。Pod、Node、DNS、IPv4 / IPv6、Proxy、Firewall、WordPress 本体を分けて確認する必要があります。
特に Kubernetes 上で WordPress を運用している場合、管理画面のエラーはネットワーク設計の問題として現れることがあります。Pod からの疎通、Node からの疎通、Firewall ログ、Proxy 設定を順番に見れば、どの層で止まっているかを切り分けやすくなります。
WordPress の外部通信は、単なるアプリケーション機能ではなく、サーバー運用とネットワーク設計の確認点でもあります。更新確認やプラグイン情報の取得が失敗した時は、アプリケーションだけでなく通信経路全体を見るのが安全です。
Related posts:
Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する
Windows Server 2019 Active Directory の LDAP を確認する
Ubuntu 26.04 タイムゾーンとロケールの設定 – timedatectl と locale を確認する
Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか
Docker プロキシ設定 – systemd drop-in で daemon に proxy を設定する
Proxy 環境で apt-key adv –recv-keys がタイムアウトする原因 – GPG 鍵取得と外部通信を切り分ける
Ubuntu 26.04 APT リポジトリとパッケージ更新 – proxy と safe upgrade を整理する
Ubuntu 26.04 Docker の基本設定 – Docker Engine / Compose / IPv6 / proxy
WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
Ubuntu 22.04 BIND 外部 DNS – 公開ゾーンと権威 DNS の設計
WordPress の外部連携プラグインが重い原因 – 投稿時の同期処理を見直す