9 minutes ago
Pre-deployment platform architecture question for ordinary HTTP and WebSocket services.
We need reliable client-address rate limits. A temporary diagnostic showed that public requests had X-Real-IP overwritten, while a direct private peer could reach the same listener and supply its own value. This concerns source trust, not a demonstrated authentication bypass.
We reviewed the private-networking docs and these related threads:
https://station.railway.com/questions/supported-way-to-obtain-a-trusted-client-e09bae3b
https://station.railway.com/questions/asp-net-core-trusted-ingress-boundary-an-ea6cad35
The latter has BOT-labelled answers; we would appreciate confirmation from a Railway team member.
- Is there a supported per-service inbound restriction that permits Railway HTTP edge traffic but blocks direct private IPv4/IPv6 callers, while retaining outbound private PostgreSQL/Redis access and health checks?
- Does disabling an internal/private endpoint remove only DNS discovery, or enforce TCP reachability restrictions too, including direct addresses and redeploys?
- If no such restriction exists for regular services, what architecture does Railway recommend for this case? For example, would a gateway alone in its own isolated environment, forwarding to separately authenticated application origins, be the appropriate supported pattern?
Please link authoritative documentation or clarify the current limitation. We are asking for platform guidance, not application debugging. No project IDs, logs, credentials or user records are included. We are not requesting a paid bounty or a plan change.
2 Replies
8 minutes ago
We can't point you to a per-service inbound control that admits only our HTTP edge and blocks direct private IPv4/IPv6 callers. The private network's isolation boundary is the project and environment: services in different projects or environments can't reach each other privately, but services in the same environment can reach your listener's port directly. Those requests skip the edge, so they don't get its header rewriting and can set their own X-Real-IP. WireGuard encryption on that hop doesn't change this.
On disabling a private endpoint: we haven't verified whether that only removes the .railway.internal DNS name or also blocks TCP to the service's private addresses, including across redeploys. Don't treat it as an ingress restriction.
For rate limiting, X-Real-IP is reliable for requests that come through the edge, because we overwrite any caller-supplied copy (along with X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host). We don't publish a stable range for the proxy socket addresses your app sees, so you can't use a peer CIDR to tell edge traffic apart from private callers. The environment should therefore only hold services you trust as much as the edge path. On your gateway example, a gateway in a separate environment couldn't reach origins in another environment over the private network, and we can't confirm that design as a supported pattern beyond these isolation rules. References: private networking isolation and public networking specs.
Status changed to Awaiting User Response Railway • 8 minutes ago
Railway
We can't point you to a per-service inbound control that admits only our HTTP edge and blocks direct private IPv4/IPv6 callers. The private network's isolation boundary is the project and environment: services in different projects or environments can't reach each other privately, but services in the same environment can reach your listener's port directly. Those requests skip the edge, so they don't get its header rewriting and can set their own `X-Real-IP`. WireGuard encryption on that hop doesn't change this. On disabling a private endpoint: we haven't verified whether that only removes the `.railway.internal` DNS name or also blocks TCP to the service's private addresses, including across redeploys. Don't treat it as an ingress restriction. For rate limiting, `X-Real-IP` is reliable for requests that come through the edge, because we overwrite any caller-supplied copy (along with `X-Forwarded-For`, `X-Forwarded-Proto` and `X-Forwarded-Host`). We don't publish a stable range for the proxy socket addresses your app sees, so you can't use a peer CIDR to tell edge traffic apart from private callers. The environment should therefore only hold services you trust as much as the edge path. On your gateway example, a gateway in a separate environment couldn't reach origins in another environment over the private network, and we can't confirm that design as a supported pattern beyond these isolation rules. References: [private networking isolation](https://docs.railway.com/networking/private-networking/how-it-works) and [public networking specs](https://docs.railway.com/networking/public-networking/specs-and-limits#technical-specifications).
7 minutes ago
Thank you. Could a Railway team member provide human confirmation or a documentation reference for the supported regular-service restriction and private-endpoint behavior? The automated answer leaves those capability questions unresolved.
To clarify the proposed fallback: the isolated gateway would forward over HTTPS/WSS to public application origins with distinct origin-authentication credentials; it would not require cross-environment private connectivity. Is this an appropriate supported arrangement, or is there a simpler native way to establish the same boundary?
Please keep this open for team guidance; this has not resolved the pre-deployment question.
Status changed to Awaiting Railway Response Railway • 6 minutes ago