a year ago
In Hetzner cloud, specifically in the US-west region, I would randomly get a connection timed out when connecting to Railway on a public IP.
This works fine if I start my servers in the Finland region or Germany, it's the third time I deploy my app in US-west and the third time I get this issue.
I see someone already posted in here: https://help.railway.app/questions/railway-hetzner-servers-cant-communic-c0257392
My deployment in the Finland and US-west region are exactly the same, I really don't know what's happening.
It's not my postgres client either since connecting with `psql` gives the same result (timeout).
Worst part is that it seems random, from time to time it'll work.
To reproduce, simply start an instance in Hetzner US-west with Ubuntu, then `sudo apt update && sudo apt install postgresql` then `PGPASSWORD=<pwd>psql -h autorack.proxy.rlwy.net -U postgres -p <port> -d railway`
Ping is working:
```
$ ping autorack.proxy.rlwy.net
PING autorack.proxy.rlwy.net (35.212.144.195) 56(84) bytes of data.
64 bytes from 195.144.212.35.bc.googleusercontent.com (35.212.144.195): icmp_seq=1 ttl=104 time=11.3 ms
64 bytes from 195.144.212.35.bc.googleusercontent.com (35.212.144.195): icmp_seq=2 ttl=104 time=11.1 ms
64 bytes from 195.144.212.35.bc.googleusercontent.com (35.212.144.195): icmp_seq=3 ttl=104 time=11.2 ms
64 bytes from 195.144.212.35.bc.googleusercontent.com (35.212.144.195): icmp_seq=4 ttl=104 time=11.2 ms
64 bytes from 195.144.212.35.bc.googleusercontent.com (35.212.144.195): icmp_seq=5 ttl=104 time=11.2 ms
```
Anyone found a way to solve this issue?
4 Replies
a year ago
Hello,
Some context, we run on top of GCP for the time being.
It has been known that GCP blocks or filters traffic from Hetzner.
Unfortunately this is outside of our control at the moment as we are at the whims of GCP.
a year ago
Thank you for your response. In that case, why is it only happening in US-West and not in all of Hetzner cloud? Why is Google doing this, and is there any workaround? Thanks!
I might have to switch to another provider if I can't find a solution with Hetzner, that's too bad because Railway was the perfect fit for my needs :(
a year ago
I'm sorry but I don't have the answers to why or why a particular region.
A workaround could potentially be static outbound IPs on the Pro plan, they would allow you to change your region and stick with a single IP, if that ends up not working either, we would have absolutely no problems refunding the cost of the Pro plan upgrade.
May I also ask what you're running on Hetzner that you couldn't run on Railway as well?
a year ago
May I also ask what you're running on Hetzner that you couldn't run on Railway as well?
Railway runs its instances on top of GCP which instances are pretty costly compared to Hetzner (I know that compared to AWS, Hetzner cloud is ~6x cheaper, I don't know for GCP but it's probably in the same ballpark.)
Hetzner root servers are a magnitude less expensive than GCP/AWS etc...
Costs quickly become an issue when scaling, especially if there is abstraction over abstraction layers (which most of the time, is not needed).
For example, GCP instances are VMs running on top of bare metal machines, railway runs on top of those VMs, and I run containers inside those VMS that are managed by k8s.
I just want bare metal machines that run my stateless containers, that's all, if one machine fails, k8s will take care of moving my pods/containers somewhere else.
DB is different, I can't let a stateful machine like the DB fail with no repercussion, that's why I'm turning to solutions like Railway, but it needs to work with Hetzner IPs.
If not for autoscaling and 99.9999% SLA (both are unnecessary in my case), there is no reason to cut bare metal performances by half with VMs while selling the VMs 10 to 20 times the price a single bare metal costs.