I'd try removing all associated records from Railway and Cloudflare, waiting for ~10-15 min, then re-add them back.

Thanks @pepper , I'll give that a try. I'm just concerned about hitting my LE rate limit, as Railway has already issued 3 certs for test.runner-x.com, while debugging this issue. Is there a way to reset the LE rate limit if that happens?

From what I understand, IIRC it's 5 certificates per week.

Update after full teardown + SSL mode change:

Followed the teardown steps. Domain recreated, records re-added, CF SSL
now Full (strict), proxy off (grey cloud). Railway control plane is all
green:

• certificateStatus: VALID

• verified: true

• dnsRecords[0].currentValue: tyxzlf5y.up.railway.app (status: PROPAGATED)

• targetPort: 3000

  But test.runner-x.com still returns 502 with x-railway-fallback: true:

  HTTP/2 502
  server: railway-edge
  x-railway-edge: railway/us-west2
  x-railway-fallback: true

  Same service on runner-production-1f2f.up.railway.app returns 200 fine
  — so the service is healthy, and the edge just doesn't have a backend
  registered for the custom hostname.

  Looks like an edge/Fastly routing sync issue on your side; nothing
  left to try from mine. Can someone flush the hostname → origin map
  for test.runner-x.com?

  Project: 9b60ef7b-cf2f-4cfa-a59d-57add229ab13
  Service: 1383d914-93f1-498e-a306-43d7192cd956
  Domain: 3aa53157-4913-4675-a2cb-b3973a3cce74

⏺ Update on custom domain issue (continuation of Discord thread on test.runner-x.com).

Short version: app.runner-x.com on a brand-new production environment works end-to-end. test.runner-x.com on the
original environment (which was renamed from "production" to "staging" after the fact) still returns 502 with
x-railway-fallback: true.

Everything Railway-side is green:

• certificateStatus: VALID

• verified: true

• dnsRecords[0].status: PROPAGATED (currentValue matches requiredValue)

• targetPort: 3000

• syncStatus: ACTIVE

  Service itself is healthy: the staging Railway URL (runner-production-1f2f.up.railway.app) returns 200, so the runner
  service on port 3000 works. Only the custom hostname's edge routing falls through.

  DNS side is clean: dig confirms the CNAME and TXT records from multiple resolvers. Cloudflare proxy is off (grey
  cloud). CF zone SSL is Full (strict). No CAA restrictions.

  Things tried with no effect:

• customDomainUpdate (touched targetPort to same value)

• serviceInstanceRedeploy on runner

• Full teardown of DNS + domain + 15 min wait + recreate (per earlier guidance in this thread)

  Hypothesis: the edge binding for test.runner-x.com is stale after the environment rename, and nothing client-side
  forces a resync. The fact that a freshly-created app.runner-x.com on a never-renamed env works cleanly points at
  something specific to this domain's edge state.

  Project: 9b60ef7b-cf2f-4cfa-a59d-57add229ab13
  Service: 1383d914-93f1-498e-a306-43d7192cd956
  Env: 2d6b0b21-2835-49c4-9e13-751e1275cd55 (renamed production -> staging)
  Domain: 3aa53157-4913-4675-a2cb-b3973a3cce74 (test.runner-x.com)
  Request ID: OWzKQvHpSAG08J1W0_TJvA (502 response just now)

  Can someone force a resync of the hostname → origin map on your edge, or inspect what's wedged?

@pepper ^ 🙏

Set your Cloudflare SSL to Full (not strict).

Also, enable Universal SSL in Cloudflare if you haven't yet.

( steps 5 and 6)

See if that works.

@pepper Tried enabling proxy + Full (not strict) + Universal SSL. Same result:
502 with x-railway-fallback: true, served by Railway's edge
(x-railway-cdn-edge: fastly/…, x-railway-edge: railway/us-west2).
Request ID: 0WjNQyxeQ72tfObPxtoGcA

So the 502 reproduces regardless of whether CF is in the path.

Isolating signal: app.runner-x.com, on a different environment but the
same service (same Dockerfile/runner image, same CF zone, same setup
steps), works end-to-end with cert valid and HTTP 200. Only
test.runner-x.com is stuck. test.runner-x.com has never served a 200 —
including after a full teardown-and-recreate per earlier guidance in
this thread. On your API, everything reads as healthy for this domain:
cert VALID, verified=true, DNS record match, targetPort 3000,
syncStatus ACTIVE. But the edge falls back.

Looks like the Fastly hostname→service map was never correctly set for
test.runner-x.com specifically. Can someone inspect or flush the edge
binding for this domain?

Project: 9b60ef7b-cf2f-4cfa-a59d-57add229ab13
Domain: 3aa53157-4913-4675-a2cb-b3973a3cce74 (test.runner-x.com)

Have you checked the documentation?

Resolved — turned out the fix was renaming the auto-generated service
domain (runner-production-1f2f → runner-test). That flushed the edge
binding, and both the renamed URL and test.runner-x.com started working
directly afterward. May be worth adding to internal troubleshooting
runbooks if other customers hit the same x-railway-fallback: true state
with otherwise-healthy API responses.

Thanks for the help!

There is no such thing as an edge DNS binding, these words don't mean anything in reality.

You had your target port set incorrectly.