Configuring WebSocket connections in Nginx Proxy Manager

Other Questions NPM
1

Setting up secure WebSocket routing for remote desktop service

I’m working on deploying a self-hosted remote desktop solution using Docker containers and I’m stuck on the WebSocket configuration part. My goal is to only expose ports 80 and 443 to the internet while routing all traffic through Nginx Proxy Manager.

The main application runs on port 22001 and I need to create WebSocket endpoints for /socket/main and /socket/bridge that forward to ports 22005 and 22006 respectively.

Current setup:

  • Main service proxy host pointing to http://localhost:22001
  • SSL certificate configured and working
  • WebSocket support enabled in basic settings

Problem: When I add custom locations for the WebSocket paths, the service shows as offline.

My custom location config for /socket/main:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 180s;

Should I be using a different approach in NPM? The official docs only show raw nginx config examples which don’t translate directly to the NPM interface.

Any guidance on properly configuring WebSocket proxying through NPM would be helpful. I suspect the issue is with how I’m setting up the custom locations but I can’t figure out what’s wrong.

2

I encountered similar issues when configuring WebSocket connections in Nginx Proxy Manager (NPM). In your custom location blocks, it’s imperative to include the proxy_pass directives for each path, as NPM requires specific instructions for routing. Ensure you add proxy_pass http://localhost:22005; for your /socket/main and proxy_pass http://localhost:22006; for /socket/bridge. Double-check that your main proxy host is effectively targeting the upstream and verify that your Docker containers are responsive on those ports. This setup should resolve your problems with NPM recognizing the WebSocket routes.

3

make sure your proxy_pass is targeting the right ports in ur custom locations. npm can be picky if the full upstream URL isn’t set. also, double check that websocket support is turned on in the main host settings, not just for individual locations.

4

Add proxy_buffering off; to your websocket config - npm’s buffering can break the connection. Also check if your containers are using 127.0.0.1 or 0.0.0.0 since localhost doesn’t always resolve right in docker.

5

Skip NPM’s weird WebSocket issues - just automate this with Latenode. You’ve got multiple proxy endpoints, ports to manage, and config nightmares that scream for automation.

I’ve done similar remote desktop setups where Latenode runs all the routing logic. Create workflows that auto-configure proxy rules based on health checks. When containers start on 22005 and 22006, Latenode spots them and updates routing without touching NPM.

Best part? Automated failover. WebSocket endpoint dies? Latenode reroutes traffic instantly or spins up backups. No more wondering why NPM thinks services are down.

It’ll handle SSL renewals and port monitoring too. Forget debugging custom location blocks - let Latenode manage the proxy chain and handle WebSocket upgrades automatically.

For complex setups like yours with multiple WebSocket paths, automation crushes manual config. Check it out: https://latenode.com

6

Your issue is probably NPM’s custom locations overriding the main proxy settings. I’ve hit this exact problem before - custom locations mess with the base proxy host config, and the order really matters. Instead of custom locations, create separate proxy hosts for each WebSocket endpoint. Set one up for yourdomain.com/socket/main pointing to http://localhost:22005 and another for yourdomain.com/socket/bridge going to http://localhost:22006. This skips the custom location headaches and gives you better control over each WebSocket connection. Also double-check that your Docker containers are actually binding to the host network - sometimes it’s not NPM at all, just container networking blocking access to those ports.