3 months ago
307 redirect to random paths from railway-edge — redeploying temporarily fixes it
We have a Node.js app (TanStack Start / Nitro, node-server preset) deployed on Railway. Periodically, all requests to both our custom domain and the .up.railway.app domain start returning 307 Temporary Redirect to random paths that don't exist in our application (/wordpress, /blog, etc.).
The pattern:
- After a fresh deploy, everything works fine (200 responses)
- After some time (hours to days), all requests start returning 307 redirects to a random path
- The redirect path changes each occurrence — sometimes /wordpress, sometimes /blog
- Redeploying the service fixes it temporarily, then it breaks again
What we've confirmed:
- The 307 is NOT generated by our application — our code has zero redirect logic
- The response headers show server: railway-edge and via: 1.1 varnish — the redirect originates from Railway's edge/CDN layer, not our app
- The issue reproduces on the .up.railway.app domain directly (no DNS/Cloudflare involved)
- We've added Cache-Control: no-store and Surrogate-Control: no-store headers as a workaround
Has anyone else experienced this? It seems like the edge proxy or Fastly CDN is caching or generating stale redirects that aren't coming from the origin server.
7 Replies
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
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.
xmrafonso
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.
3 months ago
What is the best way to address it?
yurykorzun
What is the best way to address it?
3 months ago
What you did with cache control is a workaround, you can also preferably simply return 404 in unknown routes instead of redirecting.
3 months ago
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
3 months ago
Not sure you need to use the caching rules since it now returns 404s anyways. Overall seems like a good fix
3 months ago
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?
a month ago
I've got exactly the same problem. This is despite the fact that the domain has CNAME and TXT in DNS records confirming I own the domain. The same problem is present on both railway and my own domain. The app is also a TanStack Start app. Redeploy also temporarily fixes the problem:
curl -I http://setsweat-app-production.up.railway.app/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://setsweat-app-production.up.railway.app/
Server: railway-edge
X-Railway-Edge: railway/europe-west4-drams3a X-Railway-Request-Id: QQ6m9kHHQguaw_LY21mRUA
Date: Thu, 07 May 2026 15:35:05 GMT
---
curl -I https://setsweat-app-production.up.railway.app/
HTTP/1.1 307 Temporary Redirect
Date: Thu, 07 May 2026 15:35:30 GMT
Location: /blog/rss
Server: railway-edge
X-Railway-Edge: railway/europe-west4-drams3a X-Railway-Request-Id: rZwz8YszRhytPhXms_GTAg
---
→ curl-I https://setsweat-app-production.up.railway.app/
HTTP/1.1 307 Temporary Redirect
Date: Thu, 07 May 2026 15:39:38 GMT
Location: /blog/rss
Server: railway-edge
X-Railway-Edge: railway/europe-west4-drams3a X-Railway-Request-Id: RYXAkhMYRXKAOn0InTga3g
---
curl -I https://www.setsweat.com/
HTTP/2 307
date: Thu, 07 May 2026 15:55:18 GMT
location: /blog/feed
server: railway-edge
x-railway-edge: railway/europe-west4-drams3a
x-railway-request-id: ViCwNeUBTUK2w1Cj0-QtfA
---
AFTER REDEPLOY:
---
curl -I https://setsweat-app-production.up.railway.app/
HTTP/2 200
cache-control: no-cache, no-store, must-revalidate
content-type: text/html; charset=utf-8
date: Thu, 07 May 2026 16:05:06 GMT
server: railway-edge
x-railway-edge: railway/europe-west4-drams3a
x-railway-request-id: zJIPwzmFT36qGo0YjUJq2g
---
curl -I https://www.setsweat.com/
HTTP/2 200
cache-control: no-cache, no-store, must-revalidate
content-type: text/html; charset=utf-8
date: Thu, 07 May 2026 16:05:14 GMT
server: railway-edge
x-railway-edge: railway/europe-west4-drams3a
x-railway-request-id: 75Z7vHAeRmyWWdSMN8N_Fg