WordPress Keeps Its Own Site Off the Proxy

WP_PROXY_HOST and WP_PROXY_PORT are set. A request to an external API uses the proxy, but a request back to WordPress's own hostname does not. That can be the HTTP API's intended bypass policy.

WP_HTTP_Proxy decides whether a particular URI should pass through the proxy. Its default logic bypasses localhost and the hostname derived from the site's configured siteurl. This is separate from merely deciding whether proxy constants exist.

Inspect the URL WordPress evaluated

Keep the requested hostname, the configured site URL and WP_PROXY_BYPASS_HOSTS together. A request to a public hostname and one to an internal alias can make different decisions even if both reach the same application.

WP_PROXY_BYPASS_HOSTS adds a configured list of host exclusions. It is not a set of destinations allowed by the remote proxy, and it does not make an otherwise blocked external request permissible.

The default self-site exclusion may be useful: it avoids taking a local loopback-style application request out to an intermediary. But an installation in which the public site hostname is reachable only through a particular approved route may need a different deliberate decision.

Change the decision at the supported hook

The pre_http_send_through_proxy filter can override the per-URI decision. Keep any override narrow and match the host or condition it is meant to handle. Returning one fixed answer for every URI changes the whole HTTP API's policy.

Review the selected transport as well. Code calling a separate SDK or raw PHP networking function does not automatically use WordPress's HTTP API and its filter.

When diagnosing this path, record the bypass decision without dumping complete request arguments publicly. They can contain cookies, account information and proxy secrets. A proxy log with no matching request is consistent with a bypass, but it is not enough on its own to distinguish that from a request never made.