Some of our Railway-hosted public endpoints

are consistently unreachable from several

Russian networks, while other endpoints in the

same Railway project remain reachable.

We are trying to understand the exact cause

and the supported way to resolve it. Based on

the measurements below, our current

hypothesis is a regional routing, filtering, or

ingress reachability issue. However, we are

open to other explanations, especially if there is

Railway-specific behavior we have not

accounted for.

Fresh measurements were performed from:

Russia:

WestCall, Moscow, AS8595

ER-Telecom, Moscow, AS25446

MTS, Novosibirsk, AS8359

SkyNET, Saint Petersburg, AS35807

Kazakhstan controls:

Kazakhtelecom, AS9198

NLS Kazakhstan, AS200590

The following Railway ingress IPs were

unreachable on public TCP port 443 from all

four Russian networks:

69.46.46.64

69.46.46.65

69.46.46.85

69.46.46.95

69.46.46.105

69.46.46.121

For each of these IPs:

all TCP/443 connection attempts from the

four Russian probes timed out;

TLS did not begin;

no HTTP request could be sent;

both Kazakhstan probes reached TCP/443,

completed authorized TLS, and received an

HTTP response.

The following Railway ingress IPs were

reachable from the same Russian and

Kazakhstan probes:

69.46.46.24

69.46.46.88

69.46.46.98

69.46.46.119

One useful control involves the same Railway

service:

its Railway-provided public domain currently

resolves to 69.46.46.24 and is reachable

from the Russian probes;

its custom public domain currently resolves

to 69.46.46.121 and is unreachable from the

same probes.

This suggests that the behavior follows the

assigned public ingress IP or network path

rather than the deployment itself.

The primary failing test is a raw TCP connection

directly to a numeric IP address on public port

1. Therefore, that particular test does not

involve:

application code;

an HTTP route or response;

a Host header;

TLS/SNI or certificate validation;

DNS resolution;

the application's internal target port.

The deployments themselves are healthy and

respond through the working ingress paths and

from Kazakhstan.

Representative measurements:

Affected TCP/443 — 69.46.46.85: https://

globalping.io/?

measurement=2cl6faMb0cH55p9xb00020o61

Working TCP/443 control — 69.46.46.24:

https://globalping.io/?

measurement=2NBMODu6RQavtSZVz00020o6

1

Affected traceroute — 69.46.46.85: https://

globalping.io/?

measurement=2Nwu19F3m6aPxQIoz00020o63

Working traceroute control — 69.46.46.24:

https://globalping.io/?

measurement=2ndEXSsY5ruRGiYtY00020o63

Our current interpretation is that the connection

is being dropped somewhere between the

affected Russian networks and selected Railway

ingress addresses, before TLS reaches the

Railway edge.

We would appreciate help answering the

following questions:

Can anyone reproduce these TCP/443

results from other Russian networks?

Is there any Railway domain, edge, or

ingress behavior that could explain why

selected IPs are unreachable while other IPs

in the same range and project remain

reachable?

Could any application or Railway service

configuration affect a raw TCP connection to

the public ingress IP before TLS begins?

Is this more likely to be routing, peering,

regional filtering, or something else?

What is the supported Railway remediation

path for this type of regional reachability

issue?

Possible remediation options we have

considered include:

repairing or changing the affected network

route, advertisement, or peering;

reassigning only the affected public domains

to a different Railway-managed ingress or

edge path;

another Railway-supported networking

solution that we may not be aware of.

These are suggestions rather than

requirements. We are open to other

explanations and safer supported solutions.

The working address 69.46.46.24 is only a

diagnostic control. We are not requesting that

every service be moved to that address, and we

do not intend to point DNS records directly to a

Railway ingress IP.

We would also prefer not to delete and recreate

domains or introduce an external proxy unless

there is a clear technical reason and an

understood migration plan.

Our main goal is to determine the real cause

and find a supported resolution that restores

access for affected users without creating an

unsupported or fragile configuration.

Thank you.