Summary

During a Mac mini OrbStack + Windows/WSL2 era, it was difficult to distinguish OpenClaw gateway bind behavior from VM/NAT/Tailscale reachability constraints. We used reverse SSH/Tailscale workarounds and at times misdiagnosed environment networking as an OpenClaw LAN binding problem.

This is probably not a core OpenClaw bug. It is a docs/doctor UX request.

Environment

• Mac mini M4 running OpenClaw inside OrbStack/Debian VM
• Windows PC / WSL2 local inference host
• Tailscale and reverse SSH tunnels used at different points
• Historical WSL2 subnet addresses like 172.26.x.x

Expected behavior

Docs/doctor should help users answer:

• Is gateway bound to 127.0.0.1 or 0.0.0.0?
• Is the address reachable from LAN, host, VM, WSL2, or only loopback?
• Should this deployment use Tailscale Serve/node pairing instead?
• When is reverse SSH appropriate?
• What security warnings apply before binding to LAN?

Actual behavior

Troubleshooting required ad hoc checks/tunnels and memory notes. It was easy to confuse VM/WSL NAT behavior with OpenClaw gateway config.

Suggested improvement

Add openclaw doctor gateway-reachability or a docs section covering:

1. local curl health
2. bind address detection
3. VM NAT / OrbStack caveats
4. WSL2 172.x LAN-unreachability caveat
5. Tailscale Serve/node route recommendation
6. reverse tunnel fallback
7. security warning for broad bind/reverse proxy headers