a month ago
Our service uses HA static egress in the sfo region (three gateways:
162.220.232.250 / .251 / .252). Our container consistently egresses from .251,
verified from inside the container via two independent echo services, across two
separate deployments.
.251 is listed by Spamhaus CSS and XBL, and a third-party API we depend on
(api.unas.eu) drops our packets at L3/L4 because of it. We have had no outbound
connectivity to that host for over ten hours.
Spamhaus Zen lookups, 2026-07-26:
162.220.232.250 XBL + PBL
162.220.232.251 CSS + XBL + PBL <- ours
162.220.232.252 PBL only
162.220.232.99 no listing at all (from egressGatewayLegacyPreview)
Other addresses sampled in 162.220.232.0/24 return PBL only, so these are
individual per-IP listings, not a range-level listing.
TCP connect test from inside the container (no application traffic):
api.unas.eu:443 TIMEOUT after 20s — no TCP handshake
unas.hu:443 OK, 351 ms
www.google.com OK, 12 ms
The same host connects in 47 ms from an unrelated network, so it is up and is
specifically dropping our egress address. All our other outbound integrations
are unaffected.
Worth noting: our service sends no email at all (it only reads mailboxes over
IMAP) and makes a handful of API calls per hour, so it cannot plausibly be the
source of a CSS or XBL listing. The failure also started within a minute of a
container replacement, which makes us wonder whether our egress address changed
at that point.
Questions:
-
Are the HA egress addresses dedicated per project, or shared between tenants?
-
Can CSS/XBL listings on Railway egress addresses be remediated, or can a
service be moved to a clean address? Delisting can only be driven by the
address owner.
-
Does the HA gateway fail over between its three addresses — i.e. can our
source IP change without notice? This matters, because .250 is XBL-listed
too, so a silent failover would break us again even after a delisting.
-
egressGatewayLegacyPreview reports a single clean gateway (162.220.232.99,
us-west2). Is rolling back to the legacy single gateway a supported, stable
configuration, and can that address change without notice?
-
Is there any supported way to pin a specific egress address? The API's
egressGatewayAssociationCreate accepts a region only.
Could someone from Railway pick this up? Questions 1, 3 and 4 need internal
knowledge. Happy to provide project and deployment IDs privately.
1 Replies
Status changed to Awaiting Railway Response Railway • 26 days ago
25 days ago
Thanks for the thorough diagnostics, they made this easy to confirm on our side.
To answer your questions directly:
- The HA static egress addresses come from a shared regional pool, they are not dedicated to your project. We checked your service's network flows and confirmed it is not the source of the listing. Your traffic is HTTPS and IMAP only, with no SMTP at all.
- We traced the listing to another workload behind the same gateway generating bulk SMTP traffic, and we are taking action to stop it. Since Railway owns these addresses, delisting has to come from us, and we will pursue remediation with Spamhaus once we've confirmed the traffic has stopped, since a delisting only sticks after the source is contained.
- Yes, the HA gateway can fail over between its three addresses, so your source IP can change without notice. Your observation that the failure began right after a container replacement is consistent with that.
- The legacy single-gateway address is also from a shared pool and is not a supported long-term configuration, so we would not recommend rolling back to it.
- There is currently no supported way to pin a specific egress address, the association is per region only.
In the meantime, if api.unas.eu's operator can allowlist all three addresses (162.220.232.250, .251, .252), that would restore connectivity fastest, though we understand they may decline while the listings are active. We will follow up here as the delisting progresses.
Status changed to Awaiting User Response Railway • 25 days ago
18 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 18 days ago