This looks like a network reachability issue before HTTP, rather than an application problem. Multiple Hostinger users have reported similar TCP timeouts to Railway's edge, so this may be broader than a block on 72.60.174.232.

Run mtr -T -P 443 -r -c 50 69.46.46.46 from the affected VPS and ask Hostinger's network team to investigate the route through Cogent and CDN77. A traceroute stopping at CDN77 doesn't conclusively identify where packets are dropped. Railway would need to check edge filtering and return-path routing to confirm whether traffic is being blocked.

For immediate mitigation, try a Cloudflare-proxied custom domain or route requests through another network. That's the fastest way of getting around this issue AND it has been confirmed as well that Cloudflare proxying restores connectivity

Yes Multiple Hostinger users are reporting issues, Multiple KPN users also report problems and then there are a lot of other users reporting connection issues

in multiple countries and multiple providers. Fortinet has marked multiple Railway IP's as malicious so I would not be surprised if all the issues in the 10's of threads

today are related.. in the mean time other then stupid suggestions from the railway bot support is awfully quiet...

I truly hope someone at Railway wakes up soon and investigates what is going on in their network today

Your traceroute matches a pattern several Hostinger servers are hitting today: packets leave Hostinger (AS47583), cross Cogent, and disappear at the CDN77/DataCamp hop (79.127.195.x) before reaching Railway's edge network 69.46.46.0/24 (RLWY-HIKARI-01). So it's a network path problem, not your server or your app. That also explains why your HTTP logs show nothing: the connection never gets as far as Railway.

1. Check whether only some Railway IPs are affected. Run this from the VPS:

for ip in 69.46.46.0 69.46.46.5 69.46.46.113 69.46.46.9; do
  curl -s -o /dev/null -m 8 -w "$ip %{http_code} %{time_connect}s\n" \
    --resolve scraper-service-production-1c9b.up.railway.app:443:$ip \
    https://scraper-service-production-1c9b.up.railway.app/ || echo "$ip timeout"
done

If any IP connects, a temporary /etc/hosts line pinning your three hostnames to that IP will get you working again. Remove it once the route is fixed.

2. Workaround you can do now: *.up.railway.app domains can't go through Cloudflare. Add a custom domain to each service (for example scrape.yourdomain.com), point it at Railway with a proxied (orange-cloud) CNAME in Cloudflare, set SSL/TLS to Full, and have the VPS call that hostname. Your traffic then reaches Railway through Cloudflare and avoids the broken path.

3. Escalate with evidence. Run mtr -T -P 443 -r -c 50 69.46.46.113 and open a ticket with Hostinger that includes the output, your source IP 72.60.174.232, and the start time (Nov 4, between 00:30 and 07:10 UTC). Post the same output here so Railway can check their side of the route.

AI disclosure: I used AI to help draft this answer. I checked myself that your three hostnames resolve to 69.46.46.0, .5 and .113, that those IPs are registered to Railway (RLWY-HIKARI-01), that 79.127.195.76 belongs to CDN77/DataCamp, that 38.142.150.202 is Cogent, that 72.60.174.232 is Hostinger, and that your services respond through Railway's edge from an outside network.

Hi Beckett,

I'm sorry your Hostinger server has lost access to all three production services. Their working from other networks while your VPS connections time out is consistent with the external blocking symptoms covered by our incident.

We've confirmed that a third party is sending scanning traffic using forged Railway source IP addresses. That traffic does not originate from our 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.