Proxy-set-header: Forwarding HTTP headers from Nginx to a WordPress container

I detailed in a recent post how I got a working WordPress container setup, complete with database and PHP engine. I saved the bit about how to redirect traffic to the container (and apply encryption to the outbound connections) because I knew it was going to be just as much work as getting the setup running. Also I needed to first get up to speed on HTTP headers in general and how to inspect them specifically.

This post is not a how-to any more than it’s a how-not-to. I wanted to detail as much the attempts that did not work as the final one that did because the former were just as illuminating as the latter.


WordPress on Docker: The 1-2-3 approach

There’s an official WordPress docker image on the hub. Which means I have no good excuse to go make my own. Here’s my bad excuse: The official approach contains Apache and WordPress files all mashed up in one image. This feels icky to me partly because I don’t know Apache, having decided early on to hitch my wagon to Nginx, partly because it feels un-containerly to have everything in one big pot.

I cannot argue the merits and demerits of the official image with regards to performance, scalability, or security. What I saw was an opportunity to solve the problem in a way that felt more correct to me – 1 network, 2 volumes, 3 containers,  – that would also work as a learning experience. Here’s how I did it.


NGINX for humans

Readable documentation on NGINX configuration is scarce. So finding something good is a genuine cause for celebration. This Digital Ocean piece on location blocks didn’t directly address the issues I was having (“Why do I get redirected to XYZ when I’m trying to reach ABC?”) but it made me understand much better how NGINX uses location blocks. And it gave me an aha moment, made me rewrite my try_files lines and voila, problem solved.