One of the recurring themes in my homelab projects is that I consistently underestimate how long “simple” changes will take.
Putting this blog behind Cloudflare seemed like one of those changes.
The goal wasn’t particularly ambitious. I wanted the benefits Cloudflare offers almost by default: caching, DDoS protection, hiding the origin IP, and an additional layer of security between the internet and my WordPress instance. Since the site was already sitting behind HAProxy and OpenLiteSpeed, I assumed this would amount to changing a few DNS records, validating SSL, and moving on to something more interesting.
Instead, it became a crash course in how modern infrastructure behaves when multiple independently reasonable systems interact with one another.
None of the individual components were especially difficult to understand.
The challenge was that they all made sense independently while occasionally producing outcomes that were anything but intuitive when combined.
One of the first surprises involved SSL. Before this project, I hadn’t fully appreciated how easy it is to assume that a site displaying a valid certificate to visitors means everything behind the scenes is healthy. Cloudflare abstracts a lot of complexity away from the end user, which is wonderful until it isn’t. A visitor can see a perfectly secure site while the origin certificate sitting behind Cloudflare has expired or is misconfigured. The first time you discover that, it feels less like troubleshooting and more like uncovering an elaborate magic trick.
Then there was caching.
Everyone loves caching when it makes their websites faster. Nobody loves caching when they’re trying to figure out why a change they made ten minutes ago hasn’t appeared yet or why their header menu is broken on some pages and not others.
At various points during this process, WordPress had an opinion about what should be served, OpenLiteSpeed had its own opinion, Cloudflare had another, and my browser was quietly contributing its own interpretation of reality. After clearing the wrong cache several times, I eventually stopped asking why something wasn’t updating and started asking which layer still believed it knew better than I did.
The issue that consumed the most time, however, involved something I thought Cloudflare had already solved for me.
One of the features I was most excited about was Always Online. The premise is appealing: if your origin becomes unavailable, Cloudflare serves cached versions of your content so visitors can continue accessing the site. For a personal blog, that sounded like exactly the kind of resilience I wanted.
Then I started seeing 503 errors.
Not simulated failures. Not theoretical discussions on a forum. Actual outages where I expected Cloudflare to gracefully handle the situation, and instead found myself staring at error pages while trying to understand why Always Online wasn’t behaving the way I had imagined. For example, when my VM hosting WordPress was rebooting to load a new Linux kernel, but HAProxy on my firewall was still online.
It turned out that my mental model of the feature didn’t quite match reality.
Always Online is helpful, but it isn’t magic. It depends on having content available to serve, and it doesn’t replace the need for healthy origin infrastructure. In my case, I learned it only kicks in for certain status codes from the origin. A 503 unavailable, as HAProxy loves to present when a backend is offline, is not one of those codes. Cloudflare can improve resilience, but it doesn’t eliminate the responsibility of understanding how the systems behind it fail.
That realization probably captures the biggest lesson from this entire experience.
Cloudflare doesn’t simplify infrastructure nearly as much as it redistributes complexity.
The problems don’t disappear.
They just move.
Instead of troubleshooting WordPress directly, you’re troubleshooting the interactions between Cloudflare, reverse proxies, certificates, origin health checks, cache layers, and whatever assumptions you brought into the project.
Strangely enough, I don’t mean that as criticism.
I still think putting WordPress behind Cloudflare was absolutely worthwhile. The site is faster. I have more confidence in its security posture. I appreciate the additional protections and capabilities it provides.
I also have a much healthier respect for the fact that modern infrastructure isn’t complicated because the individual pieces are impossible to understand. It’s complicated because each piece behaves reasonably on its own while participating in a larger system that occasionally produces surprising results.
The next time I decide that a project should only take an afternoon, I’ll probably still underestimate it.
At least now I’ll have a better idea of where to start looking when Cloudflare, HAProxy, OpenLiteSpeed, WordPress, and a 503 error decide to teach me something new.
