WordPress が自サイトをプロキシの外に置く理由

WP_PROXY_HOST と WP_PROXY_PORT が設定されています。外部 API へのリクエストはプロキシを使いますが、WordPress 自身のホスト名へのリクエストは使いません。これは HTTP API の意図されたバイパス方針である可能性があります。

WP_HTTP_Proxy は、特定の URI をプロキシ経由にするかどうかを判断します。既定のロジックは localhost と、サイトの設定済み siteurl から導かれるホスト名をバイパスします。これはプロキシ定数が存在するかどうかを決めることとは別です。

WordPress が評価した URL を確認する

要求されたホスト名、設定済みのサイト URL、WP_PROXY_BYPASS_HOSTS をまとめて確認してください。公開ホスト名へのリクエストと内部エイリアスへのリクエストは、どちらも同じアプリケーションに届いても異なる判断をすることがあります。

WP_PROXY_BYPASS_HOSTS は設定されたホスト除外リストを追加します。これはリモートプロキシが許可する宛先の集合ではなく、他の方法でブロックされている外部リクエストを許可可能にするものでもありません。

既定の自サイト除外は役立つことがあります。ローカルのループバック形式のアプリケーションリクエストを仲介者へ送り出すのを避けます。ただし、公開サイトのホスト名が特定の承認された経路でのみ到達可能なインストールでは、別の意図的な判断が必要かもしれません。

pre_http_send_through_proxy フィルターは URI ごとの判断を上書きできます。上書きは狭く保ち、処理すべきホストや条件に合わせてください。すべての URI に同じ固定の答えを返すと、HTTP API 全体の方針が変わります。

選択されたトランスポートも確認してください。別の SDK や生の PHP ネットワーク関数を呼ぶコードは、WordPress の HTTP API とそのフィルターを自動的に使うわけではありません。

この経路を診断する際は、完全なリクエスト引数を公開せずにバイパスの判断を記録してください。クッキー、アカウント情報、プロキシの秘密が含まれることがあります。一致するリクエストのないプロキシログはバイパスと整合しますが、それだけでは一度も行われなかったリクエストと区別するのに十分ではありません。