69.46.46.0/24 unroutable from a Russian ISP; 66.33.22.0/24 on same account is fine
matushkinvd
PROOP

a month ago

Our audience is in Russia. A share of Russian users cannot open our site at all: the TCP connection to your edge times out. We have isolated this to the edge IP range our domains are assigned to. It is not DNS, not TLS, not SNI, and not our application. The socket never opens.

Our domains (new edge, Server: railway-hikari):

Same Railway account, legacy edge (Server: railway-edge):

  • neuroverdict.com, 66.33.22.137

The controlled test:

Raw TCP:443 only. No HTTP, no TLS, no DNS (we dial the IP directly), via check-host.net. The key is to control for the node. One specific Moscow node, ru1.node.check-host.net, gives a deterministic result:

  • ru1.node.check-host.net (Moscow) to 69.46.46.38:443 => Connection timed out, 3 of 3 attempts
  • ru1.node.check-host.net (Moscow) to 66.33.22.137:443 => OPEN in ~0.04s, 2 of 2 attempts

Two other Russian nodes (ru2 Moscow, ru3 Saint Petersburg) connect to BOTH ranges normally, and so do 28 of 30 nodes worldwide. So this is not a general outage and not flakiness. It is one Russian network that cannot route to 69.46.46.0/24 while routing to 66.33.22.0/24 perfectly well. It looked "intermittent" at first only because check-host samples a random subset of nodes; once you control for the node it reproduces every time.

Raw reports, 69.46.46.38:443 (ru1 Moscow FAILS in each):

https://check-host.net/check-report/446fc810k87b

https://check-host.net/check-report/446fc881k523

https://check-host.net/check-report/446fc8bdk65a

Raw reports, 66.33.22.137:443 (ru1 Moscow CONNECTS in each):

https://check-host.net/check-report/446fc86fk376

https://check-host.net/check-report/446fc8d0kdca

Already ruled out, so you can skip triage:

  • DNS. Russian resolvers return the correct IP (69.46.46.38). The RU nodes resolve fine and then fail to connect.
  • TLS/SNI. Irrelevant. The failure is at TCP connect, before any handshake. Confirmed by dialling the raw IP with no hostname at all.
  • Our app. Unaffected. The same service answers 200 in ~0.4s from everywhere else, and the legacy-edge project on the same account is reachable from the very same Moscow node.
  • IPv6. No AAAA record exists for our hosts.

What we are asking. Please either:

  1. Confirm whether 69.46.46.0/24 is subject to known restrictions or filtering in Russian networks. An RKN block on a neighbouring IP in the same /24 would explain this exactly, as collateral damage to everyone sharing the range.
  2. Move our custom domains to the legacy edge network.
  3. Or assign us an alternate IP outside 69.46.46.0/24.

We are happy to re-run the measurements from any specific Russian nodes you want, or to test a candidate IP from the failing Moscow network before you move us.

Solved$20 Bounty

Pinned Solution

Unfortunately, your only option is to use a VPN to access the sites. Railway isn't able to do anything about this.

You can try proxying your website behind Cloudflare though. (You'll need to migrate to Cloudflare's DNS: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/)

1 Replies

Railway
BOT

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


Unfortunately, your only option is to use a VPN to access the sites. Railway isn't able to do anything about this.

You can try proxying your website behind Cloudflare though. (You'll need to migrate to Cloudflare's DNS: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/)


Status changed to Solved brody about 1 month ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...