Hi Railway team,

My production service is unreachable from the public internet despite the

container being healthy and all domains showing "Active" in the dashboard.

This blocks all my mobile app testers from signing in.

## Service details

- Project: caring-spirit (production environment)

- Service: menimle-qac-backend

- Service ID: 5e7cfc3d-e5d4-4a69-9fe3-07faae019aff

- Environment ID: 8865c8e1-5a4f-4812-988d-fed06bd646f4

- Latest deployment ID: 2914fb72-2765-4699-9140-4729e9c87f38 (SUCCESS)

- Region: US West (California)

## Symptom

All three of the following domains route to the same Fastly edge IP

151.101.2.15 and time out at the TLS ClientHello (TCP connects, ClientHello

sent, no ServerHello returned, eventual 25-30s timeout):

1. menimle-qac-backend-production.up.railway.app (Railway-issued)

2. api.runwithme.live (custom, CNAME khvde7dk.up.railway.app)

3. pi.runwithme.live (custom, CNAME idps5tg8.up.railway.app)

curl evidence:

$ curl -v -m 30 https://pi.runwithme.live/api/health

* Connected to pi.runwithme.live (151.101.2.15) port 443

* (304) (OUT), TLS handshake, Client hello (1):

* Connection timed out after 30000 milliseconds

## Service is healthy internally

Deploy logs (deployment 2914fb72):

Starting Container

Requiring external module ts-node/register

Already up to date

DB bağlantısı uğurludur

🚀 Server 8080 portunda işləyir

HTTP logs panel is empty — requests are not reaching the application

container at all. Railway's "Agent" already confirmed this points to a

service-level edge routing issue, not application or DNS misconfiguration.

## Troubleshooting already performed

- Restarted the deployment multiple times

- Triggered a fresh redeploy (2914fb72) — agent did this directly

- Removed and regenerated the Railway-issued public domain

- Added a custom domain (api.runwithme.live) — same timeout

- Removed it and added a different custom domain (pi.runwithme.live) —

same timeout

- Verified TXT record in Cloudflare (DNS only, no proxy)

- Verified CNAME points to the correct *.up.railway.app target

- Confirmed all DNS records are propagated (dig from 1.1.1.1 and 8.8.8.8

return the expected values within seconds)

The fact that three independent domains all hit the same Fastly IP with

identical timeouts strongly suggests Fastly does not have the routing

rule or the certificate for this specific service, even though the

dashboard reports every domain as "Active".

## Request

Please ask the infrastructure team to manually refresh the edge route

mapping / certificate sync on Fastly for service 5e7cfc3d-e5d4-4a69-9fe3-

07faae019aff. The public API does not expose this and our mobile app

beta testers are blocked.

Happy to provide any additional logs or run further diagnostics if useful.

Thanks,

Tural