Yeah. I had this same issue. Nginx does not support dynamic DNS resolution with the default config. For a temporary fix, restart Nginx, but for something more long-term, you'll have to go deeper. My solution was to use Caddy instead, but I don't believe that's applicable to your setup.

Nginx posted this regarding dynamic resolution last year, have you read through it?

https://blog.nginx.org/blog/dynamic-dns-resolution-open-sourced-in-nginx

Hey, thanks for getting back!

Yeah, I figured it might be something DNS-related. I did go through the NGINX blog post on dynamic DNS resolution, super useful, but still feels like a bit of a hack to get it working cleanly with service names that might change or restart. I get that NGINX doesn’t re-resolve DNS unless you reload, which obviously isn't ideal in a dynamic setup like Railway.

We’re using utility-proxy (NGINX) to route to multiple region-based utility services deployed in the same Railway project, like utility-sg-region-production, utility-eu-region-production, etc. I was hoping that using internal hostnames like http://webhook-microservice-virginia.railway.internal:4000 would work out of the box if Railway handles service discovery internally.

Since switching to Caddy isn’t ideal for us right now, just wanted to clarify a couple of things:

1. Does Railway allow internal DNS resolution between services (like http://<service-name>:<port>) within the same project?

2. Are there any known limitations with cross-region service discovery (SG → Virginia → EU)?

3. If not via DNS, is there a better pattern you recommend for internal routing between services, maybe via shared env vars or static IPs?

Happy to share more logs or setup details if needed. Appreciate the help!

Thanks,
Megha

1. Yes, though they are normalized, it's far better if you use the private domains via reference variables -
   https://docs.railway.com/guides/private-networking#using-reference-variables

   The private domain does not change unless you change it, and even if you did change it, well, it's just a reference!

2. It works without issue, but since Railway hasn't solved the speed of light issue yet, there will, of course, be latency going to different regions.

3. We don't provide static IPs for private networking, so the format shown in the docs link I shared above, plus setting your resolver to 1s is the best solution.

I was hoping that using internal hostnames like http://webhook-microservice-virginia.railway.internal:4000 would work out of the box

It will, as long as the service behind webhook-microservice-virginia is -

- Listening on IPv6
- Listening on port 4000
- The service accessing it is set up to do dynamic DNS resolution.

Note, I'm fairly certain NGINX will require you to specify a nameserver, use fd12::10 as that is the address of the DNS server that operates for the private network.

Hello Brody,

Got it — thanks, that clears things up a lot.

Yeah, I wasn't setting the resolver in NGINX, so that might’ve been the missing piece. I’ll update it to use resolver [fd12::10] valid=1s; and make sure I'm using the private domain from the reference variable instead of relying on service names.

Also good to know about the IPv6 requirement — all my utility services are listening on the right ports, so I’ll double-check that IPv6 is enabled across them.

Appreciate the heads-up on latency across regions too — makes sense, we’ll factor that into our routing logic.

Will give this a shot and ping back if I hit anything weird. Thanks again!

Thanks,
Megha

Hello Brody,

Just wanted to confirm that internal routing via private domains is now working as expected from our utility-proxy (NGINX) service. The key fix was switching from upstream block names to direct http://<internal-host>:<port> values in a map, and setting the resolver to [fd12::10] with valid=1s.

Thanks a lot for the guidance, everything’s stable now!

Thanks,
Megha