A 301 cannot be taken back: how 43 minutes of a wrong redirect came back as a 404 five days later, plus the Cloudflare edge-cache incident

Moving two web services to subdomains, a broken 301 went out for 43 minutes. The server was fixed at once, but the browser was still following that 301 into a 404 five days later. What to do before emitting a permanent redirect, the only way to rescue one already sent, and the day a deploy "did nothing" because Cloudflare's edge kept the old CSS.

What happened

On 31 August 2026 I moved two web services with tens of thousands of generated pages from eltacrew.com/fixcode/ and /benefit/ to fixcode.eltacrew.com and benefit.eltacrew.com, with 301s on the old paths.

For the first 43 minutes that 301 did not strip the prefix and sent people to benefit.eltacrew.com/benefit/.... In Caddy, if uri strip_prefix and redir sit in the same block, the default directive order runs redir first. You have to wrap them in route {} to force the order.

@moved path /benefit /benefit/*
handle @moved {
  route {
    uri strip_prefix /benefit
    redir https://benefit.eltacrew.com{uri} permanent
  }
}

Fixed in 43 minutes, verified with curl. I thought it was over.

Five days later

On 4 September I clicked a link on my admin dashboard and got a 404. The browser had cached the 301 it received inside that 43-minute window and was going to the old destination without asking the server again. A 301 is "permanent", so the browser reuses it. Fixing the server tells the client nothing. My curl asked the server every time and stayed green; this is a class of bug you can never catch by looking at the server.

Crawlers cache it too. Do not treat it as one person's problem.

The only fix is to catch it at the destination

There is no way to clear a client's cache. The only remedy is to accept the wrong address on the receiving side. I added rescue redirects on both subdomains so that a request arriving as /fixcode/* or /benefit/* gets the prefix stripped once more, preserving the rest of the path.

The order from now on

• Before a move, emit a 302 on one test path and verify the Location value. Only then promote it to permanent.
• A redirect health check on a dashboard ("old path 301 OK") looks only at the server response. A cache stuck in a client hides behind that green light. Remove the check when the migration is done.

The other incident: deployed, but nothing changed

A related incident from 10 August. I added an explanatory section to the Markdown converter and deployed it, and it did not appear. index.html was current, but style.css and app.js were coming from Cloudflare's edge as old files: cf-cache-status: HIT, Age: 6772, max-age=14400 (four hours). The old CSS still had body{overflow:hidden}, so the section existed in the HTML but scrolling was blocked and it never came into view.

Diagnosis in order:

1. Hash of the actual file on the origin server
2. Hash of the file at the live URL
3. The cf-cache-status and Age headers

If the origin is current and live differs, it is the edge cache. The fix is to bump a ?v= query on CSS and JS every time they change. HTML has a short cache and refreshes first, leaving stale assets behind; that combination is the most confusing. A subpath site's favicon shows the old file for four hours for the same reason.

There was a misjudgment in there too. Two files whose hashes differed were about to be declared stale, but the difference was CRLF only; the content was identical. On Windows with core.autocrlf=true, git archive outputs CRLF. Compare after tr -d '\r'.

Summary

• Clients cache a 301 permanently. A wrong 301, once sent, cannot be undone by fixing the server.
• Verify with a 302 first, then promote to permanent.
• If one already went out, add a rescue rule at the destination that accepts the wrong address.
• Without route {}, Caddy runs redir before uri.
• When a deploy does not show, suspect the edge cache first and bust assets with ?v=.