社内ネットワークや閉域のサーバーで「外へ出る通信はプロキシ経由のみ」と決まっている場合、WordPress は wp-config.php の WP_PROXY_* 定数で、OS のコマンド類は環境変数やツールごとの設定ファイルで、それぞれ別にプロキシを指定します。片方だけ設定しても、もう片方は直接外へ出ようとして失敗します。この記事では、WordPress 本体・WP-CLI・apt/dnf・git・Composer をプロキシ経由で動かす設定と、つながらないときの見分け方を説明します。
なお、ここで扱うのは「サーバーから外へ出るときに通る」フォワードプロキシです。訪問者からのアクセスを受けてWordPressへ中継する Nginx などの「リバースプロキシ」とは別物で、設定する場所も目的も異なります。
先に確認しておくこと
設定を書く前に、ネットワーク管理者から次の情報をもらっておきます。推測で埋めると、つながらない原因の切り分けが難しくなります。
- プロキシのホスト名（またはIPアドレス）とポート番号（例:
proxy.example.local:3128） - 認証の有無と方式（ユーザー名・パスワードのBasic認証か、認証なしでサーバーのIPで許可しているか）
- HTTPS 通信を中身まで検査する方式（TLSインスペクション）かどうか。検査する場合は、社内CA証明書の配布方法
- プロキシを通さずに直接届く宛先（社内のDBサーバー、監視サーバー、同じセグメントのホストなど）
まずはサーバーの上で、curl を使ってプロキシ越しに外へ出られるかを確認します。ここが通らなければ、WordPress 側をいくら設定しても動きません。
# プロキシを明示して WordPress.org のAPIへ接続（-v で途中経過を表示）
curl -v -x http://proxy.example.local:3128 -o /dev/null https://api.wordpress.org/core/version-check/1.7/
# 認証つきプロキシの場合（パスワードはシェル履歴に残るので、試験後に履歴を消す）
curl -v -x http://proxy.example.local:3128 --proxy-user 'proxyuser:your-proxy-password' -o /dev/null https://api.wordpress.org/-v の出力に CONNECT api.wordpress.org:443 が出て、そのあと 200 が返っていれば、プロキシ経由のHTTPS接続（CONNECTトンネル）は成立しています。407 Proxy Authentication Required が返る場合は認証情報が不足または誤りです。プロキシURL自体は、HTTPSの宛先へ行く場合でも多くの環境で http:// で書きます。プロキシとの間はHTTPで話し、その中にTLSのトンネルを張るためです。
WordPress 本体をプロキシ経由にする（wp-config.php）
WordPress の HTTP API（wp_remote_get() など）は、プラグイン・テーマ・本体の更新確認、翻訳のダウンロード、外部APIとの通信のすべてで使われています。この HTTP API は、wp-config.php に次の定数があるとプロキシを経由します。作業前に wp-config.php のバックアップを取り、「編集が必要なのはここまで」の行より上に追記してください。
// フォワードプロキシの設定（wp-config.php）
define( 'WP_PROXY_HOST', 'proxy.example.local' );
define( 'WP_PROXY_PORT', '3128' );
// 認証が必要な場合のみ。値はサーバーの環境変数から読む例
define( 'WP_PROXY_USERNAME', getenv( 'WP_PROXY_USERNAME' ) ?: '' );
define( 'WP_PROXY_PASSWORD', getenv( 'WP_PROXY_PASSWORD' ) ?: '' );
// プロキシを通さない宛先（カンマ区切り、* によるワイルドカード可）
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, 127.0.0.1, *.internal.example.local' );押さえておきたい動作は次のとおりです。
- プロキシが有効になるのは、
WP_PROXY_HOSTとWP_PROXY_PORTの両方が定義されているときです。片方だけでは無視されます。 - 認証ヘッダーが付くのは、
WP_PROXY_USERNAMEとWP_PROXY_PASSWORDの両方が定義されているときです。 - 宛先のホスト名が
localhostの場合と、サイトURL（siteurl）と同じホストの場合は、自動でプロキシを通りません。WP-Cron やサイトヘルスが行う自分自身へのリクエスト（ループバック）がプロキシへ流れないようにするためです。127.0.0.1は自動では除外されないので、使う場合はWP_PROXY_BYPASS_HOSTSに入れます。
パスワードを wp-config.php に直書きすると、ファイルのバックアップやリポジトリにそのまま残ります。上の例のように、PHP-FPM のプール設定（env[WP_PROXY_PASSWORD] = ...）などから環境変数として渡し、wp-config.php 自体は Web から読めない権限（例: 600 や 640）にしておくと安全です。プロキシ用のアカウントは、WordPress 専用に権限を絞ったものを用意してもらうのが理想です。
宛先ごとに細かく振り分けたい場合は、pre_http_send_through_proxy フィルターが使えます。null を返すと通常の判定に任せ、true/false を返すとその判定で決まります。子テーマではなく mu-plugin に置くと、テーマを切り替えても設定が残ります。
<?php
// wp-content/mu-plugins/proxy-routing.php
add_filter( 'pre_http_send_through_proxy', function ( $result, $uri, $check, $home ) {
// 社内APIはプロキシを通さず直接接続する
if ( isset( $check['host'] ) && 'api.internal.example.local' === $check['host'] ) {
return false;
}
return $result; // それ以外は通常の判定に任せる
}, 10, 4 );設定が効いたかの確認
管理画面の「ツール」→「サイトヘルス」で、WordPress.org との通信に関する項目が問題なしになっているかを見ます（項目の表記はバージョンにより異なります）。コマンドで確かめる場合は WP-CLI の wp eval が手早い方法です。
# HTTP API 経由で WordPress.org に接続し、ステータスコードかエラー内容を表示
wp eval '$r = wp_remote_get( "https://api.wordpress.org/core/version-check/1.7/" ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r ); echo PHP_EOL;'200 と表示されれば成功です。エラーの場合は cURL error 7（プロキシに接続できない）、cURL error 28（タイムアウト）、cURL error 56（トンネル確立の失敗。プロキシが宛先やポートを拒否していることが多い）といったメッセージが出るので、次の章の切り分けに使います。
OS のコマンドをプロキシ経由にする
環境変数（curl・wget・Composer など）
多くのコマンドは http_proxy・https_proxy・no_proxy の環境変数を参照します。小文字の名前が広く使われており、curl は HTTP 宛ての指定として大文字の HTTP_PROXY を読まない仕様なので、小文字で設定しておくと無難です。
# /etc/profile.d/proxy.sh などに置く例
export http_proxy="http://proxy.example.local:3128"
export https_proxy="http://proxy.example.local:3128"
export no_proxy="localhost,127.0.0.1,.internal.example.local"注意点が2つあります。1つは、sudo で実行すると環境変数が引き継がれないことが多い点です。sudo -E を使うか、sudoers の env_keep に追加します。もう1つは、シェルの環境変数は PHP-FPM で動く WordPress には届かない点です。PHP-FPM は既定で環境変数を引き継がない設定（clear_env）になっているため、WordPress には前章の wp-config.php の定数で指定してください。
Composer は環境変数のプロキシ指定を参照します。WP-CLI は、WordPress を読み込んで動くコマンド（wp plugin install など）では wp-config.php の定数が使われます。WordPress を読み込む前に動く wp core download などがどの設定を参照するかは WP-CLI のバージョンによって違いがあり得るため、実際に実行して確認してください。
パッケージ管理（apt・dnf）と git
apt と dnf は、環境変数とは別に設定ファイルでプロキシを指定できます。サーバー全体の更新を自動化している場合は、こちらで固定しておくと sudo の環境変数問題を避けられます。
# apt（Debian / Ubuntu）: /etc/apt/apt.conf.d/95proxy
Acquire::http::Proxy "http://proxy.example.local:3128/";
Acquire::https::Proxy "http://proxy.example.local:3128/";
# dnf（RHEL / AlmaLinux / Rocky Linux）: /etc/dnf/dnf.conf の [main] に追記
proxy=http://proxy.example.local:3128
# git（デプロイ用ユーザーで設定）
git config --global http.proxy http://proxy.example.local:3128つながらないときの切り分け（よくある順）
1. プロキシに届いていない（cURL error 7 / 28）ホスト名やポートの誤り、サーバー側ファイアウォールの送信制限が原因です。curl -v -x で同じ宛先に接続し、プロキシへのTCP接続自体ができるかを見ます。プロキシのホスト名がサーバーから名前解決できるかも getent hosts proxy.example.local で確認します。
2. 認証で拒否されている（407）ユーザー名・パスワードの誤り、または WordPress の定数が片方しか定義されていないケースです。パスワードに記号が含まれる場合、環境変数やシェルでの引用符の扱いで値が変わっていないかも確認します。NTLM など Basic 以外の認証しか受け付けないプロキシでは WordPress の定数だけでは対応できないことがあるので、サーバーのIPで許可する方式を相談するのが現実的です。
3. 宛先が許可されていない（403 や cURL error 56）プロキシ側で宛先ドメインを許可リスト制にしている環境では、api.wordpress.org・downloads.wordpress.org・翻訳ファイルの配布元、利用中のプラグインが通信する外部APIなどを個別に許可してもらう必要があります。プラグインの更新は確認できるのにダウンロードで失敗する、という症状は、確認用とダウンロード用でドメインが違うために起きることがあります。
4. 証明書エラー（cURL error 60 など）TLSインスペクションを行うプロキシでは、通信の途中で社内CAが発行した証明書に差し替えられます。WordPress は既定で同梱のCA証明書バンドル（wp-includes/certificates/ca-bundle.crt）で検証するため、社内CAを知らずにエラーになります。このとき sslverify を false にして検証を止めるのは避けてください。改ざんを検知できなくなります。社内CAを含む証明書バンドルを用意し、http_request_args フィルターで sslcertificates にそのパスを渡す方法が適切です。OS側のコマンドは、OSの証明書ストアに社内CAを登録します（Debian/Ubuntu なら update-ca-certificates、RHEL系なら update-ca-trust）。
5. 自分自身へのリクエストまでプロキシへ流れているサイトURLとは別のホスト名で自分自身にアクセスする構成（内部用ホスト名など）では、ループバックがプロキシへ送られ、WP-Cron やサイトヘルスの検査が失敗します。そのホスト名を WP_PROXY_BYPASS_HOSTS に加えます。
プロキシ側のアクセスログが見られる場合は、WordPress から送った時刻のリクエストが記録されているか、どのステータスで返したかを確認すると、原因がサーバー側かプロキシ側かをすぐに切り分けられます。
まとめ
- WordPress は wp-config.php の
WP_PROXY_HOSTとWP_PROXY_PORT（認証時はWP_PROXY_USERNAME・WP_PROXY_PASSWORDも）でプロキシを経由する。OS の環境変数は PHP-FPM には届かない localhostとサイトURLのホストは自動で除外される。127.0.0.1や社内ホストはWP_PROXY_BYPASS_HOSTSに入れる- OS のコマンドは環境変数（小文字推奨）、apt・dnf・git はそれぞれの設定ファイルで指定する。
sudoでは環境変数が消えやすい - つながらないときは curl の
-v -xで同じ宛先を試し、未到達・407・宛先拒否・証明書の順に切り分ける - 証明書エラーで検証を無効にせず、社内CAを含むバンドルを指定する
- 定数やフィルターの挙動は WordPress のバージョンで変わる可能性があるため、更新後にもサイトヘルスで通信を確認する（2026年10月現在）