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.
2 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
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
a month ago
I'm able to reach your URL. Have you tried restarting the device or clearing DNS cache?
Attachments
a month ago
What Railway staff likely needs to do:
- Rebind or refresh the existing public domain route for
couplebiblebackend-production-0c71.up.railway.appto the current service and target port8080. - 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 port8080, 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 -> Regionsonly if you know the prior region worked. Railway documents manual rollback there.