16 days ago
We’re hardening production rate-limiting for a Railway-hosted FastAPI app and need authoritative guidance on Railway’s proxy trust contract before enabling trusted proxy header handling in uvicorn.
Context:
- Our app runs behind Railway’s edge proxy.
- We need to determine whether we can safely trust forwarded client-IP headers for security-sensitive rate-limit dimensions.
- We specifically want to avoid accepting spoofable client IP values.
Questions:
1. Does Railway publish a stable trusted proxy IP/CIDR range for requests forwarded from Railway’s edge to customer containers?
- If yes, what is that range?
- Is it stable/documented across infrastructure changes?
2. For inbound requests behind Railway’s edge, which header should be treated as the authoritative real client IP?
- X-Forwarded-For
- X-Real-IP
- X-Envoy-External-Address
- another Railway-specific header
3. How does Railway populate that authoritative header?
- overwrite
- append
- preserve client-supplied values
- strip untrusted incoming values first
4. Is that authoritative client-IP header guaranteed to be server-set and not spoofable by the original client?
5. Is this behavior documented and stable across Railway edge/proxy infrastructure changes?
Why we’re asking:
- Standard uvicorn proxy trust with --forwarded-allow-ips=... is only safe if Railway’s trusted-proxy contract and client-IP header semantics are authoritative and spoof-resistant.
- We want to configure this correctly rather than rely on community-observed behavior.
If there is an official docs page covering this, a link would be ideal.
3 Replies
16 days ago
Our Specs & Limits documentation states that X-Real-IP is the header set by our edge proxy to identify the client's remote IP. We do not publish a stable trusted proxy CIDR range, and the docs do not currently specify the exact overwrite/append semantics or provide a formal anti-spoofing guarantee for that header. For uvicorn's --forwarded-allow-ips, you would need to use * since our proxy IPs are not published, and rely on X-Real-IP as the client IP source rather than parsing X-Forwarded-For.
Status changed to Awaiting User Response Railway • 16 days ago
16 days ago
Thanks — that helps.
To confirm whether this is safe for security-sensitive rate limiting:
-
Is X-Real-IP always set by Railway’s edge proxy, rather than forwarded from the original client?
-
If a client sends its own X-Real-IP header, does Railway overwrite it before forwarding the request to the app?
-
Can apps behind Railway’s public networking be reached directly in a way that would bypass the edge proxy and allow a client-supplied X-Real-IP header to reach the app unchanged?
We need to know whether X-Real-IP is authoritative and not client-spoofable before trusting it for rate-limit identity.
Status changed to Awaiting Railway Response Railway • 16 days ago
16 days ago
- Yes, it is always set by our proxy.
- We will always overwrite it.
- Apps behind our HTTP proxy cannot be accessed directly.
Status changed to Awaiting User Response Railway • 16 days ago
9 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 9 days ago