a month ago
Hi Railway Support,
We're seeing what appears to be persistent edge/proxy caching on a staging service despite CDN Caching being disabled.
Project: resilient-communication
Environment: staging
Service: eze-platform
Our application explicitly returns Cache-Control: no-store for HTML navigation, /index.html and /sw.js.
However, repeated exact GET / and GET /index.html requests return an identical historical response, including the same:
- Date
- ETag
- Last-Modified
- x-railway-request-id
The stale response persisted for over an hour and survived:
- a full container restart; and
- a complete Railway rebuild/redeploy.
At the same time:
- GET /? immediately returns the current deployment;
- HEAD / returns the current deployment;
- /sw.js is current;
- /api/health is current;
- SPA fallback routes are current.
Railway dashboard currently shows:
- CDN Caching: OFF
- Edge Rules: none
- Under Attack Mode: OFF
- one replica
The affected responses identify the server as railway-hikari.
Could you please confirm whether Railway's edge/proxy layer performs any caching independently of the CDN Caching setting, and advise how we can guarantee that HTML navigation and /index.html are never served from a stale edge response?
For our application we require:
HTML/navigation and /sw.js: always current/revalidated
content-hashed static assets: cacheable
We can provide the exact deployment IDs, timestamps, request IDs and header comparison from our investigation if useful.
1 Replies
a month ago
With CDN caching disabled and your service returning Cache-Control: no-store, our edge honors that directive and does not cache the response. The symptom pattern you describe (GET / stale, while GET /?, HEAD /, and all other paths return current content) is the signature of the browser's own disk cache replaying the stored response, including the original Date, ETag, Last-Modified, and x-railway-request-id. A query string changes the browser's cache key, which is why /? bypasses it. To confirm, check the x-cache response header on the stale response: if it is absent, the response never entered our CDN cache layer. You can also test with curl -v against GET / (no disk cache) to verify the origin is returning the current deployment.
Status changed to Awaiting User Response Railway • 27 days ago
Status changed to Solved richardakwarandu • 27 days ago