openclaw node run blocking wss:// connections in 2026.2.22-2
✅Solved
Hey team — running into a security check regression on the node host in 2026.2.22-2 that didn't exist in 2026.2.21-2.
Setup:
• VPS running OpenClaw gateway (2026.2.21-2, bind: loopback, port 18789)
• Tailscale Funnel exposing it at wss://ip-172-31-8-156.tail2162ca.ts.net:8443
• Work laptop running OpenClaw 2026.2.22-2 in remote mode, local config set to wss://ip-172-31-8-156.tail2162ca.ts.net:8443
Error:
node host gateway connect failed: SECURITY ERROR: Cannot connect to "3.140.193.5" over plaintext ws://. Both credentials and chat data would be exposed to network interception. Use wss:// for remote URLs.
The problem: The error says to use wss:// — we ARE using wss://. The node host appears to be resolving the Tailscale hostname to its underlying public IP (3.140.193.5) and then blocking it regardless of the protocol prefix in the config. The check seems to fire on the resolved IP, not the configured URL.
This worked fine on 2026.2.21-2 with the SSH tunnel + ws://127.0.0.1:18789. Upgrading to 2026.2.22-2 introduced the check, but the wss:// path it recommends doesn't satisfy it.
Is there a config flag to allow wss:// connections to public IPs, or is this a bug in the IP resolution check?
Setup:
• VPS running OpenClaw gateway (2026.2.21-2, bind: loopback, port 18789)
• Tailscale Funnel exposing it at wss://ip-172-31-8-156.tail2162ca.ts.net:8443
• Work laptop running OpenClaw 2026.2.22-2 in remote mode, local config set to wss://ip-172-31-8-156.tail2162ca.ts.net:8443
Error:
node host gateway connect failed: SECURITY ERROR: Cannot connect to "3.140.193.5" over plaintext ws://. Both credentials and chat data would be exposed to network interception. Use wss:// for remote URLs.
The problem: The error says to use wss:// — we ARE using wss://. The node host appears to be resolving the Tailscale hostname to its underlying public IP (3.140.193.5) and then blocking it regardless of the protocol prefix in the config. The check seems to fire on the resolved IP, not the configured URL.
This worked fine on 2026.2.21-2 with the SSH tunnel + ws://127.0.0.1:18789. Upgrading to 2026.2.22-2 introduced the check, but the wss:// path it recommends doesn't satisfy it.
Is there a config flag to allow wss:// connections to public IPs, or is this a bug in the IP resolution check?
Solution
This has been fixed. The local node.json file had a public IP locked into it that was not part of the config.
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
134,426Members
Resources
Similar Threads
Was this page helpful?
