The first deploy went up with the proxy off. The owner’s decision, made the same day, was that the site should sit behind Cloudflare’s proxy, the orange cloud. The manager wrote a brief and an Opus builder delivered the slice in a worktree.
What the proxy breaks
With the proxy on, every request reaches the server from a Cloudflare address. The app’s rate limits would see one visitor, and the certificate renewal check that arrives over plain HTTP would never reach the server. So the slice does two things: it trusts Cloudflare’s published ranges as proxies, taking the visitor’s address from the header Cloudflare sets and passing the app a single value a visitor cannot forge; and it moves certificate issuance to the DNS challenge, proved by a scoped token with the narrowest permissions the module will accept.
Opt-in, not default
With no token in the environment the server behaves exactly as before, HTTP challenge and no trusted proxies. With one, the proxy mode is on. One configuration file, no second profile, and the first deploy kept working unchanged while the slice was in review. The module that fetches the ranges fails safe: if its first fetch fails nothing is trusted, so visitors share a bucket for an hour but nobody can spoof.
The wrong diagnosis
The owner’s first switch to proxy mode showed the token as never used. The first explanation, that the server was still trying the HTTP challenge first, led to a tighter configuration that spells out the DNS challenge alone. That change was right, but the diagnosis was not: the certificate authority reuses a valid authorization for thirty days, so the re-issue had gone through with no challenge at all. The guide’s proof step now moves the account aside too, so a fresh account must solve the DNS challenge, and the proof is the challenge line in the log, the token’s last-used column, and the record writes in the audit log.
Locking the origin
Once the proxy was on, the owner switched on a firewall rule that lets only Cloudflare’s ranges reach ports 80 and 443, leaving SSH alone. The firewall was chosen over a rule in the web server because it drops traffic before any handshake and can be undone from the console without touching the machine. The cost is a pasted list that goes stale when Cloudflare adds ranges. The owner asked for a watcher. The choice was alert over auto-update: a write token for the hosting firewall cannot be scoped to one rule, so none is stored anywhere. A weekly job checks the published ranges against the file in the repository, opens a pull request on drift, and fails the run so the owner hears about it.
The guide now says in one line what the lock implies: remove it before ever going back to the grey cloud.