This started with a k3s install and not enough memory to do it in. I shut down another project's stack by hand, which freed up enough to get k3s running. k3s loads br_netfilter when it starts, and once the module was in place a kernel switch that applies to the whole host changed state. Then I brought the stopped project back, and its containers had lost the ability to reach each other. That's its own story. This one is about what I tried next — an attempt that did nothing for that problem and quietly broke a different one.
What I tried was a docker daemon restart: take the engine down, bring everything up clean, see whether the failure came back with it. It came back. The restart's real effect landed somewhere else entirely — every container on a different network, one I hadn't touched all day, came up holding an address it hadn't had before. Two of them matter here: the reverse proxy standing in front of every service on the box, and a proxy service standing in front of the reverse proxy. Neither had a static address pinned at the time, so each got whatever docker dealt it on the way up. That's where this story actually starts.
That second proxy is worth explaining before anything else, because the whole investigation turns on it. Every service on the box sits behind the reverse proxy's access rule, which admits exactly two sources and denies everything else. The one exception is the proxy service itself — call it the gateway from here — which exists specifically as a security control: connect to it first, and it's the only thing standing between the public internet and everything else running on the box. That's not how the wiring happened to end up. It's what the wiring was built to do — turn a set of publicly reachable services into something that behaves like a private intranet, gated behind one deliberately unrestricted entry point.
