a month ago
Issue:
My service deploys and starts successfully (no errors, DB connects fine, all routes mapped in logs), but every request to the public domain instantly (0.1-0.2s) returns 502 with "Application failed to respond" and header x-railway-fallback: true. Network flow logs show the request never even reaches the container — the edge appears to fall back before attempting to route to the service.
Project ID: b80a4df3-0f16-42bf-8389-ad90c2ee8f84
Environment: production
Affected services:
- mongle_back (service ID: 286f09e4-7b2e-49e1-941c-57918065fb70), domain: mongleback-production.up.railway.app
- mongle_back_v2 (service ID: 59f80b30-cc3f-4fbf-8b0f-815fd7a48443), domain: monglebackv2-production.up.railway.app
Sample request IDs from 502 responses:
- HG2mgkMuRx2JS11macI7Nw
- a6XA1gPcTTqNCR14DcO5xA
- j7npXvtBT3WKRTD2JH0Vcg
What I've already tried (none resolved it):
- Verified app listens on 0.0.0.0/process.env.PORT (defaults to 3000), matching the domain's target port (3000)
- Redeployed the service multiple times
- Reset the domain's target port
- Deleted and recreated the domain entirely (same URL reissued, sync status ACTIVE)
- Created a brand-new service (mongle_back_v2) in the same project, connected to the same GitHub repo, with all env vars copied over — same 502 fallback reproduced immediately on first deploy
- Confirmed billing/plan is fine: Hobby plan active, payment method on file, normal billing history (ruled out Limited Trial/verification restrictions)
- Tried scaling to us-west/sfo region — deployment failed outright (likely unsupported on Hobby plan), reverted back to southeast-asia=1
This is a Node.js/NestJS app (Node 20), deployed via Railpack (railpack 0.38.0), on the Hobby plan, region asia-southeast1-eqsg3a.
Since the exact same failure reproduces on a completely new service with fresh config in the same project, I don't think this is an app-level misconfiguration — it looks like something broken at the project/account level in the edge routing layer. Would appreciate help investigating.
3 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Try changing the port the application is listening to to an arbitrary number (eg, 4100), and change the URL to reflect the change as well.
0x5b62656e5d
Try changing the port the application is listening to to an arbitrary number (eg, 4100), and change the URL to reflect the change as well.
a month ago
Thanks for the suggestion! I tried changing the listening port to 4100
(and updated the domain's target port to match), redeployed, and confirmed
in the logs that the app started successfully on 4100 — but the public
domain still instantly (0.1-0.2s) returns 502 "Application failed to
respond" with x-railway-fallback: true.
For context, here's everything else I've already tried, none of which
resolved it:
-
Fixed host binding (app.listen with no explicit '0.0.0.0'/dual-stack)
-
Redeployed the service multiple times
-
Reset the domain's target port
-
Deleted and recreated the domain entirely (same URL reissued, sync
status shows ACTIVE)
-
Created a brand-new service (mongle_back_v2) in the same project,
connected to the same GitHub repo, with all env vars copied over —
the exact same 502 fallback reproduced immediately on its very first
deploy
-
Confirmed billing/plan is fine: Hobby plan active, payment method on
file, normal billing history (so it's not a Limited Trial/verification
restriction)
-
Tried scaling to us-west/sfo region — that deployment failed outright
(likely unsupported on Hobby), reverted back to southeast-asia=1
a month ago
A few more details that might help whoever's looking into this:
Account email: syoojin03@gmail.com
Plan: Hobby (payment method active, billing history normal — ruled out
Limited Trial)
Specific question for the Railway team: Is there a known circuit-breaker
or automated network protection that can get triggered by a crash-restart
loop (like the one I had) and applied at the PROJECT level rather than
per-service? That would explain why a brand-new service in the same
project inherited the same broken state. If something like that exists,
could someone check whether it's stuck "on" for project
b80a4df3-0f16-42bf-8389-ad90c2ee8f84?
Happy to provide any additional deployment/build logs, screenshots of
dashboard settings, or grant temporary access if that helps debug this
faster — just let me know what's useful.
Status changed to Solved yoojin-j • 29 days ago