Hey,

Fastly does not invent 307 redirects.

These "random" paths are not that random, they are common paths bots trigger.

What is likely happening is that a bot is triggering a 307 redirect and that gets cached and served to everyone else. Hence why a redeploy fixes that.

What is the best way to address it?

What you did with cache control is a workaround, you can also preferably simply return 404 in unknown routes instead of redirecting.

Root cause (confirmed by the community response + our own testing):

1. Bots probe /wordpress/, /blog/ etc. with trailing slashes

2. Nitro responds with 307 - /wordpress (trailing slash strip)

3. Fastly caches the 307 and serves it for all requests including /

4. Site breaks with ERR_TOO_MANY_REDIRECTS

5. Redeploying purges Fastly cache - temporarily fixes it

What we deployed:

1. strip-trailing-slash.ts middleware - returns 404 for any trailing-slash request, preventing Nitro from ever issuing a 307

2. Nitro routeRules -sets no-store cache headers on all responses at the config level so Fastly never caches anything

3. no-cache.ts middleware - defense-in-depth no-cache headers

Not sure you need to use the caching rules since it now returns 404s anyways. Overall seems like a good fix

After all these changes the app broke again today and I needed to redeploy again, nothing seems to help

Update: The issue is still reproducing after deploying all three fixes mentioned above (strip-trailing-slash middleware, routeRules no-cache headers, and no-cache middleware). Every path on the domain - including /api/health - was returning 307 - /wordpress.

Key observation: x-cache: MISS on every request. The 307 is NOT being served from Fastly's cache - it's being generated fresh at the Railway edge layer (x-railway-edge: railway/us-east4-eqdc4a). This means the cached-307 theory doesn't fully explain the problem. Even with CDN-Cache-Control: no-store and Surrogate-Control: no-store headers in the response, and even on paths that have never been probed by bots (like /api/health), every request was getting a 307 to /wordpress.

My application code never generates 307 redirects. The strip-trailing-slash middleware returns 404 for trailing-slash paths. A fresh redeployment just now fixed it again - confirming the 307 originates from Railway's edge/CDN layer, not from the application.

So the question remains: if x-cache: MISS means it's not a cached response, why is Railway's edge generating 307 redirects to /wordpress on every path? And why does redeploying fix it?