Railway’s documented nearest-region routing applies to public traffic. For a multi-region service, the public edge selects the nearest deployment region and then distributes requests among replicas in that region.

Private networking works differently: *.railway.internal bypasses the public edge, and the internal hostname resolves to the service’s internal IP addresses. Railway’s private-networking documentation does not describe or guarantee locality-aware selection among multi-region replicas.

So, with one multi-region private service behind a single <service>.railway.internal hostname, there is no documented setting that guarantees a caller will reach the replica in its own or nearest region.

If same-region routing must be deterministic, the practical approach is:

1. Deploy separately named services for each region, such as worker-eu, worker-us, and worker-asia.
2. Give each service its own private hostname.
3. Read RAILWAY_REPLICA_REGION in the calling service.
4. Map that value to the matching private hostname in application configuration.

For example:

const targets = {
  "europe-west4-drams3a": process.env.WORKER_EU_URL,
  "us-east4-eqdc4a": process.env.WORKER_US_URL,
  "asia-southeast1-eqsg3a": process.env.WORKER_ASIA_URL,
};

const target =
  targets[process.env.RAILWAY_REPLICA_REGION] ??
  process.env.WORKER_DEFAULT_URL;

Configure those URLs using Railway reference variables rather than hard-coding them. You’ll also need to decide how the application should fail over when its local regional service is unavailable.

If using the public hostname internally is acceptable, the public edge can provide Railway’s documented nearest-region routing, but that path no longer has the private-network properties: it passes through the edge and may incur public-network egress.

References:

• Optimize performance and multi-region routing
• How private networking works
• Private domains
• Edge networking
• Deployment regions