2026 OpenClaw Public Access: Gateway Reverse Proxy, HTTPS, and Ports — Minimal Nginx/Caddy Checklist on a VNC Remote Mac

If you need a stable HTTPS URL for the OpenClaw Gateway console, webhooks, or integrations, exposing the app port directly to the internet is rarely the end state. This guide is for teams that already run OpenClaw on bare metal or a remote Mac and plan to go public: a direct vs reverse-proxy decision table, minimal Nginx and Caddy snippets with WebSocket-friendly headers, a TLS and firewall checklist, and a VNC-friendly verification path from loopback to another network. Cross-links point to Docker, common errors, and silent “no reply” troubleshooting on this site.

1. Pain points of exposing Gateway without a proxy

• Plain HTTP and trust: credentials and callbacks over the open internet without TLS are fragile; many providers require HTTPS.
• WebSockets under naive forwarding: missing Upgrade/Connection or aggressive timeouts look like “random disconnects” in the UI.
• Larger attack surface: publishing the app port directly increases scan noise; a proxy is where you attach allow lists, rate limits, and consistent access logs.
• Remote Mac blind spots: “SSH works” does not prove macOS firewall and cloud security groups align with what you see in VNC.
• Docker vs host listeners: 127.0.0.1 versus 0.0.0.0 changes where the proxy must run—see the official Docker guide on this site.

2. Decision table: direct vs TLS + reverse proxy

3. When you should add Nginx or Caddy

• You need a stable domain and HTTPS for bookmarks, OAuth redirects, or webhooks.
• Real-time UI behavior degrades on long paths without proper upgrade handling.
• You host other sites on the same remote Mac and want one certificate story.
• Policy allows only 443/80 from the internet while the app stays on loopback.
• openclaw doctor suggests binding sensitive services to localhost and fronting them with a proxy (follow your version’s output).

4. Minimal Nginx: 18789, Host, WebSocket

Teaching snippet—replace hostnames, cert paths, and upstream port. Harden for production (ciphers, OCSP stapling, logging redaction, rate limits).

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl http2;
    server_name claw.example.com;

    ssl_certificate     /etc/letsencrypt/live/claw.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/claw.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Use HTTP/1.1 to the upstream, forward Upgrade/Connection, and keep forward headers honest so the app knows the client scheme.

5. Minimal Caddy: automatic HTTPS

claw.example.com {
    reverse_proxy 127.0.0.1:18789
}

Caddy obtains and renews certificates when ports 80/443 are reachable for ACME. Add matchers, extra headers, or IP filters as your policy requires.

6. Certificates, DNS, security groups

6b. Optional IP allow lists and rate limits

For small teams, restrict admin surfaces by source IP or VPN egress. On Nginx use allow/deny or a WAF; on Caddy use matchers such as remote_ip per your version docs. Add limit_req (or equivalent) on hot endpoints so brute force and accidental loops do not take down the Gateway.

For webhooks, prefer signature verification from the provider; IP ranges can change. Document allow lists and cert expiry on a calendar.

7. Seven-step verification on a VNC remote Mac

1. In a VNC terminal, run openclaw doctor and confirm listen addresses match config.
2. curl -v http://127.0.0.1:18789/ (or your upstream) and verify status codes.
3. Validate nginx/caddy syntax and reload cleanly.
4. Open https://your-domain in a browser on the Mac; confirm WebSocket 101 in devtools.
5. Retest from mobile data or another network to avoid LAN-only false positives.
6. Correlate proxy access logs with OpenClaw logs when debugging silent failures (see the no-reply article).
7. After firewall changes, wait for propagation and re-run the external test.

8. Quotable parameters and related guides

For install and runtime errors, read common errors and ten fixes. For silent channels, follow no-reply troubleshooting. For containers, start from official Docker Compose on a remote Mac.

Closing: why VNC on a remote Mac still helps

Public Gateway setup mixes TLS, long-lived connections, and OS-level firewalls—hard to debug from SSH alone when you need a browser and system prompts in one place. Renting a VNC-capable remote Mac (such as from VNCMac) lets you run doctor, reload proxies, and validate WebSockets visually without buying hardware you only need for a short project. Keep the edge locked down: TLS on 443, loopback upstream, and this site’s Docker and troubleshooting posts as your runbook.