Which shutdown strategy should a PM2 cluster-mode app use for WebSocket clients during zero-downtime reloads?

I am planning to migrate a small Node.js HTTP service from PM2 fork mode to cluster mode so deploys can use pm2 reload instead of stop/start, avoiding the brief listener gap a single forked process creates. The app will run as at least two cluster instances on Linux, with PM2 and Node versions pinned but not yet finalized.

The plain HTTP path seems well understood: workers are recycled one at a time, and the app closes its HTTP server on the termination signal so in-flight requests finish before exit. What I have not resolved is the handful of long-lived WebSocket connections the service also holds. These clients stay connected for minutes to hours, so a worker that waits for them to drain naturally may never exit within any reasonable reload window, while closing connections immediately forces visible client reconnects on every deploy.

State is otherwise stateless (no in-memory sessions or local caches), so the sockets are the only blocker to treating workers as disposable.

Given PM2 cluster mode as the documented mechanism:

• Should the app drain WebSockets in-process on the shutdown signal with a forced timeout, or is that pattern unreliable under PM2's reload timing?
• Is moving the sockets behind a separate broker or dedicated gateway process the more standard design, or is accepting controlled disconnects with client auto-reconnect considered acceptable practice?
• What staging measurement (failed requests, disconnect counts, reload duration) would confirm the chosen approach actually achieves zero-downtime deploys?