Start at the route people actually use
A healthy container does not prove a real-time game is reachable. The useful starting point was the production hostname, its certificate, the generated proxy configuration, and the path used by Socket.IO.
- Confirm DNS and TLS at the public hostname
- Inspect the active proxy entries instead of relying on a remembered configuration
- Verify both the document route and the real-time transport path
- Keep application containers intact while the routing problem is isolated
Use stable upstream identities
The repaired proxy routes the static game and Socket.IO traffic to stable Docker service names. A URL containing another public path is not a reliable container upstream, and a generic static route is not enough for a real-time connection.
Health checks need a functional companion
A dedicated health endpoint made infrastructure checks deterministic, but the final verification used two browser pages. One created a room, the second joined, the host started play, the host disconnected, and the remaining client recovered into the active room.
- Room creation
- Second-player join
- Synchronized game start
- Host disconnect
- Reconnect and host reassignment
The transferable lesson
For interactive learning games and simulations, verify the complete public flow. Static HTML, API health, and WebSocket behavior are separate surfaces, and a deployment is only healthy when the learner-facing sequence works across them.