Railway proxy connection exhaustion and TCP keep-alive behavior

Railway utilizes a proxy-based architecture to abstract database connections through internal network layers. While this facilitates seamless deployments, intermittent connection pool exhaustion can occur when the application-side maximum pool size exceeds the limits imposed by the proxy or the database plan.

There is a documented uncertainty regarding how the platform handles TCP keep-alive timeouts on idle database connections. If the proxy terminates a silent socket without the application-side pool being notified, the connection pool may retain 'ghost' connections. This leads to scenarios where new connection requests are rejected despite the database dashboard showing low active usage.

The goal is to distinguish between platform-level rate limiting and application-level socket leakage caused by stale TCP states in HikariCP or similar pooling libraries.

• What is the specific TCP keep-alive timeout duration on the Railway proxy for internal database traffic?
• Are environment variables available to force the proxy to aggressively prune stale connections before they reach the application limit?