WS upgrade → 502 at edge (railway-hikari fallback), plain HTTP fine — project-wide

Question

**WebSocket upgrade returns 502 from edge (railway-hikari fallback), regular HTTP works fine — project-w

ide, not service-specific**

Project: `practical-perception`, service `performia-learn` (Node/Express + `ws`, WS path `/ws`, attached

via `server.on('upgrade', ...)`).

Every WS handshake to `/ws` fails with `502` right at the edge, in ~9ms — too fast to be a real round-tr

ip to the app. Response headers/body confirm it's Railway's own fallback, not our app:

```
server: railway-hikari
x-railway-fallback: true
x-railway-edge: ams1
```

body: `{"status":"error","code":502,...}`

Regular HTTP (GET/POST/PATCH) on the exact same domain/service works perfectly (200/304/401 as expected)

.

What I've ruled out so far:

- **App itself is fine** — confirmed via `railway ssh` straight into the container: the same WS handshak

e against `127.0.0.1:$PORT/ws` (bypassing edge) completes correctly (101 Switching Protocols, valid sess

ion cookie).

- **Not a plan issue** — was on Trial, upgraded to Hobby, fresh redeploy after. Same 502.
- **Not a region issue** — tested EU West (Amsterdam) and US East (Virginia). Same 502 in both.
- **Not a domain issue** — same 502 on both the generated `*.up.railway.app` domain and a fully verified

custom domain.

- **Not CDN Caching / Under Attack Mode** — both disabled in Edge settings.
- **Not this specific service** — spun up a brand new, separate service in the same project from the sam

e repo/branch, with its own fresh domain. Same 502 on WS, everything else identical.

So it looks account/project-wide rather than tied to one service's config. Support tickets aren't availa

ble on my plan, so I'm hoping someone here has seen this exact `railway-hikari` fallback response on WS

upgrades before, or knows what could cause it. Happy to share more diagnostics/logs if useful.