a month ago
Subject: Edge routing blackhole for api.formo.so (service f45015a3-b68a-4f65-aa2f-3214bd1c7e49)
Details:
Service: api (ID: f45015a3-b68a-4f65-aa2f-3214bd1c7e49)
Domain: api.formo.so → dqzp1gpl.up.railway.app → IP 69.46.46.255
Symptom: TCP SYN packets to 69.46.46.255:443 get zero response (i/o timeout). No connection refused, no 502 error page — packets black-hole at the network layer.
Evidence:
Service shows 2/2 replicas online and healthy
No HTTP logs reaching the service (requests never arrive)
railway.app / railway.com respond fine (platform edge is up globally)
DNS resolves correctly
Timing: Started ~[insert time], after successful deployment at 2026-06-04 07:53 UTC
Action taken: Restarted service at [current time]
Ask: Is there a routing sync issue, edge cache corruption, or regional outage affecting traffic to this specific service IP?
2 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
Force a route refresh without restart:
Trigger a redeploy (not just restart) — this forces Railway to re-register the upstream with the edge proxy fresh. If urgent: Set up a temporary CNAME bypass — point api.formo.so directly at a fresh Railway service deployment in a different region to restore traffic while the routing issue is investigated.
a month ago
What spatrickpaul got right:
Triggering a redeploy (not just restart) is correct — it forces Railway to re-register the upstream with the edge proxy, which can fix a stale routing entry.
What's missing / more accurate:
This is a classic edge routing desync — the service is healthy and DNS is correct, but the Railway edge proxy at IP 69.46.46.255 is black-holing TCP SYN packets. That means the edge node lost its routing table entry for this service after the deployment on June 4.
Better fix sequence:
Redeploy (not restart) first — as spatrickpaul says
If that doesn't fix it → remove and re-add the custom domain api.formo.so in Railway service settings. This forces the edge to re-provision the routing entry from scratch.
If still broken → change the deployment region in service settings, then redeploy. This moves the service to a different edge node entirely, bypassing the broken IP.
The CNAME bypass suggestion is a valid emergency workaround but adds complexity — try steps 1–3 first.
Bottom line: This needs Railway infrastructure to fix the specific edge node at 69.46.46.255. Community can only work around it — escalate to Railway support with the service ID and that specific IP.