A reverse proxy may serve HTTPS to visitors while sending HTTP to the WordPress origin. Unless WordPress receives a reliable indication of the original scheme, it can generate HTTP URLs, mishandle secure cookies, or redirect endlessly.
Define the proxy trust boundary first. Then normalize the public scheme before WordPress initializes and verify the complete application path.
What it means
Public HTTPS and the proxy-to-origin connection are separate facts. WordPress needs the visitor-facing scheme and host to build URLs, set cookies, enforce login security, and validate callbacks.
Forwarded headers are safe only when a known proxy replaces client-supplied values and the origin rejects or ignores untrusted copies.
A realistic WordPress example
A load balancer terminates TLS but sends HTTP to the origin. WordPress does not trust the forwarded scheme, so login URLs become HTTP and an OAuth callback returns to the wrong address.
Configuring the load balancer to overwrite the protocol header and allowing WordPress to honor it only from that proxy restores correct URL and cookie behavior.
Why it matters and when to use it
A scheme error can affect administration, REST requests, cron callbacks, forms, and authentication even when public pages appear secure. It may also create loops between the proxy and WordPress.
Use this diagnosis when generated URLs or cookies disagree with the HTTPS address visible to the visitor.
A straightforward route for beginners
- Map where TLS terminates and how the proxy reaches the origin.
- Confirm the public certificate, hostname, and WordPress home and site URLs.
- Inspect the forwarded scheme and host values arriving at the origin.
- Configure the proxy to replace, not append, its authoritative protocol header.
- Restrict trust to the known proxy addresses and normalize HTTPS before WordPress starts.
- Test public pages, login, admin, REST, forms, and callbacks.
The advanced route
Compare edge requests with authorized origin requests using valid, missing, and spoofed forwarded headers. Confirm cookie flags, client-IP handling, load-balancer affinity, health checks, and canonical output.
Prefer encrypted or tightly isolated origin transport and prevent direct public access from bypassing the proxy contract. Keep only one redirect owner, and verify that redirects preserve methods and query data used by APIs and callbacks.
Risks, common mistakes, backup, and rollback
Trusting every X-Forwarded-Protovalue lets clients spoof security state. Editing only database URLs leaves runtime detection broken, while simultaneous proxy and WordPress redirect rules can loop.
Save proxy rules and WordPress configuration before changing them, and retain independent origin access. If authentication or callbacks fail, restore the previous trust rule while you inspect the exact headers rather than weakening certificate checks.
How AIOWS helps:
AIOWS SSL Manager
AIOWS SSL Manager can help review supported WordPress-side HTTPS settings once the proxy accurately reports the public request. It is useful for checking site URLs and application behavior after the trust boundary is established.
AIOWS cannot authenticate proxy headers, secure the origin connection, change load-balancer routing, or block direct origin access. Those responsibilities remain with the infrastructure configuration.
Use SSL Manager to verify WordPress URLs, login, administration, assets, forms, and callbacks over HTTPS. Pair that check with raw edge and origin requests, including a spoofed-header control, so WordPress accepts scheme information only from the intended proxy.
Related AIOWS articles
- Cloudflare Flexible SSL Causes a WordPress Redirect Loop
- WWW vs Non-WWW HTTPS Redirects in WordPress
- How to Check WordPress SSL Certificate and HTTPS Health
Conclusion and recommended route
Teach WordPress the public scheme through a narrowly trusted proxy contract, then secure or isolate the origin. HTTPS is healthy only when application behavior is correct and untrusted clients cannot spoof the forwarded headers.
