HTTP/2 connection drops after 60s despite keep-alive - configurable?
jetsonearth
FREEOP

10 months ago

Hey Railway team! 👋

Quick question about HTTP/2 connection persistence limits on Railway.

Context:

I have a Swift client that sends keep-alive requests every 40s to maintain HTTP/2 connections to my Railway-hosted proxy (which forwards to Groq API). This works great for eliminating cold start penalties.

Issue:

Connection reuse works perfectly for ~60 seconds, then Railway seems to drop the connection despite active keep-alives every 40s. This causes 800ms+ TCP/TLS handshake penalties.

Question:

Is there a way to extend HTTP/2 connection persistence beyond 60 seconds on Railway? Or is 60s a hard limit?

My keep-alive setup:

Connection: keep-alive + Keep-Alive: timeout=55 headers

URLSession with persistent config (httpMaximumConnectionsPerHost = 1)

Project ID: 77c31c97-2ba9-4511-b060-7ff5fa441682

$10 Bounty

5 Replies

10 months ago

Hello,

We do not support HTTP/2. HTTP/2 is accepted, but it is demuxed down to HTTP/1.1 when our proxy connects to your application.


jetsonearth
FREEOP

10 months ago

Thanks Brody, how do I enable persistent connection beyond 60s?

Sorry I am super new to deploying app so might be some dumb questions

I use Groq in production. I'm deploying the proxy on Railway and embedding my Groq LLM API key into the proxy so my client application can request through my proxy. I've noticed it's hard to keep the connection longer than 60 seconds. Sending "Keep Alive" doesn't keep it. Is there any way to work around this?


jetsonearth
FREEOP

10 months ago

My TCP/TLS latency are quite high

(base) ZhaobangJetWu (main *) ~

$ curl -w @- -o /dev/null -s "https://clio-backend-production.up.railway.app/" <<<'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_total: %{time_total}\n'

time_namelookup: 0.778054

time_connect: 0.779268

time_appconnect: 1.415058

time_total: 1.507795

(base) ZhaobangJetWu (main *) ~

$ curl -w @- -o /dev/null -s "https://clio-backend-production.up.railway.app/" <<<'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_total: %{time_total}\n'

time_namelookup: 0.005307

time_connect: 0.008736

time_appconnect: 0.630628

time_total: 0.718160

(base) ZhaobangJetWu (main *) ~

$ curl -w @- -o /dev/null -s "https://clio-backend-production.up.railway.app/" <<<'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_total: %{time_total}\n'

time_namelookup: 0.003124

time_connect: 0.004879

time_appconnect: 0.621428

time_total: 0.701561

(base) ZhaobangJetWu (main *) ~

$


10 months ago

On our side, we allow for persistent connections for up to a maximum of 15 minutes, so anything stopping your connections at a timeframe shorter than that would be something on your side.

I will go ahead and place a bounty on this thread in hopes that the community can help you debug where you have this 60-second timeout set.


phoenixauro
HOBBY

10 months ago

Try using a vpn.

keep-alives only tell the server what you prefer. Instead maybe you can send an actual light weight request to keep it alive.


Welcome!

Sign in to your Railway account to join the conversation.

Loading...