I would separate the normal Discord gateway from the Discord voice path here.

Your bot being online only proves that outbound HTTPS/WebSocket to the main Discord gateway works. Voice uses a separate voice WebSocket plus outbound UDP to the selected Discord voice server, so the failure can still be voice-path specific.

I would not try to fix this with Railway public networking, custom domains, or TCP proxy settings. Those are for inbound traffic to your service. Discord voice is outbound traffic from your container to Discord.

The fastest useful test is to log the exact voice endpoint and state transition from inside the Railway deployment:

connection.on("debug", console.log);

connection.on("stateChange", (oldState, newState) => {

console.log("voice state", oldState.status, "->", newState.status);

console.log("networking", newState.networking?.state);

});

Then check whether the voice WebSocket reaches a real endpoint under discord.media and whether UDP setup starts after that. If the voice WebSocket never gets stable, this is not primarily a UDP audio issue yet. If the voice WebSocket is stable but UDP never completes, focus on outbound UDP to the remote voice IP and port Discord selected for that session.

I would also add one small UDP sanity check in the same Railway service, using the actual voice IP and port from the debug output:

import dgram from "node:dgram";

const socket = dgram.createSocket("udp4");

socket.on("error", (error) => {

console.error("udp error", error);

socket.close();

});

socket.send(Buffer.from([0]), DISCORD_VOICE_PORT, "DISCORD_VOICE_IP", (error) => {

console.log(error ? error : "udp send queued");

socket.close();

});

That does not prove Discord will accept the packet as a valid voice packet, but it does tell you whether the container can create a UDP socket and attempt egress to that destination. If this errors immediately inside Railway but works from another host, then the evidence points to a Railway egress path issue. If it queues successfully, the next suspect is the Discord voice handshake, IP family, encryption dependency, or runtime behavior rather than a blanket UDP block.

Also verify the runtime dependencies in the deployed image, not only locally:

npm ls @discordjs/voice @discordjs/opus sodium-native libsodium-wrappers tweetnacl prism-media

node -v

For @discordjs/voice, a missing or incompatible encryption/audio dependency can make voice setup fail even when the gateway connection itself is fine.

So I would narrow it down in this order:

1. Log the exact Discord voice endpoint selected during the join.
2. Confirm the voice WebSocket reaches that endpoint from Railway.
3. Test UDP socket creation and send from the Railway container to the selected voice IP and port.
4. Confirm the deployed image has a valid voice encryption and Opus stack.
5. If only step 3 fails on Railway, then it is strong evidence for a Railway outbound UDP or routing regression.