a month ago
Subject: Outbound TCP from us-east4 to api.ebay.com IPs (66.211.163.2, 209.140.129.24) connect-timeouts; other eBay IPs work from elsewhere
Service: Website-InventoryTCG (us-east4)
Symptom: Container resolves api.ebay.com to 66.211.163.2 and 209.140.129.24. TCP connections to either IP on port 443 time out after 10s. All other external services (Stripe, Supabase, Scryfall, OpenAI, Pokémon TCG API, YGO, etc.) connect normally — confirmed via /api/debug/dns endpoint.
Independent confirmation eBay is up: From a ProtonVPN exit, Test-NetConnection api.ebay.com -Port 443 returns TcpTestSucceeded: True (resolved to 209.140.142.13 — a different eBay edge IP). So eBay's CDN is alive; only the IPs Railway hands my container can't be reached.
Sentry trace: Latest event 38199c8079384a75a9fd248cf03a15a0 — ConnectTimeoutError.
Ask: Please check whether outbound TCP from my service's egress IP(s) to 66.211.163.2:443 and 209.140.129.24:443 is being dropped by Railway's network OR by eBay rejecting your egress range. This is independent of DNS.
"Issue began after a series of deploys today. Service was working fine earlier (successful eBay API call at 4:08am UTC publishing 3 listings). After multiple subsequent redeploys (~10 commits, each triggering container restart), outbound TCP to api.ebay.com began failing consistently. Suggests a specific subset of Railway nodes in our region have broken routing to eBay's IPs. A redeploy that lands on a healthy node would resolve."
3 Replies
Status changed to Open Railway • 26 days ago
25 days ago
I'm not sure what happened but it seemed to have resolved itself after an hour.
25 days ago
Hitting the exact same issue from us-west2 right now — different region, same symptom.
Service: Node app calling api.ebay.com / OAuth token endpoint
Region: us-west2
Started: 2026-04-27 15:21 UTC, still failing ~45 min in
Identical error class:
UND_ERR_CONNECT_TIMEOUT
attempted addresses: 66.211.166.2:443, 209.140.129.1:443
timeout: 10000ms
Different IPs from yours but same eBay edge ranges (66.211.x and 209.140.x). From a UK home connection both of those IPs accept TCP in ~150ms and a full HTTPS handshake completes in ~500ms, so the eBay side is healthy globally — it's specifically Railway egress that can't reach this subset.
Two data points worth flagging for the investigation:
1. Two different regions (us-east4, us-west2) hitting the same
destinations within ~14h — looks broader than a single bad node.
2. I restarted the service and the new container hit the same
timeouts immediately — so for me at least, "redeploy lands on a
healthy node" isn't sufficient.
All other outbound from the service is healthy (Discord webhooks, our own Postgres in the same region, public web traffic).
25 days ago
Update from us-west2: still failing 2h+ in. No improvement, no recovery. Confirmed eBay IPs are reachable globally (TCP connects in ~150ms from a UK home connection to the same IPs Railway is timing out on). This is consistently reproducible from us-west2, not transient.
Definitely a Railway egress issue, and longer-running than the ~1h precedent above. Could someone at Railway look at egress routing from us-west2 to the 66.211.x and 209.140.x ranges?