Description:
The current architecture of openshell-controller assumes that the client (browser) can directly reach two separate ports:
Port 3000: The Next.js web application.
Port 3001: The WebSocket sidecar proxy.
The Problem:
In a standard production environment, applications are typically deployed behind a Reverse Proxy or Edge Gateway (e.g., Nginx, Cloudflare, Traefik, AWS ALB) where all traffic is unified under a single hostname on port 443 (HTTPS).
When openshell-controller generates a WebSocket URL, it hardcodes the injection of :3001. Behind a reverse proxy, this results in the browser attempting to connect to wss://your-domain.com:3001.
- Firewall Issues: Most corporate/production firewalls block non-standard ports like 3001.
- Certificate Issues: The reverse proxy handles SSL at port 443. Connecting to 3001 would require the backend service itself to handle SSL, or the proxy to listen on 3001 as well, which is complex to manage.
- Path Routing: Standard reverse proxies prefer routing by path (e.g., /api/openshell/ws) on the same port, rather than switching ports.
Why the current "External Port" logic is insufficient:
Even if we override the port to be empty (forcing the browser to use port 443), the request still fails because:
- The request arrives at the Reverse Proxy on port 443.
- The Proxy forwards it to the Next.js app on port 3000.
- The Next.js app (3000) does not handle the WebSocket Upgrade. Only the sidecar on port 3001 knows how to handle it.
Recommended Solution:
The application should ideally use a unified listener or provide a mechanism to route WebSocket upgrades through the main Next.js server (e.g., using a custom server.js with http-proxy or socket.io integration).
At a minimum, the openshell-controller should:
Allow the WebSocket Proxy to be served on a sub-path of the main application (e.g., 3000/api/ws-proxy).
Stop hardcoding :3001 in the bootstrap script and launchUrl generation, instead allowing a fully qualified BASE_WS_URL environment variable.
Quick Solution:
quick interim solution would be to have an expandable info message div on the openclaw page that gives the internal port number and token. Then at least I could manually create a public URL on the reverse proxy pointing to the port
Description:
The current architecture of openshell-controller assumes that the client (browser) can directly reach two separate ports:
Port 3000: The Next.js web application.
Port 3001: The WebSocket sidecar proxy.
The Problem:
In a standard production environment, applications are typically deployed behind a Reverse Proxy or Edge Gateway (e.g., Nginx, Cloudflare, Traefik, AWS ALB) where all traffic is unified under a single hostname on port 443 (HTTPS).
When openshell-controller generates a WebSocket URL, it hardcodes the injection of :3001. Behind a reverse proxy, this results in the browser attempting to connect to wss://your-domain.com:3001.
Why the current "External Port" logic is insufficient:
Even if we override the port to be empty (forcing the browser to use port 443), the request still fails because:
Recommended Solution:
The application should ideally use a unified listener or provide a mechanism to route WebSocket upgrades through the main Next.js server (e.g., using a custom server.js with http-proxy or socket.io integration).
At a minimum, the openshell-controller should:
Allow the WebSocket Proxy to be served on a sub-path of the main application (e.g., 3000/api/ws-proxy).
Stop hardcoding :3001 in the bootstrap script and launchUrl generation, instead allowing a fully qualified BASE_WS_URL environment variable.
Quick Solution:
quick interim solution would be to have an expandable info message div on the openclaw page that gives the internal port number and token. Then at least I could manually create a public URL on the reverse proxy pointing to the port