Columbia Games · WordPress / 14 May 2026
Behind an HTTPS reverse proxy, WordPress can easily end up chasing its own redirects
The container saw HTTP while the browser used HTTPS. Without an explicit proxy boundary, WordPress could generate redirect loops and inconsistent asset URLs.
Situation
The local Docker environment ran behind a reverse proxy: traffic was HTTPS outside and HTTP between the proxy and the container. WordPress could therefore infer from the internal request that SSL was absent, redirect to HTTPS, and receive the next hop over HTTP again. That is a straightforward recipe for redirect loops or mixed URL generation.
Approach
In the Docker-specific part of `wp-config`, I interpreted the protocol information forwarded by the proxy and marked a request as HTTPS only when a trusted forwarded header said so. The compatibility logic stayed in the development runtime layer instead of being baked into production configuration.
Outcome
Redirect loops disappeared and WordPress consistently generated HTTPS URLs for the local development domain. Production configuration remained unchanged, so local proxy-specific behaviour did not leak into the live system.