Introduction

OpenClaw recently updated its security protocol, mandating a more secure access method and directly disabling traditional direct HTTP LAN connections. This has little impact on devices with a local browser, but for NAS systems like Synology and FnOS that run server-side and are mainly managed through a web console, it is practically a “dimensional strike”: since you cannot open a browser from inside the NAS to visit http://localhost, and external LAN devices are blocked by the security protocol, the control end is left disconnected.

To solve this problem, I’ve put together two practical approaches: one uses an SSH tunnel to quickly “trick” the protocol, and the other builds a proper HTTPS access environment with a self-hosted DNS + Caddy.

---

Reference video: Emergency Guide to OpenClaw “Going Offline” After an Update: Two “Workaround” Solutions for LAN Access

SSH tool: windterm

Solution 1: SSH Tunnel Forwarding (Fast, Temporary, Lightweight)

How it works: Using SSH’s local port forwarding, map the OpenClaw port on the NAS to the loopback address 127.0.0.1 on the computer you are currently using. Since OpenClaw usually allows loopback access, this method perfectly bypasses the LAN restriction.

Steps

1. Open a terminal: Open a terminal on the computer (PC or Mac) you use to access the NAS.

2. Run the command:

   ssh -L 18789:127.0.0.1:18789 user@your-nas-ip

   Note: Assume the OpenClaw port is 18789 and user is the NAS username.

3. Access: Keep the terminal window open and enter this in your browser: http://127.0.0.1:8080

Pros and Cons

• Pros: No certificate configuration, no modifying NAS system files — ready to use immediately.
• Cons: You must start the SSH process before every access; suitable for temporary debugging or infrequent configuration.

---

Solution 2: Self-Hosted DNS Forwarding + Caddy Reverse Proxy (Long-Term, Stable, Elegant)

How it works: Use Caddy to automatically obtain or self-sign a certificate to enable HTTPS, and combine it with DNS forwarding to point a custom domain at the NAS internally. OpenClaw will then recognize it as a secure, encrypted HTTPS connection and allow access.

Architecture

Steps

1. Configure the Caddy Reverse Proxy

Install Caddy in Docker or locally on the NAS, and write a Caddyfile:

openclaw.local {
    tls internal  # Use Caddy's self-signed certificate
    reverse_proxy openclaw:18789
}

2. Self-Hosted DNS Forwarding

To let devices on the LAN resolve openclaw.local, you can:

• AdGuard Home / Pi-hole: Add a record under “DNS rewrites” pointing openclaw.local to the NAS’s LAN IP.
• Router settings: If your router supports it, add a mapping under static DNS.

3. Trust the Root Certificate (Optional but Recommended)

Because it is a self-signed certificate, the browser will show a security warning. You can export the root certificate from Caddy and install it on your usual computer to get the “green padlock” when accessing.

Pros and Cons

• Pros: Configure once, and all household devices can access directly via the domain; complies with modern security protocol standards.
• Cons: Requires some networking knowledge (deploying Caddy and a DNS service).

---

Summary

If you only occasionally go into the backend to change a parameter, Solution 1 (SSH tunnel) is the most efficient. If you want to manage OpenClaw anytime, anywhere, just by typing an address in the browser as before, then Solution 2 (DNS + Caddy) is the ultimate solution.

Although the new protocol adds hassle, it also pushes us to make our home lab (HomeLab) more secure. I hope these two approaches help those of you tinkering with a NAS!