2 hours ago
We’re configuring a synthetic staging app behind Railway’s public HTTPS endpoint.
Our diagnostic observed multiple forwarding peers and a multi-address X-Forwarded-For header. Railway replaced the spoofed forwarding headers in our test requests, but we don’t want to treat those observations as a guaranteed trust boundary.
Could you confirm:
What supported mechanism distinguishes Railway’s public HTTP ingress from direct or private-network callers?
Is there a maintained proxy IP allowlist, and are those addresses exclusive to trusted ingress?
If no allowlist exists, what supported isolation or authenticated proxy configuration prevents callers from bypassing the public edge and supplying forged forwarding headers?
What configuration do you recommend for HTTPS detection, client-IP rate limiting, and health checks in a Flask/Waitress app?
Our service has one replica, a Railway-generated HTTPS domain, and no TCP proxy. We want to avoid trusting all proxy addresses or hard-coding addresses seen in a few requests.
1 Replies
2 hours ago
There is no request-level mechanism that lets your app tell our public HTTP edge apart from a private-network caller. We don't sign forwarding headers, offer an edge-only ingress switch, or expose an mTLS identity to the app. We also don't publish a proxy IP allowlist, and the socket peer address you see (such as 100.64.0.0/10) is not a stable range to hard-code.
The trust boundary is the environment. Private networks are isolated between projects and environments, but other services in the same environment can reach your port over *.railway.internal and send any headers they like. Requests through the public edge, including your .up.railway.app domain, have X-Real-IP, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host overwritten, not appended to. With one service and no TCP proxy, the edge is your only ingress path. Any services you add to that environment later share the boundary, so treat them as trusted or put them in a separate environment.
For rate limiting, key on X-Real-IP, not the socket peer or a hop count in X-Forwarded-For. For HTTPS detection, the edge terminates TLS and sets X-Forwarded-Proto to https.
Health checks only run at deploy time. They call your configured path on PORT with the hostname healthcheck.railway.app, so allow that host if you restrict hosts. They need a 2xx response within 300 seconds by default. More detail is in the networking specs and the healthcheck docs.
Status changed to Awaiting User Response Railway • about 2 hours ago