Our production booking app on Hostinger cannot connect to its Railway PostgreSQL database today (4 November 2026).

Source: Hostinger server579, outbound IPv4 145.223.89.177 (verified with an IPv4-only external IP check).

Destination: crossover.proxy.rlwy.net:46058, resolving to 66.33.22.252.

Tests from the Hostinger server at approximately 11:09–11:32 UTC:

• Node 24.22.1 and Python both time out opening TCP connections to the proxy, by hostname and IP, before PostgreSQL authentication.
• railway.com:443 also times out.
• backboard.railway.com:443, registry.npmjs.org:443, Microsoft HTTPS and Microsoft SMTP:587 connect successfully.
• The PostgreSQL proxy accepts TCP and responds to a PostgreSQL SSLRequest from my Mac. The database responds normally over Railway private networking and is well below its connection limit.
• Redeploying the same commit did not restore connectivity.

Hostinger reviewed the case twice. Their final response could not conclusively attribute the filtering to either provider or an intermediate network policy. They have not provided a way to restore the existing route through this hosting plan.

A possibly related Hostinger report:

https://station.railway.com/questions/outbound-ip-147-79-99-12-hostinger-tim-9568443f

Could Railway check whether traffic from 145.223.89.177 is being dropped or rate-limited at the edge, and help restore the connection? If a replacement public proxy endpoint is needed, please advise a safe way to obtain one without disrupting the database or its existing private-network clients.