Help with Node

[topaz spear]

Hey team! I'm trying to connect a Windows node host to my OpenClaw gateway running on myclaw.ai (hosted/cloud setup).

I've installed OpenClaw on Windows and run:

openclaw node run --host myclaw.ai --port 443 --display-name "Will's PC" --tls

I get this error:

node host gateway connect failed: Unexpected server response: 200
node host gateway closed (1006)

My openclaw qr --json shows:

{
  "gatewayUrl": "wss://myclaw.ai",
  "urlSource": "plugins.entries.device-pair.config.publicUrl"
}

So the gateway is advertising wss://myclaw.ai correctly, but the WebSocket connection isn't being upgraded — getting a 200 HTTP response instead.

Does the myclaw.ai reverse proxy support WebSocket node host connections? Is there a specific path or port I should be using? Any config needed on the gateway side?

Thanks!

[hasty scaffold]

That Unexpected server response: 200 usually means the node host hit a normal HTTPS page, not the Gateway WebSocket.

A few important bits:

• openclaw node run connects to ws:// or wss:// at host:port only. No extra path. If your proxy expects something like /ws, that will not work for node host right now.
• openclaw qr --json without --remote is not validating the node-host route. It reads plugins.entries.device-pair.config.publicUrl, which is for pairing/bootstrap. It can be correct for QR and still be wrong for node-host WS.
• So yes, this is very likely a reverse proxy issue, not a Windows issue.

What to check:

1. Please paste openclaw --version from both the gateway host and the Windows node.
2. On the gateway, check whether gateway.remote.url is set, or run:

   openclaw qr --json --remote
   

   That is the better signal for remote WS routing than plain qr --json.
3. Make sure your proxy on myclaw.ai:443:

• supports WebSocket upgrade
  • forwards Upgrade: websocket and Connection: upgrade
  • sends WS traffic to the Gateway, not your dashboard/static site

4. If 443 is just serving the website, try the actual Gateway port instead, usually 18789, or expose that via a WS-capable proxy / Tailscale / SSH tunnel.

So the short answer is:

• Specific path? No. It expects root wss://host:port.
• Specific port? Usually 18789 directly, unless your proxy cleanly maps 443 to the Gateway WS.
• Gateway-side config? plugins.entries.device-pair.config.publicUrl alone is not enough for node hosts. gateway.remote.url and correct proxy WS pass-through matter more here.

Docs:

• https://docs.openclaw.ai/cli/node
• https://docs.openclaw.ai/cli/qr
• https://docs.openclaw.ai/gateway/trusted-proxy-auth

If you paste the two versions plus openclaw qr --json --remote, I can narrow it down pretty fast.

[topaz spear]

Gateway version: OpenClaw 2026.4.9

Windows node version: (run openclaw --version in PowerShell and add it)

openclaw qr --json --remote output:

gateway.remote.url was not set previously — now set to wss://myclaw.ai. Still getting the same 200 error on openclaw node run --host myclaw.ai --port 443 --tls. Does myclaw.ai:443 cleanly proxy WebSocket connections to the Gateway, or do we need a different port/approach?

[hasty scaffold]

Yep, this points to ingress/proxy, not discovery.

gateway.remote.url = wss://myclaw.ai only tells clients what URL to try. It does not make myclaw.ai:443 start proxying WebSockets.

So if openclaw node run --host myclaw.ai --port 443 --tls still gets HTTP 200, then as currently configured myclaw.ai:443 is not cleanly passing the Gateway WS through.

A few concrete takeaways:

• There is no special node-host path to use.
• node run expects wss://host:port at the root, no /ws flag/path.
• If your proxy is serving the website/dashboard on /, the node host will hit that and get 200, exactly what you're seeing.

So the supported fixes are basically:

1. Expose the actual Gateway WS directly, usually on 18789, then connect the node host there.
2. Put a WS-capable reverse proxy in front of the Gateway on 443 that forwards WebSocket upgrades to the Gateway socket.
3. Use Tailscale or an SSH tunnel instead of the public proxy.

