6 days ago
Hello Railway team,
Our two production services are unreachable from the network of our website's
hosting provider. The apps themselves are healthy and serve traffic normally from
everywhere else — the problem is inbound reachability of your edge range from one
Ukrainian network.
PROJECT
Project: gladiolus-bot (bf6b6f11-eea6-4ed3-b456-fdf15001c7c9)
Environment: production
Service 1: gladiolus-bot (fff3c70c-3654-4553-a388-039f816bf422)
gladiolus-bot-production.up.railway.app -> 69.46.46.78Service 2: oda-osnova (9d9d1e47-9ef7-4517-884f-ccc401c59226)
oda-osnova-production.up.railway.app -> 69.46.46.109AFFECTED SOURCE
Our WordPress site, shared hosting ukraine.com.ua (adm.tools), Ukraine.
Outbound IP: 185.104.44.197
SYMPTOM
TCP connections never establish: SYN is sent, nothing comes back.
PHP fsockopen -> errno 110 "Connection timed out"
curl -> error 28, connect_time = 0.00Both ports 443 and 80 fail identically, so this is not TLS or HTTP related.
DNS resolves correctly and consistently; forcing IPv4 changes nothing
(these hostnames have no AAAA records).
TIMELINE
Worked normally until 2026-08-14 ~18:45 EEST.
Already broken by 2026-08-15 19:48 EEST.
Nothing was changed on our side — no DNS, no domains, no plan changes.
EVIDENCE THAT IT IS THE WHOLE EDGE RANGE, NOT ONE IP
From the affected host I scanned 30 addresses spread across 69.46.46.0/24,
including .46 (railway.com), .53, .78, .96, .109, .120 and .1 through .250.
ALL 30 time out on port 443.
This means IP rotation would not help us: every address in the range is
equally unreachable from this network.
At the same time, from the same host in the same seconds:
backboard.railway.com -> HTTP 200 (resolves to a Cloudflare address)
railway.com -> timeout (69.46.46.46)
api.telegram.org, api.wayforpay.com, google.com -> all fine, 0.1-0.2 sSo general outbound connectivity is healthy; only your 69.46.46.0/24 edge
range is affected, and anything of yours behind Cloudflare still works.
NOT THE PROVIDER'S EGRESS
Our hosting provider tested reachability from several of their own servers and
from a separate test VPS in a different network with no egress filtering.
None of them can reach the range either.
RELATED THREAD
This matches "Production domain intermittently unreachable from multiple
Ukrainian ISPs — possible routing blackhole to 69.46.46.96", posted a few hours
ago, where even the Railway dashboard (69.46.46.46) was unreachable from
Ukrainian networks and the traceroute died after the Twelve99 / DataCamp hop.
It looks like the same routing blackhole rather than a per-IP block.
QUESTIONS
-
Are you aware of a routing issue affecting 69.46.46.0/24 from Ukraine, and
is anything being done about it upstream?
-
Since the whole range is affected, IP rotation seems pointless for us —
do you agree, or is there a pool outside 69.46.46.0/24?
-
Is putting Cloudflare (proxied custom domain) in front of a Railway service
the recommended fallback for this situation? We would like to know before
rebuilding our integration around it.
IMPACT
Our website sends order-status notifications to customers through these two
services. While the range is unreachable, every notification silently falls
back to email instead of Telegram, and one customer-facing page in the account
area stops working. This is a live e-commerce site, so it is time-sensitive.
We can provide MTR/traceroute output from the affected host on request.
Thank you.
5 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
Update from our hosting provider: the outbound IP is 185.104.44.197 and their
autonomous system is AS200000 (ukraine.com.ua / adm.tools).
They tested reachability from several of their own servers and from a separate
test VPS in a different network — none of them can reach 69.46.46.0/24 either.
So this affects the whole AS200000 -> your edge range path, not a single source IP.
Could you check for blocks or upstream routing problems affecting AS200000?
Workaround in place: we now proxy our requests through a Cloudflare Worker, which
reaches your edge without any problem — so the services themselves are fine and
only the direct route from this network is broken. We would still like the direct
route fixed.
0x5b62656e5d
Have you tried accessing the URLs with a VPN?
5 days ago
Yes — from other networks (home ISP, VPN) both hosts were always reachable.
That was in the original report: the apps were healthy, only the path from
AS200000 was broken.
Update: as of ~09:00 UTC today the direct route works again from the affected
network — all three IPs (69.46.46.78, .109, .46) connect in ~29 ms, and a direct
HTTPS request returns 200. Nothing changed on our side.
Do you know what was fixed — an upstream/transit change on your end?
Asking because another Ukrainian user reported the same thing the same day and
described it as intermittent, so we are keeping our Cloudflare Worker proxy in
place as a fallback for now.
0x5b62656e5d
Have you tried accessing the URLs with a VPN?
5 days ago
ghg
5 days ago
Resolved — and the cause turned out to be on the hosting side, not yours.
Our hosting provider (ukraine.com.ua, AS200000) investigated: their senior network
engineer found and fixed a fault on one of their routers that affected access to
69.46.46.x. They confirm there was no block on their side — it was a routing
problem, which also explains why another user described the same symptom as
intermittent.
Direct connectivity has been back since ~09:00 UTC on 16 Aug: all three IPs
(69.46.46.78, .109, .46) connect in ~29 ms and return 200.
Leaving this here for the next person with the same symptom: if traffic to
69.46.46.0/24 dies from one network while VPN and other destinations work, ask the
hosting provider to check their routers and transit before assuming a block on
Railway's side. An MTR from the affected host is the fastest way to tell whose
segment it is.
No action needed from Railway — thanks.