I'm seeing a large, consistent gap between my app's actual response time and the latency clients experience — it looks like the Cloudflare-proxy / edge-to-container origin latency your team has previously acknowledged. SETUP - Service (API): api.smartiwos.com → 2yv1osip.up.railway.app - Region: us-east4 (header: x-railway-edge: railway/us-east4-eqdc4a) - Stack: FastAPI/Uvicorn behind the Railway HTTP edge (server: railway-hikari), single replica, production THE PROBLEM Railway's own HTTP logs report the service responding in p50 23ms / p90 62ms / p95 73ms / p99 275ms, and in-container profiling confirms tens-of-ms handling (/health is a no-op returning {"status":"ok"}). But real-world client latency is far higher: - api.smartiwos.com/health (Cloudflare-proxied): TTFB ~700ms, with one 11.8s outlier on an idle endpoint. - 2yv1osip.up.railway.app/health DIRECT (bypassing Cloudflare): still ~520–590ms TTFB, consistently. - A user in Calgary (~50ms from us-east4) sees ~500ms per request — far above what 50ms network + 23ms app time should produce. So the added latency is in the Railway edge→container path and/or the Cloudflare-origin integration, not my app code or DNS. This matches the community thread "Is it normal to have 200ms baseline latency?", where staff confirmed "it is not normal, team is aware" and noted disabling the Cloudflare proxy dropped times to <30ms. QUESTIONS 1. Is there a known issue with added latency between the Railway HTTP edge and containers in us-east4, and an ETA on a fix? 2. For custom domains, do you recommend Cloudflare as DNS-only (grey cloud) rather than proxied? Is the Cloudflare-proxy origin-latency issue resolved or still to be avoided? 3. The intermittent 11.8s TTFB spike on a no-op endpoint is concerning — connection re-establishment / origin pooling on your edge? Anything I can configure (keep-alive, replicas, region) to mitigate? 4. Any edge PoP / multi-region options to reduce origin latency for North American users, like the Melbourne PoP mentioned in that thread? Happy to provide deployment IDs, timestamps, or HAR/traceroute captures to help reproduce.

High edge→origin latency on us-east4 despite sub-25ms app response times

ayush391

PROOP

25 days ago

I'm seeing a large, consistent gap between my app's actual response time and the latency clients experience — it looks like the Cloudflare-proxy / edge-to-container origin latency your team has previously acknowledged.

SETUP

Service (API): api.smartiwos.com → 2yv1osip.up.railway.app
Region: us-east4 (header: x-railway-edge: railway/us-east4-eqdc4a)
Stack: FastAPI/Uvicorn behind the Railway HTTP edge (server: railway-hikari), single replica, production

THE PROBLEM

Railway's own HTTP logs report the service responding in p50 23ms / p90 62ms / p95 73ms / p99 275ms, and in-container profiling confirms tens-of-ms handling (/health is a no-op returning {"status":"ok"}).

But real-world client latency is far higher:

api.smartiwos.com/health (Cloudflare-proxied): TTFB ~700ms, with one 11.8s outlier on an idle endpoint.
2yv1osip.up.railway.app/health DIRECT (bypassing Cloudflare): still ~520–590ms TTFB, consistently.
A user in Calgary (~50ms from us-east4) sees ~500ms per request — far above what 50ms network + 23ms app time should produce.

So the added latency is in the Railway edge→container path and/or the Cloudflare-origin integration, not my app code or DNS. This matches the community thread "Is it normal to have 200ms baseline latency?", where staff confirmed "it is not normal, team is aware" and noted disabling the Cloudflare proxy dropped times to <30ms.

QUESTIONS

Is there a known issue with added latency between the Railway HTTP edge and containers in us-east4, and an ETA on a fix?
For custom domains, do you recommend Cloudflare as DNS-only (grey cloud) rather than proxied? Is the Cloudflare-proxy origin-latency issue resolved or still to be avoided?
The intermittent 11.8s TTFB spike on a no-op endpoint is concerning — connection re-establishment / origin pooling on your edge? Anything I can configure (keep-alive, replicas, region) to mitigate?
Any edge PoP / multi-region options to reduce origin latency for North American users, like the Melbourne PoP mentioned in that thread?

Happy to provide deployment IDs, timestamps, or HAR/traceroute captures to help reproduce.

$20 Bounty

3 Replies

Railway

BOT

25 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 25 days ago

phin

EMPLOYEE

25 days ago

We recommend removing the Cloudflare proxy (orange->grey cloud) for the time being. They are having a few issues routing correctly to our edge.

Is there anything that you use the Cloudflare proxy for that you can't get from the Railway platform? Would love to know as we're currently prioritizing work on our edge offering.

ayush391

PROOP

25 days ago

Thanks for the response. I will try this out and revert here with the results.

To answer your question: honestly, not much that's critical for us. We mostly keep Cloudflare for DNS management.

Anonymous

FREE

22 days ago

Switch Cloudflare to Grey Cloud (DNS-only) 2. Increase your app's keep-alive timeout settings. 3. Scale your app from 1 replica to 2+ replicas to keep the connection paths open and active.

Welcome!