a month ago
Internal DNS resolution for *.railway.internal hostnames fails in PR environments, even when all services are
deployed and running.
Environment: PR environment (web-pr-224)
All services are deployed and healthy on the canvas.
web-dev (Next.js frontend) cannot reach rest-api-dev.railway.internal (API backend). The env var
NEXT_PUBLIC_API_HOST is set to http://rest-api-dev.railway.internal, which works in the development environment
but fails in the PR environment.
Error from web-dev logs:
Proxy request failed for http://rest-api-dev.railway.internal/api/v1/workspaces
TypeError: fetch failed
[cause]: Error: connect ECONNREFUSED fd12:e099:d6e8:0:5000:b6:6eff:aa67:80
DNS resolves to an IPv6 address but connection is refused. All API routes return 502.
Static assets serve fine from web-dev's public URL. Only internal service-to-service communication is broken.
These same services communicate fine in the development environment. The issue is specific to PR environments.
Base environment: development
PR: #224
11 Replies
a month ago
Your rest-api-dev service is currently in QUEUED status in the PR environment, meaning it is not running and cannot accept connections. This is likely why the same hostname works in your development environment but fails here. If you have Focused PR Environments enabled, only services affected by the PR's changed files are deployed, and others (like rest-api-dev) are skipped - you can manually deploy skipped services from the canvas. Additionally, your URL http://rest-api-dev.railway.internal/api/v1/workspaces has no port specified, so it defaults to port 80, which is almost certainly not the port your API listens on - you need to include the explicit port (e.g., http://rest-api-dev.railway.internal:3000).
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
Hello,
the error shows dns is resolving fine (you got an ipv6 address back) so the service is reachable, the problem is the connection is being refused on port 80. your url http://rest-api-dev.railway.internal has no port, so it defaults to 80, which is almost certainly not the port your api is listening on. just add the explicit port your api runs on, like http://rest-api-dev.railway.internal:3000 (replace 3000 with whatever port your api actually uses)
Hope this help you :)
domehane
Hello, the error shows dns is resolving fine (you got an ipv6 address back) so the service is reachable, the problem is the connection is being refused on port 80\. your url <http://rest-api-dev.railway.internal> has no port, so it defaults to 80, which is almost certainly not the port your api is listening on. just add the explicit port your api runs on, like <http://rest-api-dev.railway.internal:3000> (replace 3000 with whatever port your api actually uses) Hope this help you :)
a month ago
That is not case 80 my default port and the same setup works in development environment. Can anyone from @railway answer this.
a month ago
Can anyone from @railway answer this.
a month ago
okay, what is the actual port your api listens on, and is it included in the url in the pr environment? and in the dev environment what is NEXT_PUBLIC_API_HOST set to exactly , is it also rest-api-dev.railway.internal or something different?
a month ago
port is 80. they are all set matching dev env no change
a month ago
Since your internal API URL is resolving to an IPv6 address. Your API server needs to bind on :: instead of 0.0.0.0, so it can handle IPv6 traffic.
Plus, when using Next.js, you should set NEXT_PUBLIC_API_HOST to the server's public URL not internal URL, unless you only use it inside server actions, RSC, or API routes. If NEXT_PUBLIC_API_HOST is used on the client, DNS resolution will fail, and users' browsers won't be able to send requests to your server's internal URL. Because internal URLs can't be accessed from the public network.
a month ago
I didnt do that in dev why should that change in a PR env?
I didnt do that in dev why should that change in a PR env?
a month ago
If your dev environment is your local machine, then what I said regarding NEXT_PUBLIC_API_HOST wouldn't matter. But you should definitely consider my suggestion in a production environment. As for IPv6, your localhost resolves to IPv4. So, you wouldn't have a problem with that either.
So these issues arise in a production environment most of the time.
a month ago
dev environment is also hosted on railway not on local