Edge routing broken — container healthy but zero inbound traffic
bevatsal1122
PROOP

a month ago

Hi team,

I'm hitting an edge routing issue on a production service and need help restoring it without changing the generated public domain, because that URL is hardcoded in a shipped

iOS app — losing it would break all existing users.

Project / Service:

- Project: Couple Bible Server (production environment)

- Service: CoupleBibleBackend

- Service ID: c83923c9-de79-4876-9406-385852813534

- Environment ID: 2b923d77-d7c7-49f2-... (production)

- Public domain: couplebiblebackend-production-0c71.up.railway.app

- Region: europe-west4-drams3a

Symptom:

External clients hitting https://couplebiblebackend-production-0c71.up.railway.app receive ERR_CONNECTION_RESET (curl returns HTTP 000, browsers show "The connection was

reset"). This started after a redeploy around 2026-04-11 15:53 GMT+5:30.

Container is healthy:

- Deploy logs show the app starting correctly:

Starting Container

> node dist/index.js

Server is running on port 8080

- Service status shows "Active / Online"

- Metrics show the container running (low CPU, stable memory)

- The container successfully makes outbound HTTPS calls (Supabase via Cloudflare)

Smoking gun — Network Flow Logs:

Since the 15:53 deployment, Network Flow Logs show only outbound TCP connections from the container (10.250.19.6: → 104.18.38.10:443 / 172.64.149.246:443

Cloudflare/Supabase) and DNS lookups. There are zero inbound TCP connections to 10.250.19.6:8080 — meaning no external request is reaching my Express server at all. This looks

like the edge proxy is accepting TLS at the public domain but has no valid route to forward to my container's port.

Confirmed NOT my code:

- process.env.PORT || 8000 in src/index.ts, app.listen(port) — standard config.

- The exact same build runs cleanly locally (yarn build && yarn start) and serves traffic on all routes without issue.

- Settings → Networking shows the public domain correctly mapped to Port 8080 — matching what the container listens on.

Things I've already tried (none fixed it):

- Multiple redeploys of the active deployment

- Rollback to a previous deployment

- Verified PORT env var and removed any manual overrides

- Confirmed the container starts and listens on 8080 in deploy logs

What I need:

Please re-establish edge routing for this service while preserving the existing couplebiblebackend-production-0c71.up.railway.app domain — deleting and regenerating the domain

isn't an option because the URL is burned into my shipped iOS app.

$10 Bounty

2 Replies

Status changed to Awaiting Railway Response Railway about 1 month ago


Railway
BOT

a month ago

This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.

Status changed to Open Railway about 1 month ago


I'm able to reach your URL. Have you tried restarting the device or clearing DNS cache?

Attachments


intruvurt
FREE

a month ago

What Railway staff likely needs to do:

  • Rebind or refresh the existing public domain route for couplebiblebackend-production-0c71.up.railway.app to the current service and target port 8080.
  • Preserve the existing generated domain hostname while repairing the routing object behind it.
  • Check whether the service was moved across edge/network infrastructure during or after the redeploy, since Railway routes inbound traffic through its edge network and region/platform transitions can coincide with redeploys.

Low-risk things you can try from the UI without deleting the hostname:

  • In Settings -> Networking -> Public Networking, verify the domain still points to target port 8080, then edit/save that target port again to force a route refresh. Railway docs say target ports can be changed at any time and are what tell Railway which internal port receives traffic.
  • If the service has the Metal Edge Network toggle available, toggle it off/on or check whether the service changed platform/region around the failing deploy. Railway exposes that setting in the Public Network section.
  • If the failing deploy coincided with a region/platform migration, try a manual region rollback in Settings -> Deploy -> Regions only if you know the prior region worked. Railway documents manual rollback there.

Welcome!

Sign in to your Railway account to join the conversation.

Loading...