Make sure the application is listening on 0.0.0.0 instead of localhost or something else. I'd also make sure the port your URL is mapped to is the same port your application is listening to.

I’d check the bind address and target port first, because this kind of 502 usually happens when Railway can see the container but can’t actually reach the HTTP server properly.

You should make sure Next.js is listening on 0.0.0.0, not just 127.0.0.1.

Try starting it with:

next start -H 0.0.0.0 -p $PORT

Then check what Railway is actually giving your app:

echo $PORT

and confirm the process is listening on that port:

ss -lntp

You should see something like:

0.0.0.0:3000

or whatever value $PORT is using.

I’d also test it from inside the container:

curl http://127.0.0.1:$PORT

and:

curl http://$(hostname -i | awk '{print $1}'):$PORT

If localhost works but the container IP doesn’t, then it’s definitely a bind issue.

If both work, then you should check the Railway domain settings and make sure the target port matches the port your app is actually listening on. For example, if Railway gives you PORT=8080 but your domain is targeting 3000, you’ll keep getting the 502 even though Next.js says Ready.

For the TCP proxy, you should also make sure you’re connecting to the public port Railway assigned to the proxy, not port 3000 directly. Railway forwards that external port to your internal 3000.

If the app is listening on 0.0.0.0, the target port matches, and you can successfully curl the service using the container IP, but the public domain still instantly returns 502, then I’d say you’ve pretty much ruled out the app itself and it’s likely a Railway edge/routing issue.

The Anonymous reply above already has the two things that matter: the target port has to match the port your app is really on, and a TCP proxy is reached on the public port Railway assigned it rather than on 3000. I would start there and I am not going to repeat either. What I can add is a shortcut, because your own evidence already rules out the half of that reply you would otherwise spend the next hour on.

Skip the bind investigation. You do not need ss -lntp or the curl comparison. Your Network Flow logs are showing successful TCP connections to the service on 3000, and a loopback bind cannot produce that. On top of it, your 502 comes back in a few milliseconds, which is the edge saying it has nowhere to connect, not a server that accepted and then failed to answer. Nothing in your report points at the bind address.

That leaves the port, and there is a Next specific trap worth knowing: plain next start listens on 3000 no matter what PORT is set to. Railway's own troubleshooting page calls this out and gives the fix as next start --port ${PORT-3000}. So if your start command does not pass the port explicitly, your app is on 3000 while Railway injected something else, and the domain that was created for you is pointed at the injected value.

The useful part is that one mismatch explains both of your symptoms at once, the domain and the proxy, which no other single cause here does. And you do not have to guess which side is wrong, because Next prints the port it actually bound on the Ready line in your deploy logs. That line is the truth. Compare it to your domain's target port and to the internal port on the TCP proxy, and make all three the same number.

If all three already agree, then you have genuinely ruled out the boring explanation and the edge question you opened with is the right one to press. I would just rather you not spend the evening on bind addresses to get there.

Application failed to respond, including the Next flag: https://docs.railway.com/networking/troubleshooting/application-failed-to-respond

What does the Ready line in your deploy logs say the port is?