6 days ago
We're facing problems with the new HA Static IPs since the migration.
The new IPs was already added to firewall's whitelist but it can't reach our local servers.
The services that wasn't migrated keep working fine. The problem is the new HA Static IP
syscall: 'connect',
AggregateError [ETIMEDOUT]:
at internalConnectMultiple (node:net:1134:18)
at afterConnectMultiple (node:net:1715:7) {
address: '177****150',code: 'ETIMEDOUT',
port: ****Error: connect ETIMEDOUT 177****150:****
},
at createConnectionError (node:net:1678:14)
Error: connect ETIMEDOUT 191.*****102:****
at Timeout.internalConnectMultipleTimeout (node:net:1737:38)
at createConnectionError (node:net:1678:14)
at listOnTimeout (node:internal/timers:587:11)
at afterConnectMultiple (node:net:1708:16) {
errno: -110,
at process.processTimers (node:internal/timers:521:7) {
code: 'ETIMEDOUT',
errno: -110,
syscall: 'connect',
code: 'ETIMEDOUT',
address: '191*****102',
port: ****
}]
}
]
}
Error fetching clients: AggregateError [ETIMEDOUT]:
at internalConnectMultiple (node:net:1134:18)
at afterConnectMultiple (node:net:1715:7) {code: 'ETIMEDOUT',
at createConnectionError (node:net:1678:14) at afterConnectMultiple (node:net:1708:16) {
Error: connect ETIMEDOUT 177******150:****
at createConnectionError (node:net:1678:14)
errno: -110,
at Timeout.internalConnectMultipleTimeout (node:net:1737:38)
at listOnTimeout (node:internal/timers:587:11)
code: 'ETIMEDOUT',
at process.processTimers (node:internal/timers:521:7) {
syscall: 'connect',
errno: -110,
address: '191.241.33.102',
code: 'ETIMEDOUT',
port: ****
syscall: 'connect',
}
address: '177*****150',
port: ****
},
Error: connect ETIMEDOUT 191*****102:****Stack: AggregateError [ETIMEDOUT]:
at internalConnectMultiple (node:net:1134:18)
at afterConnectMultiple (node:net:1715:7)1 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
5 days ago
The HA setup load balances your outbound traffic across 3 IPs instead of 1, so first thing I'd check is what your traffic is actually leaving from. Open a shell in the migrated service (railway ssh) and run curl -s https://api.ipify.org like 10 times, you should see the IPs rotating. If even one of them isn't in your whitelist (or there's a typo), connections will time out whenever the traffic goes out through that one.
Also double check you actually hit Deploy after updating the allowlist, the new IPs only take effect after a redeploy.
If the egress IPs all match your whitelist, then go look at your firewall logs on the local side: are you seeing dropped SYNs from the new IPs, or nothing arriving at all?
- dropped packets = problem on your side. Rule order, wrong interface, or geo-IP/reputation filtering. Worth checking that last one specifically, the new HA ranges are likely in a different block/ASN than your legacy IP and some firewalls silently drop unknown ranges even when the IP is whitelisted.
- nothing arriving at all = routing problem on the path. Run an mtr from the Railway service to your server's IP and open a ticket with the output, that's on Railway's side to fix.