Our Southeast Asia region runs in Singapore, so services deployed to it are hosted there.

IP geolocation providers build their databases from address registration and their own data sources, not from where we route traffic, so an outbound address can show up as US-located even when the service sending from it is in Singapore. We don't control how third-party geolocation databases classify our addresses.

Outbound addresses aren't reserved for a single service unless Static Outbound IPs are enabled. With Static Outbound IPs, a service gets permanent IPv4 addresses tied to the region it's deployed in, though they may still be shared with other customers, and how geolocation providers label them is likewise outside our control.

Static Outbound IPs are available on the Pro plan, and there isn't an option for assigned outbound IPs on the Trial plan.

Thank you for the explanation.

Unfortunately, this does not resolve the issue. Our application requires outbound IP addresses that are correctly geolocated to Singapore by external services.

We understand that Static Outbound IPs are available on Pro, but your response indicates that accurate geolocation is not guaranteed even with this feature.

Could a Railway networking specialist please clarify:

1. Is there any supported way to obtain an outbound IP that is consistently geolocated to Singapore?
2. Can incorrect IP geolocation records be corrected through Railway or its network provider?
3. Would upgrading to Pro actually help with this issue, or would the same geolocation problem remain possible?

We would like to avoid unnecessary upgrades or infrastructure changes that do not solve the problem.

Thank you.

We can't offer an outbound IP that is guaranteed to be geolocated to Singapore by external services, on any plan.

Upgrading to Pro and enabling Static Outbound IPs gives a service permanent IPv4 addresses tied to the region it's deployed in, which makes them stable enough for destinations to allowlist. Those addresses can be shared with other customers, and how third-party geolocation databases classify them is outside our control, so the same geolocation result remains possible after upgrading.

We also can't commit to getting a third-party geolocation record changed, so if your application depends on external services reporting a Singapore location, upgrading on that basis alone wouldn't guarantee a fix.

Thank you. I understand that Singapore geolocation cannot be guaranteed, even on Pro.

Could a human networking specialist review whether there is any supported way to resolve the mismatch between our Singapore deployment region and US-geolocated outbound IPs?

We are not requesting an infrastructure change, only technical clarification before making a decision.

We don't have a supported way to make outbound addresses from the Singapore region geolocate to Singapore, and that applies to the shared outbound addresses your services use today as well as to Static Outbound IPs on Pro.

What Static Outbound IPs does give you is a stable set of addresses tied to the service's region, so destinations can allowlist them. How external geolocation databases label those addresses stays outside our control, so if your requirement is specifically a Singapore geolocation result, upgrading wouldn't settle that on its own.

Follow-up for a human Railway networking specialist. Binance API support has now checked both IPs already listed in this thread (152.55.188.42 and 152.55.188.6): most of its geolocation sources classify them as US, with only one showing Singapore, causing HTTP 451 for our Singapore-hosted service. Binance advised asking our hosting provider to correct IP geolocation; it cannot disclose its GeoIP vendor. We understand a Singapore result cannot be guaranteed.

1. Can Railway or the upstream IP/network owner actually submit a geolocation correction/geofeed for these addresses? Please distinguish “cannot guarantee third-party updates” from “cannot accept/submit a correction request at all.” If possible, please escalate this as a correction request and provide the process, ticket/reference, required evidence and expected timeframe. If not, can you provide the upstream contact or public geofeed/physical-region confirmation we can use?
2. For our current Trial/shared outbound IPv4, is there a scheduled rotation interval or TTL? If not, exactly what can change the egress IP: redeploy, restart, crash/recovery, host migration, scaling, region changes, maintenance, or normal operation? Can it change without a deployment? Is there any minimum stability guarantee?
3. Are IPs assigned per service, replica, deployment or host/NAT gateway? Can multiple source IPs be used simultaneously or vary by destination? Can the current/possible IP set be inspected?
4. For Pro Static Outbound IPs, which events retain or change the addresses (redeploy, restart, scaling, region move, disable/re-enable), and how are forced changes notified? We are NOT authorizing an upgrade or configuration change.

Please provide technical clarification and any supported correction action only. Do not restart, redeploy, rotate IPs, change settings or billing.

We won't be submitting a geolocation correction or geofeed request for these addresses, and there is no separate upstream network owner to contact, since the range they belong to is registered directly to us. Services in our Southeast Asia region are physically hosted in Singapore, but the HTTP 451 response is a restriction Binance applies and controls, so resolving it has to go through Binance support. Changes on our side, including upgrading, won't clear it.

On your current plan, outbound traffic uses shared addresses that aren't reserved for your service, and there isn't a supported way to pin or select a specific address.

With Static Outbound IPs on Pro, the addresses assigned to a service are stable, which is what lets destinations allowlist them. Each container keeps one address from that set for its lifetime, so replicas may show one address or several, and traffic isn't balanced per connection. Changing the service's region moves it to that region's set of addresses.

I still need a HUMAN networking specialist (brody or team) to review this. Binance has already referred correction to the IP owner; your assistant says Railway owns the range directly and will not submit any correction. Please confirm whether this is Railway staff policy, and whether a formal network/geolocation correction ticket can be opened.

The specific IP rotation question is still unanswered: for NON-static shared outbound IPs, is there any fixed scheduled rotation interval? Can the address change while a container continues running, or only when it is replaced/moved? What events change it, and is there any guaranteed retention period? Please explicitly state if no schedule/stability guarantee exists.

Please also confirm whether the “one address per container lifetime” explanation applies to shared NON-static IPs or only Pro Static IPs. No infrastructure changes are authorized.

Yes, declining a geolocation correction is our position.