Additional info: the affected service is NocoDB at bruttus.setor13.com.br (CNAME wy7yy1ib.up.railway.app, resolving to 69.46.46.9). It loads normally from other networks, so the service itself is up. Only traffic from 187.77.53.108 is timing out.

I am sure this is all related to all the other IP block and connection issue threads from today, even railway.com is not accessible from some providers

I have seen threads where users apps are marked malicious by google safe browsing, Fortinet has blocked multiple edge ip's.

It is a big mess again and Railway should be investigating what's going on and fix it..

Your MTR points at the transit path, not your VPS or your NocoDB service.

• Your source 187.77.53.108 is Hostinger (AS47583). The destination 69.46.46.0/24 is Railway's edge (RLWY-HIKARI-01, AS400940).
• The last hop that answers, 79.127.195.139, is registered to CDN77/DataCamp (CDN77-P2P), a transit network.
• Loss on middle hops in MTR is often just routers limiting their ICMP replies. What matters is that nothing answers from hop 14 to the destination, which suggests packets are dropped somewhere between that transit network and Railway.
• status.railway.com shows no incident.
• From another network, 69.46.46.9, .100, .67 and .101 all serve bruttus.setor13.com.br with its own certificate (HTTP 200), so any of those edge IPs can serve your domain.

1. Test from the VPS

curl -v -o /dev/null -w 'connect=%{time_connect}s total=%{time_total}s\n' -m 15 https://bruttus.setor13.com.br/
sudo mtr -T -P 443 -rwc 50 69.46.46.9
for ip in 9 100 67 101; do
  curl -s -o /dev/null -m 10 -w "69.46.46.$ip -> %{http_code} connect=%{time_connect}s\n" \
    --resolve bruttus.setor13.com.br:443:69.46.46.$ip https://bruttus.setor13.com.br/
done

If one IP works, you can pin it in /etc/hosts for now (69.46.46.X bruttus.setor13.com.br). Remove the pin later, because Railway can change these IPs. If all of them time out, the whole /24 is unreachable over Hostinger's path.

2. Workaround: Cloudflare proxy

Your DNS is on HostGator (ns00060.hostgator.com.br). If you move the zone to Cloudflare and proxy bruttus (orange cloud), the VPS connects to Cloudflare's IPs instead of 69.46.46.x. Railway's docs say to set SSL/TLS to Full, because Full (Strict) won't work as intended. Keep the CNAME and TXT records Railway gave you.

3. Escalate with evidence

Post in this thread or a private Central Station thread:

• source 187.77.53.108 (AS47583)
• destinations 69.46.46.9 and .100
• start time 2026-11-04 02:55 UTC
• the full mtr -T report, noting the last responding hop 79.127.195.139 (CDN77)
• the curl output above

Send Hostinger the same MTR, so they can raise it with the transit provider on that path.

AI disclosure: I used AI to help draft this answer. I checked the IP ownership, DNS, status page, docs and the per-IP curl tests myself.

This is a routing asymmetry issue, not a block. Your best options are:

Use a proxy/tunnel to bypass the bad path.

Switch to a different Railway IP if available.

Wait for the peering issue to resolve.

If you need immediate relief, use a tunnel/proxy. It’s the fastest workaround.

Hops 1–10: Clean (0% loss) → Your ISPs internal network is fine.

Hops 11–13: 50–60% loss → This is where the problem starts. The last responding hop is 79.127.195.139, which belongs to AS43541 (Telefónica Brasil / Vivo).

Hop 14+: No response → Traffic is being dropped after leaving the Telefónica peering link toward Railway’s network (69.46.0.0/16).

Railway services often have multiple IPs. Check if your service has another A record or IP address:

In your Railway dashboard, look for alternative IPs for your service.

If you’re using a custom domain, try pointing it to a different Railway IP via DNS.

1. Route Through a Proxy

Use a Cloudflare Tunnel (cloudflared) or ngrok to tunnel your traffic to Railway. This bypasses the bad peering link entirely.

Example with Cloudflare Tunnel:

cloudflared tunnel --url http://localhost:YOUR_PORT

Then point your app to the Cloudflare URL.

also uyo can try and Ask Hostinger if you can assign a different egress IP to your VPS. A different IP might take a different route to Railway.

Some providers let you add secondary IPs; use one of those instead.

Your server IP: 187.77.53.108

The MTR showing loss at hops 11–13

Note that other sites work fine

Ask if they have known routing issues from AS43541 (Telefónica Brasil) to their network.

agin if you need immediate relief use a tunnel/proxy. It’s the fastest workaround.

Update: Hostinger confirmed in writing that outbound connections from 187.77.53.108 to 69.46.46.0/24 on TCP 443 are blocked by Hostinger's network firewall, because 69.46.46.9, .100, .67 and .101 are flagged with a high abuse confidence score (see AbuseIPDB). They refused an exception. Since these are Railway's shared edge IPs, could the Railway team look into the abuse reports on this range, or offer a different edge IP/route for my service?

Yes Fortinet https://www.fortiguard.com/ has also marked railways IP's as malicious making then unreachable from multiple ISP's and multipole countries

this has been going on for the last 8+ hours there have been multiple reports there are over a dozen threads.. and still no reply or action from Railway..

Thank you for sharing Hostinger's written confirmation of the reputation-based block and its refusal of an exception. I'm sorry this has prevented your server from reaching the affected Railway addresses. We've confirmed that forged-source scanning traffic is behind the broader false-listing incident.

That traffic does not originate from Railway's network. Railway's infrastructure, including our networking, is fully operational. We're in the process of contacting ISPs, security vendors, and abuse database providers to have the resulting false blocks and reputation listings corrected.

It would also help if you could share the incident notice with Hostinger and ask them to allowlist Railway's affected IP ranges for legitimate connections to your services.

Please follow the incident page for further updates. Access from individual networks may remain affected until their blocks are lifted.