Your service is responding normally when traffic reaches it, and our probe a few minutes ago got a normal response from your login page.

We don't run traceroutes or other outbound diagnostics from our servers, so the path data has to come from your side: could you run the Network Diagnostics tool from an affected machine on your office network, plus a traceroute to 69.46.46.60 and to 69.46.46.46 from both the office and the external network, and send the reports here with the exact UTC times of each failure, including the earlier outage today?

Thanks. NetDiag report from our office, 2026-11-04 12:31 UTC (client IP, hostname and location redacted for this public thread; ISP is AS5617 Orange Polska, Warsaw area; happy to share privately):

routing-info-production.up.railway.app resolves to 69.46.46.119. HEAD returns 200 via X-Railway-Edge: waw1, ping shows 0% loss at 5–8 ms, traceroute reaches it in 8 hops. All OK.

But that is not the IP our domain resolves to. At the same time (12:26–12:33 UTC):

Our service domain resolves only to 69.46.46.60 (system DNS, 8.8.8.8 and 1.1.1.1).

69.46.46.60 fails completely: ping 100% loss, TCP 443 times out, traceroute dies right after our ISP’s first hop.

The same request with our hostname forced to 69.46.46.119 / .63 / .46 is answered instantly by our app via waw1.

So the edge network works for us. The problem is that our domain’s DNS points to 69.46.46.60, which is unreachable (at least from Orange Polska AS5617). Could an engineer check 69.46.46.60 and/or point our domain at a working edge IP?

From our side, 69.46.46.60 is accepting connections and serving your app normally right now: a probe to your service domain through that address just returned your login page with a valid certificate. That address is part of our shared anycast edge, so where your traffic lands depends on the network path. Your results (the same edge reachable on other addresses, while 69.46.46.60 fails right after your ISP's first hop) point to the path from your networks to that one address being dropped.

We can't assign a specific edge IP to a domain or exclude one from it, and redeploys or region changes don't change which edge IP a domain resolves to. The lasting option for users on networks that can't reach that address is to put a proxy or CDN in front of your domain whose IPs those users can reach.

To narrow down the external-network failure, could you share the traceroute to 69.46.46.60 from that network and its ISP name, plus the exact UTC times of the earlier outage today and whether it hit the same address?

Thanks. Two unrelated networks fail on 69.46.46.60, so this doesn’t look like a single-ISP path issue:

Our office (Orange Polska AS5617, Warsaw): 69.46.46.60 is black-holed right after the ISP’s first hop. The waw1 addresses .119, .63 and .46 work from the same network.

A third-party cloud HTTP fetcher (not our network, so we can’t traceroute from it) got “connect ECONNREFUSED 69.46.46.60:443” earlier today and again around 12:40 UTC. That is an active refusal, which suggests that the PoP serving 69.46.46.60 to that network isn’t listening on 443.

Since .60 is anycast, could you check which PoPs announce 69.46.46.60 and whether all of them are actually serving 443?

Our probe to your service domain through 69.46.46.60 just now got your login page with a valid certificate. So that address is answering on 443 from where we test, but this single result can't tell us whether every location serving 69.46.46.60 behaves the same way, and it doesn't rule out the refusals your cloud fetcher saw.

An active ECONNREFUSED from an unrelated network is a different symptom from the black hole on your office network, and it's the more useful lead here. Could you share the fetcher's provider and region (or the source IP it connects from, if it shows it), plus the exact UTC timestamps of each refusal today, including the earlier outage?