The OpenClaw gateway is the HTTP server that handles every connection to your agent. The single most important setting is the bind address: on a server, set it to 127.0.0.1 (loopback) so only the local machine can reach it, and use SSH tunneling for remote access. The default 0.0.0.0 binding is what exposed 30,000+ OpenClaw instances to the public internet.
The gateway is how your agent talks to the world. If it's misconfigured, anyone on the internet can talk to your agent too. Here's what you need to know.
Thirty thousand OpenClaw instances were found exposed on the internet without authentication. Thirty thousand. Censys, Bitsight, and Hunt.io all independently confirmed the number. Every one of those instances had a misconfigured gateway.
The OpenClaw gateway is the single most important security setting in your entire setup, and it's the one most people never think about. If you get this wrong, anyone on the internet can send messages to your agent, read your conversations, and potentially access whatever your agent has access to (your files, your API keys, your connected platforms).
Here's what the gateway actually is, why the default configuration is dangerous on a server, and the one change that fixes it.
What the OpenClaw gateway actually is
Think of the OpenClaw gateway as the front door to your agent. It's the HTTP server that accepts incoming connections and routes them to the agent. When you open the OpenClaw web interface in your browser, you're connecting through the gateway. When Telegram delivers a message to your agent, it arrives through the gateway. When a cron job fires, the gateway processes it.
Every interaction with your agent flows through the gateway. It handles authentication (or doesn't, depending on your configuration), manages WebSocket connections for real-time chat, processes incoming messages from connected platforms, and serves the web-based TUI interface.
On your local machine, this is straightforward. The gateway runs on your computer. Only you can access it. The front door is inside your house.
On a VPS or remote server, the situation changes entirely. The gateway runs on a server connected to the public internet. If the front door is open and facing the street, anyone can walk in.
For the complete OpenClaw security checklist, our security guide covers the gateway alongside nine other security measures.
The 127.0.0.1 vs 0.0.0.0 problem (this is the dangerous part)
This is where most people get it wrong. Stay with me here because this single setting is responsible for the majority of exposed OpenClaw instances.
127.0.0.1 (loopback) means the gateway only accepts connections from the same machine it's running on. If someone on the internet tries to connect, they can't. The door only opens from inside the house. This is what you want on a server.
0.0.0.0 (all interfaces) means the gateway accepts connections from anywhere. Your machine, your local network, and the entire internet. The door is open to the street. This is the default for some OpenClaw configurations, and it's the default that GitHub Issue #5263 flagged (closed by a maintainer as "not planned" to change).
Here's the problem: if your gateway binds to 0.0.0.0 on a VPS without a firewall blocking the gateway port, your agent is publicly accessible. No password. No authentication. Anyone who finds your IP address and port can interact with your agent, read your conversation history, and potentially trigger actions through your connected platforms.
The CVE-2026-25253 vulnerability (CVSS 8.8, one-click remote code execution) was especially dangerous for instances with exposed gateways. An attacker could exploit the WebSocket vulnerability to execute arbitrary code on the host machine. The vulnerability was patched, but instances with publicly exposed gateways were the easiest targets.
If your OpenClaw gateway binds to 0.0.0.0 on a server, your agent is public. Change it to 127.0.0.1. This is the single most important security setting in your configuration.
The one change you must make before exposing your gateway
Set the gateway bind address to loopback in your OpenClaw config. In your openclaw.json (or equivalent config file), the gateway section should have its bind setting set to "loopback" or the bind address set to "127.0.0.1".
This single change means the gateway only listens for connections from the local machine. External traffic can't reach it directly. Your agent is invisible to the internet.
But wait, how do I access my agent remotely if it only listens locally?
SSH tunneling. You create an encrypted tunnel from your personal machine to the server. The tunnel forwards the gateway port from the remote server to your local machine. You open your browser, connect to localhost on the forwarded port, and the traffic travels through the encrypted SSH connection to the server.
This gives you remote access to the gateway without exposing it to the internet. Only someone with SSH credentials can create the tunnel. Everyone else sees nothing.
On BetterClaw, gateway binding is handled and locked down by default. This isn't something you configure or can accidentally misconfigure. The gateway is never publicly exposed. $29/month per agent, BYOK. The security configuration is part of the platform.
How to set up secure remote access
The SSH tunnel approach is the standard way to access a loopback-bound gateway remotely.
From your personal machine, open a terminal and create an SSH connection to your server with port forwarding. You specify which local port on your machine should map to which port on the remote server. The gateway's default port (varies by configuration, commonly 3000 or 4000) gets forwarded to a local port on your machine.
Once the tunnel is open, you access the OpenClaw web interface by opening your browser and going to localhost on the forwarded port. The traffic travels through the encrypted SSH tunnel to the server, reaches the loopback-bound gateway, and works exactly as if you were sitting at the server.
Why not just open the port publicly and add a password? Because OpenClaw's built-in authentication is minimal. The gateway wasn't designed as a public-facing web service. It was designed as a local interface. Adding a reverse proxy with authentication (nginx with HTTP basic auth, for example) is possible but adds complexity. SSH tunneling gives you encrypted, authenticated access with zero additional software.
For the complete VPS setup walkthrough including firewall configuration and SSH hardening, our self-hosting guide covers the full server security stack.
Common gateway errors and what they mean
Connection refused
You're trying to connect to the gateway and getting "connection refused."
This means nothing is listening on the port you're trying to reach. Either the gateway isn't running (start it), you're using the wrong port (check your config), or the gateway is bound to loopback and you're trying to connect from outside the machine without an SSH tunnel (set up the tunnel).
Gateway already in use (EADDRINUSE)
The port the gateway wants to use is already occupied by another process.
Something else is running on that port. Check what's using it and either stop that process or change the gateway port in your OpenClaw config. Common culprits: a previous OpenClaw instance that didn't shut down cleanly, another Node.js application, or a system service.
Timeout on remote connection
You can reach the server but the gateway connection times out.
This usually means a firewall is blocking the port. If you're using SSH tunneling (as you should be), the firewall should block the gateway port from external access. The tunnel bypasses the firewall through the SSH connection. If you're getting timeouts through an SSH tunnel, the gateway isn't running or is bound to a different port than the one you're forwarding.
For the broader OpenClaw troubleshooting guide covering all first-hour errors, our error guide covers the six most common problems new users hit.
How to know if your gateway is exposed right now
If you're running OpenClaw on a server and you're not sure whether your gateway is exposed, check immediately.
From a different machine (not the server), try to access your server's IP address on the gateway port through a web browser. If you see the OpenClaw web interface or get any response other than a timeout or connection refused, your gateway is publicly exposed.
If you get a connection timeout or connection refused, the gateway is either not exposed or a firewall is blocking external access. Both are acceptable states.
If your gateway is exposed: change the bind setting to loopback immediately. Restart the gateway. Verify the external access no longer works. Then rotate all API keys stored in your configuration, because if the gateway was exposed, someone may have already accessed your setup.
Check your OpenClaw logs for unfamiliar conversations or requests. If you see messages you didn't send, someone else was using your agent.
The managed vs self-hosted comparison covers how different deployment approaches handle gateway security, including which platforms prevent exposure by default.
The honest takeaway
The OpenClaw gateway is simple in concept (it's the HTTP server your agent uses to communicate) and dangerous in default configuration (it can expose your agent to the entire internet with one wrong setting).
Bind to loopback. Use SSH tunnels. Block the port in your firewall. These three actions take 10 minutes and prevent the exact exposure that affected 30,000+ instances.
The OpenClaw maintainer Shadow warned that "if you can't understand how to run a command line, this is far too dangerous of a project for you to use safely." The gateway is the specific thing he's talking about. It's the difference between a private assistant and a public service that anyone can abuse.
If gateway security, firewall configuration, and SSH tunnel management isn't something you want to handle, give Better Claw a try. $29/month per agent, BYOK with 28+ providers. Gateway security is locked down by default. AES-256 encrypted credentials. Docker-sandboxed execution. The infrastructure security is handled so you focus on what your agent does, not on whether someone else is using it.
Frequently Asked Questions
What is the OpenClaw gateway?
The OpenClaw gateway is the HTTP server component that handles all communication between your agent and the outside world. It processes incoming messages from connected platforms (Telegram, WhatsApp, Slack), serves the web-based chat interface, manages WebSocket connections, and routes requests to the agent. Every interaction with your OpenClaw agent flows through the gateway.
What's the difference between 127.0.0.1 and 0.0.0.0 in OpenClaw gateway settings?
127.0.0.1 (loopback) means the gateway only accepts connections from the local machine. 0.0.0.0 (all interfaces) means it accepts connections from anywhere, including the public internet. On a server, binding to 0.0.0.0 without a firewall makes your agent publicly accessible to anyone who finds your IP. Always bind to 127.0.0.1 on servers and use SSH tunnels for remote access.
How do I securely access my OpenClaw gateway remotely?
Use SSH tunneling. Create an SSH connection from your personal machine to the server with port forwarding. This forwards the gateway's local port through the encrypted SSH connection to your machine. You access the gateway through localhost on your personal machine, and the traffic travels securely through the tunnel. This gives you remote access without exposing the gateway to the internet.
How do I check if my OpenClaw gateway is exposed?
From a different machine (not the server), try to access your server's IP address and gateway port in a web browser. If you see the OpenClaw interface or get any response other than a timeout, your gateway is publicly accessible. Fix immediately: change the bind setting to loopback, restart the gateway, and rotate all API keys. 30,000+ OpenClaw instances were found exposed this way.
Is the default OpenClaw gateway configuration secure?
On a local machine (your laptop or desktop), the default is generally safe because the machine isn't directly exposed to the internet. On a server or VPS, the default bind to 0.0.0.0 is dangerous. GitHub Issue #5263 requested changing this default, but it was closed as "not planned." You must manually change the bind to loopback on any server deployment. Managed platforms like BetterClaw handle this automatically.
Related Reading
- OpenClaw Security Checklist — Nine more security measures alongside gateway binding
- OpenClaw Security Risks Explained — Why 30,000+ instances were exposed and what attackers do with them
- OpenClaw VPS Setup: The Real Cost of $8/Month Hosting — Full server security stack including firewall and SSH hardening
- OpenClaw Not Working: Every Fix in One Guide — Connection errors and other first-hour issues
- BetterClaw vs Self-Hosted OpenClaw — How managed deployment handles gateway security automatically
