We’re seeing what looks like a Railway Metal Edge / WebSocket issue on a staging NestJS service.

Setup

• NestJS app on Railway
• WebSocket endpoint at /voice/ws
• Browser connects with wss:///voice/ws?token=...

Problem

In the browser, the WebSocket connection fails with the generic Chrome error:

WebSocket connection to 'wss:///voice/ws?...' failed:

Voice works nowhere in staging because the socket never establishes.

What we verified

We tested the same endpoint three ways:

1. Plain request to /voice/ws

This returns:

• HTTP/2 404
• server: railway-edge
• x-railway-cdn-edge: fastly/...

Body says:

• Cannot GET /voice/ws

That part is expected for a WS-only route.

2. Request with WebSocket upgrade headers over the default path

This still returns:

• HTTP/2 404
• server: railway-edge
• x-railway-cdn-edge: fastly/...

Body says:

• Cannot GET /voice/ws?token=stub

This is the suspicious part. It looks like the upgrade is not reaching origin as a real WebSocket upgrade.

3. Same upgrade request, but forced to HTTP/1.1

This returns:

• HTTP/1.1 101 Switching Protocols

Then our app responds with invalid_token, which is expected for the stub token and proves the request reached the actual WebSocket server logic.

Conclusion

The endpoint itself appears healthy.

The failure seems to happen only on the default Railway edge path, where the request ends up as an HTTP/2 404 instead of upgrading, while the exact same endpoint works when forced to HTTP/1.1.

Question

Has anyone else hit this on Railway recently?

Specifically:

• browser wss:// fails
• default path returns HTTP/2 404
• forced HTTP/1.1 upgrade succeeds with 101 Switching Protocols

If so, did you get a working fix or workaround other than moving the service elsewhere?