The page opens. The dashboard renders. And then nothing ever updates again — the classic fingerprint of an app that speaks Websockets behind a proxy that is not passing them.
Most web pages work in requests: ask, answer, done. A whole class of modern apps instead opens a Websocket — one long-lived connection down which the server pushes updates the moment they happen. If your proxy treats that connection like a normal request, the app looks half-alive: it loads, then silently stops. NPM has exactly one switch for this, it is off by default, and knowing when to flip it separates a two-minute fix from a weekend of blaming the app.
When a browser opens a normal page, it makes a request, gets a reply, and the connection closes. A Websocket starts the same way but then upgrades the connection into an open channel: both sides can send messages at any time, for as long as the page is open. Live dashboards, browser terminals, chat panes, collaborative editors and many home-automation screens are built on it. The upgrade is requested with special headers — and a proxy must be told to pass those headers and hold the connection open, or the upgrade silently fails and the app falls back to a frozen first paint.
That is the complete repair. Under the panel, NPM adds the upgrade handling to that host's generated nginx config — the Upgrade and Connection headers are forwarded and the connection is treated as a live stream instead of a one-shot request. Nothing else about the host changes.
Home and office favourites that commonly need it: Home Assistant (its whole interface is live), Portainer container consoles and logs, any app with a browser-based terminal, code-server style editors, chat and notification-heavy dashboards, and monitoring screens that update without refreshing. Plain document and media sites — blogs, photo galleries, file downloads, most admin panels — do not use Websockets and gain nothing from the toggle. Test before you toggle: if the app works fully through the proxy, this switch is not your problem.
Use the signature in the panel above. The cleanest test takes one minute: open the app through its direct internal address (192.168.x.x and port). If everything updates live there but freezes through the domain name, the app and your network are fine and the difference is precisely the proxy — flip the toggle and retest. If it misbehaves in both places, stop — the fault is inside the app itself, and no proxy setting will cure it. Diagnosis by contrast, not by hope.
Honestly assessed: turning Websockets Support on for a host that does not need it is harmless in practice — the upgrade headers simply never get used. Many experienced users enable it on every new host as a habit. The disciplined approach in this series is to enable it when an app needs it, because a setup you can explain is a setup you can debug at midnight. But if you inherited a fleet of hosts with it on everywhere, nothing is broken — leave them be and save your worry for ports 81 and backups.
App behaviour through a proxy versus direct is much easier to judge when you have seen it — the video's live demos show exactly what 'working' looks like.
▶️ Watch Full VideoNo. It changes how one special kind of connection is handled; ordinary pages neither gain nor lose anything. Speed was never its job.
Hard-refresh to clear cached code, then check the app on its direct internal address. If it freezes there too, the problem lives in the app or its own backend — look at its logs, not the proxy.
Nothing unique to NPM. The connection is still authenticated by the app itself and still travels inside your HTTPS. You are enabling a transport the app was designed to use, not opening a new door.