14 days ago
Hi Railway team,
I am having a consistent problem with outbound TCP connections from my service. I have done a lot of testing and I want to share all the details so you can help me understand what is happening.
About my service:
- Project name: mge.tf
- Service name: servers-panel
- Plan: Hobby
- Started in us-west-2 region with egress IP 52.9.223.133
- Then I changed the replica location to US East, got new egress IP 34.198.145.100
The Problem:
My service cannot make reliable outbound TCP connections to my NFOservers VPSes:
- Main VPS: 74.91.122.215
- Second VPS: 74.91.114.171
Both are from the same provider (NFOservers, AS400475).
The connections (especially on port 22 for SSH) time out or get dropped. This started happening on the first IP, then again on the second IP after about one day.
### What still works
- UDP traffic to the same NFO servers works fine (game servers on port 27015 respond normally)
- TCP connections from my service to other hosting providers work fine (Contabo, Alice Network, Lowhosting, etc.)
- From my home computer and from other VPSes, I can connect normally to the NFO servers
Important tests we did:
I tested from two different places (from inside one of my NFO VPSes and from my home computer):
To Railway egress IPs:
- Ping (ICMP) to 52.9.223.133 → 100% packet loss
- Ping (ICMP) to 34.198.145.100 → 100% packet loss
- TCP connection to port 22 on both IPs → timeout
This leads me to believe Railway’s egress IPs have very strict inbound firewall rules (they drop ping and some TCP connections from the internet).
What NFO said:
I contacted NFO support. Their CEO (John) personally replied and said:
“It seems as though 52.9.223.133 does have a general firewall on its side, since ICMP is dropped on the path to it from everywhere here, as well as from my home connections.”
He also said they are not blocking AWS on their side.
What we are doing on our side:
Our panel was opening many SSH connections (about 720 attempts per hour per server). We are now working on making it much gentler (using one connection instead of many, adding delays, etc.).
My questions:
1- Is it normal for Hobby plan egress IPs to have such strict inbound firewall rules (dropping ICMP and some TCP traffic)?
2- Could there be any outbound filtering or restrictions on these IPs that explain why TCP connections to NFOservers specifically are failing?
3. What is the best way to solve this long-term without upgrading to Pro plan and Static Outbound IPs?
I am happy to run any tests you need, do traceroutes, or give you exact times when it fails. Thank you very much for your help!
3 Replies
Status changed to Open Railway • 14 days ago
14 days ago
Not sure if I understand the issue correctly but as a note, Railway’s egress IPs cannot be used as inbound IPs. If you want some kind of static IPs for whitelisting purposes, your only option would be to upgrade to the Pro plan to use the static IP feature.
0x5b62656e5d
Not sure if I understand the issue correctly but as a note, Railway’s egress IPs cannot be used as inbound IPs. If you want some kind of static IPs for whitelisting purposes, your only option would be to upgrade to the Pro plan to use the static IP feature.
14 days ago
To clarify the issue: We are having problems with outbound TCP connections from Railway (e.g. SSH to our NFO VPSes on port 22). The connections get dropped or timeout.
This does not happen with other VPSes that I manage through my panel, which is deployed in Railway. Only NFO's machines do this to us. But the NFO CEO told us he does not do anything special to those IPs from their side.
We already confirmed that inbound to our Railway egress IPs is heavily restricted (as you mentioned), but the main problem is the outbound direction to specific destinations (NFOservers).
Is there any known outbound filtering or rate limiting on Hobby plan egress IPs that could cause this? Or is the recommendation simply to upgrade to Pro + Static Outbound IP?
10 days ago
Bump