What will each of the five layer faults look like when OpenClaw Gateway is exposed on the public network in 2026?
The first layer isCloud vendor security groups and boundary ACLs: You see that the monitoring is normal inside the machine, but you cannot enter from the public network entrance. Typically, the inbound rules only open 22 and 80, and 18789 or reverse external ports are not written into the allowed list. The second layer isHost firewall: Ubuntu's ufw, CentOS's firewalld, and the default drop policy of some images will still block the packet behind the network card after the security group releases it. The third layer isReverse proxy and WebSocket: Nginx or Caddy if missingUpgradeandConnectionFor transparent transmission, the browser side will show a handshake failure or infinite reconnection, but the Gateway process itself is still healthy.
The fourth layer isGateway binding and authentication: When you change the monitoring from loopback to LAN or custom address, the official guardrail will require token or equivalent authentication; if it is missing, it will "refuse to bind" or "can bind but the control plane cannot complete RPC detection". The fifth floor isChannels and Strategies: The rate limit, pairing status, group policy and DM policy on any side of Telegram, Discord or Webhook will cause the phenomenon "Gateway is online but the business side is not aware" to appear in the logs.
After separating the five layers, you will not have to reinstall it for every error; the table in the next section is used to determine whether you are solving the network entrance problem, the control plane configuration problem, or the channel product problem.
Security group:Use the smallest probe from the public IP to verify that the port is reachable, and then fall back to the intranet for comparison.
Host firewall:Cross-check with the security group rules to avoid "both layers think the other will let it go."
Countergeneration:Confirm that the TLS termination point is consistent with the upstream protocol and that the WebSocket header is forwarded unchanged.
Binding and authentication:Checkgateway.mode,gateway.bindandgateway.auththe same set of assumptions.
aisle:Bundlechannels status --probeAligned with provider console timestamp.
If you have already read the article "OpenClaw from Installation to Gateway Connection" on the site, you can think of this article as a "Special Chapter on Public Network Entrance and Reverse Generation": that article talks about installation and daemon process acceptance, and this article talks about external network paths and WebSocket details. After superimposing the two articles and then reading "All-Weather Stable Operation and Cloud Node Solution", you can align the motivation, command line and network layer at once.
How to compare authentication and exposure when monitoring and binding loopback, LAN and tailnet
The loopback binding is minimally exposed and is suitable for using the control plane only on the same machine; once you want to open the Dashboard on another laptop, you will be forced to expand the monitoring to a non-loopback address. At this time, authentication is not an option but a guardrail. LAN binding needs to make it clear which network cards and network segments are trustworthy; in tailnet or zero-trust tunnel scenarios, "who counts as the internal network" must be written as a team consensus, otherwise it will repeatedly jump to the wrong layer during debugging.
| Dimensions | Loopback binding only | Non-loop binding + reverse proxy |
|---|---|---|
| exposed surface | Minimum, external network is not reachable by default | Requires security group, firewall, TLS and token combination management |
| Dashboard experience | Requires SSH tunnel or peer access | Available domain names and certificates, suitable for teams to share control planes |
| Troubleshooting order | Give priority to Gateway and doctor | Let’s look at ports and reverse proxy first, then look at Gateway and doctor |
| Common risks | Mistaking loopback-only address for public network available address | Anti-leak upgrade or non-loopback without token |
| Compatibility with VPS | Suitable for temporary testing | It is suitable to use Gateway as a long-term control plane component |
The first principle of public network troubleshooting is: first prove that the packet can arrive, then prove that the handshake can pass, and finally prove that the business logic is online.
When you put Gateway on a VPS but still stack recompilation and browser tool load on the same machine, contention will be amplified into "random unhealthy"; splitting the control plane and heavy load into different bare metal instances is often more effective than repeatedly adjusting JVM-style parameters. When you need to combine parallelism and lease period, you can refer to the article "Mac mini M4 Buy or Rent TCO" published on the same day to tie the budget and milestones together for review.
WebSocket Upgrade transparent transmission skeleton when Nginx or Caddy is used to reverse OpenClaw Gateway
The following skeleton deliberately retains only key instructions related to WebSocket: the core isproxy_http_version 1.1,UpgradeandConnectionhead. When TLS terminates in reverse proxy, the upstream can use plaintext loopback; if you change to end-to-end TLS, you need to write another set of lists for the upstream protocol and certificate verification. Do not mix the two sets of assumptions on the same page of the runbook.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl;
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;
}
}
hint:If you have implemented IP restrictions or geo-blocking on the reverse proxy layer, remember to whitelist the channel provider's callback entry, otherwise there will be false positives like "the health check is always green and real messages can never come in".
Caddy’s route is automatic certificates and shorter site files, but the principle of WebSocket transparent transmission remains unchanged: it is still HTTP/1.1 upgrade semantics and correctHostTransparent transmission. No matter which set of reverse proxy you choose, it is recommended to write the "final URL after reverse proxy" into the team document to avoid half of the colleagues accessing the old IP and half of the colleagues accessing the new domain name, resulting in inconsistency between OAuth and the callback domain name.
Six steps to converge "external network is not connected" from the entrance to the channel layer
The following sequence deliberately places "local curl" at the bottom: public network problems are first verified with external network probes to avoid being deceived by the internal network perspective. Paste the output of each step into the work order, and the on-call handover will be much easier.
Freeze target URL:Write down the domain name and port that Dashboard finally accesses and whether it has been reversed to avoid mixed testing.
From the external network probe port:Verify that 443 or 18789 is reachable using a separate network path, aligned with the security group screenshot.
Check the host firewall:List the ufw or firewalld rules to verify that no local deny overrides the global pass.
Verify WebSocket:Use the browser network panel or curl to manually upgrade the request to see if it is 101.
Back to Gateway:implementopenclaw gateway statusandopenclaw doctor, confirm that the binding and token assumptions are not masked by the reverse proxy layer.
Verification channel:implementopenclaw channels status --probe, record the provider-side current limit and pairing status together.
When 01 to 04 are green and 05 is red, first suspect configuration drift or default value changes after upgrade; when 05 is green and 06 is red, don’t rush to restart the Gateway, first treat the channel as an independent subsystem.
Three criteria that can be written into the change review and the permanent division of labor on the cloud
Port and protocol conformance:If the public network entrance uses 443 to terminate TLS, all bookmarks, OAuth callbacks and Webhook URLs must be rewritten to the same domain name space simultaneously, otherwise they will fluctuate between "locally available" and "globally unavailable".
Detect layering:Divide "port reachable", "HTTP 200", "WebSocket 101", "Gateway RPC ok" and "channel ready" into five levels of signals, and it is prohibited to use one level to replace the conclusion of another level.
The control plane is isolated from the computing power plane:When the same machine also runs a heavy-load IDE or parallel simulator, you should evaluate moving the Gateway to an independent bare metal node to reduce contention instead of infinitely increasing swap.
Notice:Tying the Gateway directly to the public network without authentication is a high-risk mode for production accidents; be sure to configure token or equivalent control plane authentication according to the official guardrails, and record the changes in the audit log.
Tying the Gateway to a laptop that may be closed at any time will tie TLS, callback domain names, and token refreshes into unauditable personal habits; tying heavy loads and browser tool chains to the same VPS will mix "the network seems fine" and "random process jitters" into the same black box. In comparison,Mac Mini Cloud Bare Metal Rental by MESHLAUNCHIt provides exclusive Apple Silicon, flexible ordering and multi-region switching on a daily, weekly and monthly basis, and is more suitable for long-term operation of the OpenClaw control surface as a production component. You can open it firstRental price pageSelect one level each for the control surface and construction surface, and thenHelp CenterCheck SSH and network requirements; motivation and context can be combinedAll-weather cloud node solutionandInstallation and troubleshooting with doctorBoth articles will be reviewed together.
Yes, a typical conflict is port occupation and two sets of configuration root directories. It is recommended that only one set of control planes be kept on the same host, or port isolation and data directory isolation be clearly stated in the documentation. See you at the order entranceRental price page.
First align the local and daemon configurations according to the official migration instructions, and then restart the service; for a more complete command chain, seeInstallation and troubleshooting with doctor.
Please searchHelp CenterNetwork and SSH instructions, port and security group verification are written into the same page of the runbook.