6 days ago
Railway's Hikari edge IPs are completely unreachable from my ISP. This is not
limited to Railway's own pages — third-party sites hosted on Railway that
resolve into the same /24 are equally unreachable from this network.
Everything works over VPN, which confirms the problem is path-dependent.
Affected IPs
69.46.46.46 railway.com
69.46.46.25 blog.railway.com
69.46.46.18 a customer hostname under *.up.railway.app
All of them: TCP 443 times out, no SYN-ACK. On 69.46.46.46 I also tested
port 80 (fails) and ICMP (100% packet loss).
My network
AS35362 — LLC "BEST SOLUTIONS", Ukraine (95.158.0.0/18)
DNS is fine — this is purely routing
Resolution is correct and consistent across my local resolver, 1.1.1.1 and
Google Public DNS. All return the same addresses. Note there are no AAAA
records for railway.com, so there is no IPv6 fallback path.
Control test — same machine, same moment
1.1.1.1 Cloudflare anycast OK
8.8.8.8 Google anycast OK
104.18.10.246 Cloudflare CDN OK
So this is not a general anycast problem or a broken upstream on my side.
Only 69.46.46.0/24 is affected.
traceroute -d 69.46.46.46
1 <1 ms
2 1 ms 95.158.0.191
3 1 ms 95.158.0.195
4 1 ms 95.158.0.215 <- last responding hop, my ISP's border
5-20 * * * <- no responses at all
Packets die immediately after leaving my ISP's network.
Routing context (from RIPEstat)
-
69.46.46.0/24 is announced by AS400940 and is globally visible —
324 of 326 RIS full-feed peers see it. So this is not a global withdrawal.
-
AS400940 appears to be single-homed: every observed AS path goes through
AS60068 (CDN77/Datacamp). Examples: 1299 60068 400940, 2914 60068 400940,
3257 60068 400940, 174 60068 400940.
-
AS35362 has no direct adjacency with AS60068. Its upstreams are
AS44600 (Gigatrans UA), AS3326 (Datagroup), AS50263 (1-IX),
AS60159, AS3303, AS6768, AS6663, AS30886.
-
The prefix showed unusual churn between Aug 12-15: 347 announcements and
12 withdrawals, the most recent at 2026-08-15 00:22 UTC. Possibly related.
Other ISPs in my region reach Railway normally, and the site loads fine from
external vantage points — which points at a specific broken junction between
AS35362's transit path and AS60068, rather than anything global.
4 Replies
6 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 6 days ago
6 days ago
Users from/around Russia have reported issues reaching Railway’s servers.
Unfortunately, Railway isn’t able to do anything about regional/ISP blocks. Your only option would be to use a VPN.
6 days ago
Small correction that I think caused the misunderstanding: I'm in Ukraine,
not Russia. AS35362. There is no block on Railway here.
I'd like to push back on the "regional/ISP block" diagnosis, because the
signature doesn't match one:
-
DNS is untouched. railway.com resolves correctly and identically via my
local resolver, 1.1.1.1 and Google Public DNS.
-
No RST injection, no TLS/SNI reset. The connection isn't torn down —
SYN packets simply vanish. Nothing ever answers.
-
The failure is scoped to a single /24, not to a service name. From the
same machine at the same moment, 1.1.1.1, 8.8.8.8 and 104.18.10.246
(Cloudflare CDN) all connect fine. Only 69.46.46.0/24 is dead. No
filtering system blocks one Railway /24 while leaving every other
foreign CDN reachable.
What the evidence does point to: 69.46.46.0/24 is a young prefix (first
seen in the global table 2026-05-12), single-homed behind AS60068
(CDN77/Datacamp) — every observed AS path goes through it — and it showed
347 announcements and 12 withdrawals between Aug 12-15, the most recent at
2026-08-15 00:22 UTC.
Two concrete things that would settle it:
-
Could you (or CDN77) run a traceroute from the Hikari edge back toward
95.158.0.0/18? Routing is asymmetric and my traceroute only shows the
forward path — if the return path is the broken one, I cannot see it
from here.
-
Could you check whether 69.46.46.0/24 is propagating correctly to
AS35362's upstreams: AS44600 (Gigatrans UA), AS3326 (Datagroup),
AS50263 (1-IX)?
For what it's worth, your own Hikari post describes doing exactly this kind
of per-network traffic engineering, including the Liberty Global BGP
communities issue — so this seems like it falls within what's actionable
on your side.
6 days ago
I mentioned users from/around Russia, not purely from Russia.
If using a VPN allows you (or other users) to access the sites that are hosted on 69.46.46.0/24, then it's possible that traffic to that IP is blocked by your ISP.
0x5b62656e5d
I mentioned users from/around Russia, not purely from Russia. If using a VPN allows you (or other users) to access the sites that are hosted on `69.46.46.0/24`, then it's possible that traffic to that IP is blocked by your ISP.
6 days ago
Update: connectivity restored on its own a few hours later, with no changes
on my side — same ISP, same connection, no VPN. My traceroute now completes
in 11 hops:
95.158.0.215 AS35362 (my ISP border)
45.14.110.252 AS6768 (Eurotele-Plus)
80.77.167.1 AS28917 (Fiord)
84.17.32.86 AS60068 (CDN77)
69.46.46.46 AS400940 (Railway) 37ms
railway.com returns 200, server: railway-hikari, x-hikari-trace: ams1.aydy
The missing segment was in transit, past my ISP's border — not a filter at
the edge of AS35362. An ISP block would not lift by itself overnight while
I changed nothing. Given the 12 withdrawals on 69.46.46.0/24 between
Aug 12-15, I'd expect this to recur, so it seems worth a look at the
AS6768/Fiord -> AS60068 path rather than closing it as a regional block.
Status changed to Solved alefantasy • 6 days ago