2 months ago
We've hit two separate but possibly related issues on our project's private networking, and wanted to flag both together in case they share a root cause.
Issue 1 — X-Forwarded-For header trust ambiguity
We need to correctly identify real client IPs for rate-limiting (including login brute-force protection), which requires running our app with --proxy-headers and trusting Railway's forwarded-for header. However, we found genuinely conflicting information across your own support forum/docs on which position in X-Forwarded-For is authoritative (first vs. last value), including one answer explicitly caveated as provisional due to an active CDN migration, plus a separate acknowledged bug in the related X-Real-Ip header. We've held off enabling this rather than guess, since getting it wrong would mean trusting a potentially spoofable value in a security-relevant path. Could you confirm definitively which header and which position is authoritative for identifying real client IPs on our project?
Issue 2 — Recurring intermittent Redis connection timeouts on private networking
Our app (2 replicas) connects to a Railway-hosted Redis instance over private networking. We're seeing frequent, short TCP-level timeouts (not fast ERR max clients rejections — full 3-10s timeouts with no response) when connecting to Redis, roughly every few minutes, continuous and ongoing. We've confirmed:
Redis itself is healthy (low memory, no crashes, normal background saves).
Connection pool usage is nowhere near any configured limit (single-digit connections against a default cap of 100).
Traffic/load on our app is near-idle when this happens, ruling out load-related causes on our end.
We attempted to SSH directly into the Redis service to check maxclients and other config, but the official Redis template image doesn't appear to run Railway's SSH agent, so we couldn't self-diagnose further.
We've built application-level resilience so this doesn't cause user-facing errors, but we'd like to understand whether this is expected private-networking behavior, something specific to our project, or something Railway can help resolve at the platform level.
Happy to provide specific timestamps, deployment IDs, or logs for either issue if helpful
1 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
2 months ago
For client IP/rate limiting, use X-Forwarded-For and take the first/leftmost IP. Railway's edge strips client-supplied X-Forwarded-For and constructs the header, making the leftmost value the real client IP. Railway also documents X-Real-IP as the client IP, although I've seen some CDN-related bugs with it.
As for Redis, test connectivity from each app replica: resolve the Redis hostname and perform TCP connection tests, then correlate failures with timestamps. Railway private networking uses a WireGuard mesh, and newer environments can resolve internal services to both IPv4 and IPv6, so an intermittent address-family/routing problem is worth checking.
If the Redis problem persists, please provide me with the logs.