Description

All services in my Railway project are experiencing consistently high TTFB (~900ms-1s), regardless of whether the request involves any backend processing. The latency appears to be in Railway's proxy/routing layer, not in our application code.

Evidence

1. Mostly static webapp (no DB, no backend logic)

```

curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" -s https://(obfuscated).com

TTFB: 0.946840s

TTFB: 0.910275s

TTFB: 1.048065s

TTFB: 1.001922s

TTFB: 0.594758s

```

2. API service (19-byte response)

```

curl timing breakdown for https://api.%28obfuscated%29.com:

DNS: 0.001s

Connect: 0.034s

TLS: 0.073s

TTFB: 0.911s ← ~838ms gap between TLS completion and first byte

Total: 0.912s

Size: 19 bytes

```

3. Control test — external services from the same machine/network

```

Google: TTFB 0.200s

httpbin: TTFB 0.329s

```

4. Not cold-start related

Latency is consistent across 5+ sequential rapid requests. Second and subsequent requests show no improvement.

5. Sentry confirms handlers are fast

Application-level tracing shows handler execution in low milliseconds. The delay is occurring before/after our application processes the request.

Key Details

- Proxy node:trolley.proxy.rlwy.net

- Custom domains:(obfuscated).com, api.(obfuscated).com

- Affected services: All services in the project (both NodeJS web apps and Go API)

- Pattern: The ~800ms gap consistently sits between TLS completion and TTFB, pointing to proxy-layer overhead

Request

Could you investigate whether there's a proxy routing issue affecting this project? If possible, could the project be migrated to a different proxy node?