Subject: Constant 12.5s TTFB on all origin fetches, intermittent 502s

Every origin fetch through your edge takes a near-constant 12.4-12.6s TTFB, regardless of method, HTTP version, IPv4/IPv6, or which domain (custom or *.up.railway.app).

Server logs prove application processes each request in 0-5ms, so latency is entirely between Fastly edge and Railway upstream. Cached apex HTML serves in 0.4s, so the edge

works -- only origin fetches are broken.

Client service URL also intermittently returns 502 with same 12.6s TTFB.

Latency, consistent across many runs:

bloomleave.com/ GET 0.44s cached

api.bloomleave.com/api/health GET 12.56s

bloom-lmsclient-production.up.railway.app/ GET 12.62s 502

bloom-lmsserver-production.up.railway.app/api/health GET 12.51s

POST api.bloomleave.com/api/auth/login 12.46s

curl breakdown for api.bloomleave.com: DNS 0.002s, TCP 0.012s, TLS 0.044s, TTFB 12.56s.

Already ruled out:

- Application code (server log shows 0ms processing)

- Express bind (explicit 0.0.0.0)

- Stale custom-domain routing (deleted + recreated via GraphQL, fresh CNAME, no change)

- Missing service domain (added via serviceDomainCreate, same 12.5s)

- HTTP version, method, cache-busting query strings -- no difference

Please investigate:

1. Is the Fastly-to-Railway origin path degraded for this project or us-west2 today?

2. Why does the client bare service URL return 502 with 12.6s wait? Looks like connection retry.

3. Anything I can configure (healthcheck path, replicas, region) to improve routing? healthcheckPath is null on both services.

Reproduce:

curl -w 'TTFB %{time_starttransfer}s\n' -o /dev/null -s https://api.bloomleave.com/api/health