Also, setting gateway.remote.url was still the right cleanup, but it only fixes the advertised URL, not the transport.

If you control the proxy, make sure it:

• forwards Upgrade: websocket
• forwards Connection: upgrade
• sends traffic to the Gateway WS upstream, not the normal HTTP site

I’d treat this as: different port/approach needed unless the proxy config is changed.

Still worth pasting the Windows openclaw --version when you have it, but the 200 is already the big clue.

Useful docs:

• https://docs.openclaw.ai/cli/node
• https://docs.openclaw.ai/nodes
• https://docs.openclaw.ai/gateway/remote
• https://docs.openclaw.ai/gateway/trusted-proxy-auth

If you want, I can also sketch the exact nginx/Caddy shape the proxy needs.

[topaz spear]

How do I connect a Windows node to a gateway hosted on myclaw.ai? The WebSocket connection gets a 200 error

[hasty scaffold]

Short version, a Windows node connects fine, but it needs a real Gateway WebSocket endpoint.

Your 200 means myclaw.ai:443 is answering normal HTTPS, not upgrading to the Gateway WS.

So the setup is:

1. Expose the Gateway WS

   • either directly on 18789
   • or behind a reverse proxy on 443 that does proper WebSocket pass-through
   • or via Tailscale / SSH tunnel

2. Set auth on the Windows box

   $env:OPENCLAW_GATEWAY_TOKEN="your-gateway-token"
   

   (or use OPENCLAW_GATEWAY_PASSWORD)

3. Run the node
   • direct port:

     openclaw node run --host myclaw.ai --port 18789 --display-name "Will's PC"
     

   • proxied TLS endpoint:

     openclaw node run --host myclaw.ai --port 443 --display-name "Will's PC" --tls
     

But the second form only works if myclaw.ai:443 is actually proxying the Gateway WebSocket.

Important gotchas:

• gateway.remote.url only advertises the URL, it does not configure the proxy.
• openclaw qr --json / --remote does not prove node-host WS is working.
• There is no special path for node host here. It expects wss://host:port at root. If your proxy wants /ws, that will not work with node run.

So for your case, the fix is one of:

• expose 18789 and connect there
• fix the reverse proxy to pass WS upgrades on 443
• use Tailscale or SSH tunnel

Docs:

• https://docs.openclaw.ai/cli/node
• https://docs.openclaw.ai/nodes
• https://docs.openclaw.ai/gateway/remote

If you want, I can give you a minimal nginx or Caddy config for the proxy side.

[topaz spear]

"Thanks! I'm running on your hosted cloud infrastructure (myclaw.ai), so I don't control the reverse proxy or the firewall to open port 18789. The container also doesn't have an SSH server or sudo access for me to install Tailscale.

Can your infrastructure team either:

Open port 18789 on the myclaw.ai server for direct connections?
Configure the myclaw.ai reverse proxy on port 443 to pass WebSocket upgrades through to the Gateway?
Right now I'm stuck because I'm in the hosted container and can't change the networking."

[hasty scaffold]

Yep, that sounds like a hard infra block now.

From inside that hosted container, if you cannot control the proxy/firewall and cannot use SSH/Tailscale, then there is no client-side fix left for the Windows node host. One of these has to happen on the host side:

1. Expose the Gateway WS directly on 18789, or
2. Make myclaw.ai:443 do real WebSocket pass-through to the Gateway, or
3. expose some other dedicated public wss:// endpoint for the Gateway

So your request is basically correct.

I’d phrase it as:

The hosted myclaw.ai endpoint currently returns HTTP 200 to the node-host WebSocket handshake, so remote node hosts cannot connect.
Please either expose the Gateway WebSocket directly (for example on 18789) or configure the 443 reverse proxy to pass WebSocket upgrades through to the Gateway.

Since this needs maintainer/infra attention, please file it here with the repro details: