This thread was created 4 days ago and has yet to receive a response aside from the status change. Is there anything additional that I need to provide?

Wondering if Railway blocks certain ports internally, or if there’s a workaround (like binding to specific interfaces or using IPv4 instead)?

Unless I'm mistaken, Railway services are only allowed to expose one TCP port. Currently, that port is exposed to actually connect to the application via IPv4. Hence why I'm attempting to use RCON via Railway's IPv6 private networking.

If that’s the case, I guess using something like an internal proxy or tunneling everything through the main exposed port might be the only workaround, unless Railway eventually allows more flexibility with internal port access.

Alright, I popped a socat binary in the container and have forwarded a local port to the server's IPv6 RCON address as suggested by buhhhrandon (kudos to you, friend). This works, and the bot can successfully execute RCON commands through this bridge — suggesting the server and bot can reach each other over private networking, but something about direct IPv6 connectivity is going haywire.

I'd love insight on:

• Whether direct IPv6 connections between services are supported or intentionally restricted

• Whether exposing a second port internally or setting up a reverse proxy is a better long-term solution

Much appreciated for the help.

Hey — sounds like you’ve already done a solid job debugging this!

If the service is bound to tcp6 :::25575 and DNS is resolving to the .railway.internal address, that’s usually enough — inter-service networking over IPv6 should just work inside the same Railway project.

That said, a couple of things to double-check:

1. Ensure the target service is actually listening on all interfaces, not just localhost or ::1. Even though /proc/net/tcp6 shows ::: it’s worth explicitly binding to :: in your server code if you haven’t.

2. No need for any special configuration to allow custom ports like 25575 — Railway doesn’t block inter-service traffic on non-standard ports internally.

3. Since you’re using Python sockets, double-check you’re setting up the AF_INET6 socket type and using the full tuple for IPv6 (including flowinfo and scopeid if needed — depending on the library you’re using).

Also, just in case: try doing a simple telnet <service>.railway.internal 25575 or even a small Python test script inside the bot container to confirm the connection manually. Sometimes it helps isolate whether it’s your RCON logic or the actual network connection failing.

Your suggestion inevitably led to a temporary solution for my problem. Thank you for your help. I think you've earned this reward. Since that, I did some more review and came to the conclusion that the package I was using was forcing IPv4 connections no matter what I tried. I have made a small class, tested it, and verified that it achieves my goal.