3 hours ago
My project "renewed-growth" (service: renewed-growth, project ID: d3ab71ea-1fcf-4a2b-a1db-33a23d90e92e) is experiencing sudden, simultaneous WebSocket disconnects for ALL connected users, with close code 1006 (abnormal closure, wasClean: false).
This happens multiple times per session, dropping all active game rooms/players at once. My Node.js server itself does NOT crash or restart during these events - confirmed via logs (no UNCAUGHT exceptions, no restart events, and app state like chat history/live media persists across the disconnects).
This matches other reports I've seen about the edge proxy dropping long-lived WebSocket connections. Could you check the networking path for my service? This happened multiple times tonight (around 19:49, 19:51, 19:54-19:55 UTC+4 / please let me know what timezone you need this in).
Domain: kiss.az / mygame.az
1 Replies
3 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 3 hours ago
an hour ago
Additional info to help investigate:
Region: ams
Affected projects (both experiencing the SAME simultaneous 1006 disconnects):
- renewed-growth (mygame.az / kiss.az) - Project ID: d3ab71ea-1fcf-4a2b-a1db-33a23d90e92e, Service ID: b4afa549-fbbd-4170-a29e-1a3230fb5b91
- calm-empathy (ureyimsen.com) - Project ID: 1565ccb0-d461-4901-a23f-93ca54fd46c1, Service ID: 9b06a761-16a1-4cb7-b40b-c77f3fd68211
Confirmed server-side facts (via logs on both projects):
- No process restart at time of incident
- No uncaughtException / crash
- No deployment triggered at incident time
- In-memory game state (chat history, room state) survives the disconnects
- HTTP and new WebSocket connections work fine immediately after
Client-side observation:
- Browser reports: code=1006, wasClean=false, reason=''
- Multiple UNRELATED users (different accounts, different rooms) disconnect within the same few seconds
- This happens on the custom domain (mygame.az/kiss.az)
Incident times observed tonight (please let me know what timezone reference you need - these are UTC+4):
- ~19:49, 19:51, 19:54-19:55, 20:19-20:20
The fact that this occurs across TWO separate, unrelated Railway projects in the same region at overlapping times strongly suggests an edge-proxy/routing issue in ams rather than an application-level bug. Could you check for edge proxy connection resets, WebSocket upgrade/routing logs, or any infrastructure events in AMS around these timestamps?
Happy to run an A/B test comparing the custom domain vs the Railway-generated *.up.railway.app domain simultaneously if that would help isolate whether this is domain-routing specific.