WebSockets keep a connection open for two-way communication. They require support from the application server, reverse proxy and hosting process model.
IN THIS ARTICLE
01 What you need before you begin
Confirm the plan supports persistent Node processes and WebSocket proxying. Identify the public endpoint, authentication method and any idle timeout.
02 Use WebSocket connections on eligible hosting
Implement the WebSocket endpoint through the maintained library selected by the application. Validate connection authentication and authorise the channels or resources a user may access.
Configure the proxy to support the required connection upgrade or protocol behavior. Use the platform’s documented settings rather than assuming ordinary HTTP forwarding is sufficient.
Use secure public connections through HTTPS/WSS and validate allowed origins where the application’s browser security design requires it.
Add heartbeat, reconnect and backoff behavior. Treat a disconnect as normal and decide how the client resynchronises missed state.
For multiple workers, use the library-supported shared adapter or message broker when events must reach clients attached to different processes.
03 Confirm the expected result
Test a real-time message in both directions, an idle connection and a deployment restart. Confirm an unauthorised user cannot subscribe to another customer’s channel.
04 Troubleshoot unexpected results
A connection that opens then closes at a fixed interval may meet a proxy idle timeout. Check heartbeat and hosting limits before repeatedly increasing application retry speed.
05 A common question
Can WebSockets run on every plan that supports Node.js?
No. Confirm persistent connection support and resource policy for the specific plan. A self-managed or differently configured service may be required for the intended workload.
06 Example: test a WebSocket connection through the full route
A WebSocket application can work on a developer's machine yet fail after deployment because the public route includes a web server, proxy or CDN. Test through the real HTTPS hostname, not only a direct local application port.
In browser developer tools, inspect the WebSocket request and its response. Record whether the handshake succeeds, whether the connection closes immediately and how long it remains open. Compare this with the application log at the same time. Do not post private message payloads or authentication tokens as diagnostic evidence.
Why does the page load but live updates stop?
The ordinary HTTP page and the persistent connection are different operations. Investigate routing, upgrade handling, timeouts and application restarts separately. If several application instances are involved, confirm the application's design for sharing events and connection state instead of assuming one instance can see every client's connection.
Tell us the application runtime, expected persistent connection, proxy/CDN route and observed failure before changing your plan. A hosting account that supports ordinary PHP pages does not necessarily support every long-running application architecture. We will help you identify a suitable service or the specific limitation rather than opening arbitrary public ports.