Public domain unreachable (connection refused) despite healthy container — service-specific, not regional
danielocampodev-182
HOBBYOP

11 days ago

Subject: Public domain unreachable (connection refused) despite healthy container — service-specific, not regional

Project: olimpiadas-fiestas-patrias (ID: 86d578ba-19f0-416e-8ada-83bfc7832c21)

Service: olimpiadas-fiestas-patrias (ID: 6bb9831e-d551-4a87-83fc-04fddba94eb6)

Environment: production

Region: sfo

Symptom: The public domain (olimpiadas-fiestas-patrias-production.up.railway.app) has been unreachable from the outside (connection refused / timeout) for a few days, even though the container itself is healthy.

What I've verified:

Deployment status: RUNNING, no crash/restart loop.

App logs show gunicorn starting cleanly and listening on 0.0.0.0:8080.

Domain "Target port" is correctly set to 8080 (matches).

Domain sync status: ACTIVE.

I deleted and regenerated the service domain (new domain ID) — same result, and it resolves to the same edge IP (146.112.61.110) which still refuses/times out connections from multiple independent networks.

railway ssh into this service also hangs/times out — same failure mode as HTTP.

Another service in this same workspace, same region (sfo), works perfectly and resolves to a different edge IP (69.46.46.x) — so this doesn't look like a regional outage, just this specific service/domain routing.

Ask: Could you check the health/routing of edge node 146.112.61.110 for this service, or reassign it to a healthy edge? App-side config looks correct; this looks like a stuck routing entry on Railway's edge for this service.

Happy to provide deployment ID or further logs if useful.

$10 Bounty

2 Replies

Railway
BOT

11 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway 11 days ago


Try using a VPN. I’m able to access the site just fine.

image.png

Attachments


kaijakagi-sys
FREETop 10% Contributor

3 hours ago

The reported IP is the key discrepancy: 146.112.61.110 is a Cisco Umbrella/OpenDNS block-page address, not the Railway edge to investigate. Cisco's official block-page table lists that exact address for several filtering categories. This does not establish that your site contains malware or identify which category/policy applied.

At 2026-09-08 06:32 UTC, I checked public DNS for olimpiadas-fiestas-patrias-production.up.railway.app through both Google and Cloudflare. Both returned 69.46.46.122, with a 60-second TTL—not 146.112.61.110. These are current, outside-network measurements, not a reconstruction of your original failure; DNS answers can change, so don't hard-code that IP.

On an affected device/network, check the answer from its configured resolver:

nslookup olimpiadas-fiestas-patrias-production.up.railway.app

If it still returns 146.112.61.110, ask the network/DNS administrator to inspect the Umbrella/OpenDNS event and policy/category for this exact hostname and request a classification review if appropriate. No service recreation or filter bypass is needed to identify that discrepancy. The moderator being able to load the site is consistent with different DNS/filter paths.

This explains why the quoted IP should not be treated as a failed Railway edge. It does not establish the cause of the separate SSH timeout, and I have not tested your affected network or changed any deployment.


Welcome!

Sign in to your Railway account to join the conversation.

Loading...