Railway has introduced a cache on the metal side that breaks my application as of today, Feb 20th 2026.

- Request goes in with .well-known in the path

- Railway edge returns 301 to the same URL

- Container never sees the request (not in HTTP logs)

- Same container responds correctly via TCP proxy

Something in the Railway edge stack is intercepting .well-known paths.

This has pretty much broken my service. I can see clearly in the logs that .well-known is never hitting. All HTTP requests containing .well-known in the path return a 301 Moved Permanently redirect to the same URL, creating an infinite redirect loop. These requests never reach the container!!

$ curl -sI "https://logto-auth-production-021b.up.railway.app/oidc/.well-known/openid-configuration"

HTTP/2 301

location: https://logto-auth-production-021b.up.railway.app/oidc/.well-known/openid-configuration # <-- redirects to itself

server: railway-edge # <-- only edge headers, no container headers

But when I connect via TCP directly...

$ curl -sI "https://logto-auth-production-021b.up.railway.app/oidc/jwks"

HTTP/2 200

content-type: application/jwk-set+json; charset=utf-8

logto-core-request-id: bQcX0jntSgVRWLeF # <-- container headers present

This breaks OIDC discovery, which is required for:

- OAuth2 client initialization

- JWT token validation

- Any OIDC-compliant service connecting to this provider

Environment

- Region: us-east4

- Edge responses include: x-served-by: cache-yyz4574-YYZ, via: 1.1 varnish

- This issue started recently with no changes to the service configuration