Hello Railway team,

Russian players cannot reach our Lights Out service without a VPN. We reproduced a destination-IP-dependent failure and would appreciate an investigation of the existing ingress route. We want to keep the existing service and plan without adding paid resources.

Affected domains: lightsout.up.railway.app, lightsoutranked.com, and www.lightsoutranked.com. Root and the Railway hostname currently resolve to 69.46.46.123; www resolves to 69.46.46.81. DNS points directly to Railway with no Cloudflare website proxy. Under Attack Mode is disabled, no Edge Rules are configured, and the domains/certificates are active. All three target port 8081.

At 10:09:48-10:09:49 UTC on September 22, 2026, we tested the SAME ten Russian probes plus one German control, keeping TLS SNI/HTTP Host lightsout.up.railway.app and GET /api/health unchanged:

• Current IP 69.46.46.123: all ten Russian probes establish TCP in 25-110 ms, then time out during the TLS handshake at 15 seconds, with no HTTP response. Germany returns HTTP 200 with valid TLS.
• Alternative Railway IP 69.46.46.32: all ten Russian probes return HTTP 200, valid TLS, and the expected Lights Out 2.6.3 health JSON in 180-426 ms. Germany also succeeds.

Failing paired measurement: https://globalping.io/?measurement=2jjyh9GPGw3oumq5C00021BK5

Successful paired measurement: https://globalping.io/?measurement=2WY42aqMg98Ddnw3d00021BK5

Later successful recheck at 10:17:58 UTC: https://globalping.io/?measurement=2YmEzs1uTuzRyk7Ig00021BKD

Russian ASNs: 12389, 41754, 8359, 35807, 8595, 52207, 51570, 29124, 203791, 31357. German control: AS24940. Successful requests through .32 enter ams1, osl1 or cdg1 and reach the same existing upstream zone, railway/us-east4-eqdc4a.

Additional controls from five initial Russian probes plus Germany:

• An unrelated HTTPS control works; TCP443 checks to .123 complete with zero loss.
• Changing SNI between our three names, or omitting SNI for diagnostics, does not fix .123. Plain HTTP80 also connects but receives no first response byte from Russia; Germany gets the expected HTTPS redirect.
• .81 works from three Russian datacenter networks but fails TCP from the two residential probes.
• .32 works with all three existing hostnames, serves the complete catalogue, and answers the installer HEAD request with the expected size. Full Russian downloads, authentication and gameplay are not yet verified.
• TCP traceroute to the failing .123 reaches the destination: https://globalping.io/?measurement=2RgZNAWjfDWu4GLUd00021BJz

We have not changed production DNS or hardcoded an IP in clients. We understand Railway does not support static-IP A records; .32 was only used as a controlled diagnostic destination override, preserving the original hostname and checking certificate authorization.

Could Railway staff investigate whether .123 receives these TLS ClientHello packets and whether replies leave normally, comparing it with .32? We cannot establish externally whether the cause is transit filtering, an edge issue, or another network policy. Is a supported repair or reachable routing assignment possible for the existing domains, especially lightsout.up.railway.app used by installed clients, on our existing plan at no added cost?

Please investigate and explain the proposed change before applying it. Would it affect only the failing paths, all users of these domains, or other services? Please preserve the current deployment region, service/data, hostnames and certificates, and explain expected interruption, connection draining and rollback if other regions regress. Please obtain our confirmation before any production routing change or charge.

Thank you.