Android app failed to connect and asking openclaw for help led to gateway bind failure

[indigo adder]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[forest dust]

@stone dawn That error means whatever you currently have in gateway.bind doesn’t match the allowed values in the config schema.

In ~/.openclaw/openclaw.json, bind must be one of these strings:

• "loopback" (local-only, default)
• "lan" (binds to 0.0.0.0)
• "tailnet" (binds to your Tailscale 100.x IP)
• "auto" (picks something sensible)

So if you set it to an IP like "0.0.0.0" / "192.168.x.x" / "localhost", change it to "lan" (or "tailnet" if you’re doing Tailscale).

Example (LAN):

{
  gateway: {

    mode: "local",
    bind: "lan",
  },
}

Example (Tailscale):

{
  gateway: {
    mode: "local",
    bind: "tailnet",
  },
}

Two quick follow-ups so we can get you unblocked fast:

1. Paste just your gateway: { ... } block here (redact tokens/passwords).
2. What does openclaw --version print?

Docs refs:

• Config section: https://docs.openclaw.ai/gateway/configuration
• FAQ gateway.bind bits: https://docs.openclaw.ai/help/faq

[stone dawn]

i cannot connect to the gateway from my android app and it could be router/client isolation, what can i do ?

[forest dust]

@stone dawn If it’s “router/client isolation”, there are basically 2 different failure modes:

A) Only discovery is broken (mDNS blocked), but direct TCP works

Symptom: the Android app doesn’t “discover” the gateway, but manual connect works.

Fix: in Android app → Settings → Advanced → Manual Gateway
Enter host = your gateway’s LAN IP (e.g. 192.168.1.50) and port = 18789, then Connect (Manual).

Quick test from the phone (same Wi‑Fi): open in Chrome:

• http://<gateway-ip>:18789/

If that page loads (even if it says unauthorized), the network path is fine and it’s just discovery.

B) True client isolation / guest Wi‑Fi (devices can’t talk at all)

Symptom: http://<gateway-ip>:18789/ from the phone times out (and manual connect fails).

Fix options:

1. Make sure the phone is not on Guest / IoT Wi‑Fi. Put both devices on the same “normal” SSID.
2. In the router/AP settings, disable stuff like AP isolation / client isolation / wireless isolation.
3. If you can’t change the network: use Tailscale on both the gateway host + the Android device, then set:

• gateway.bind: "tailnet"
• connect from Android using the gateway’s MagicDNS name or 100.x tailnet IP on port 18789.

Two things to paste so we can pinpoint which case you’re in

On the gateway host, paste:

1. openclaw --version
2. openclaw gateway status (especially the Listening: / Last gateway error: lines)

[stone dawn]

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Local probe uses loopback (127.0.0.1). bind=lan listens on 0.0.0.0 (all interfaces); use a LAN IP for remote clients.

Runtime: running (pid 134541, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: *:18789
Troubles: run openclaw status

[forest dust]

@stone dawn Nice — that status output means the Gateway is definitely up and listening on the LAN (Listening: *:18789). So now it’s either (1) you’re pointing Android at the wrong host, (2) LAN reachability is blocked (client isolation / VLAN / firewall), or (3) you’re hitting auth/pairing.

Here’s the fastest way to narrow it down:

1) Make sure Android is using a real LAN IP (not 0.0.0.0 / 127.0.0.1)

On the gateway machine, find its LAN IP (example outputs: 192.168.x.x / 10.x.x.x):

• Linux: hostname -I
• macOS: ipconfig getifaddr en0

Then in the Android app → Advanced → Manual Gateway:

• Host: that LAN IP (e.g. 192.168.1.50)
• Port: 18789

2) Test “is the network path open?” from the phone (this catches client isolation)

On Android (Chrome), open:

http://<LAN_IP>:18789/

Outcomes:

• Page loads (even if it says unauthorized / reconnecting): network is fine → it’s auth/pairing/app settings.
• Times out / can’t connect: this is real isolation/firewall/VLAN. Fix is router side (disable “AP/client isolation”, don’t use Guest/IoT SSID, make sure phone + gateway are on same VLAN), or use Tailscale.

3) If it loads but won’t connect: it’s usually token + device pairing

The gateway typically requires a token now.

• On the gateway host, run: openclaw dashboard (it prints the tokenized link / token)
• In the Android app, look for a Gateway token field in settings and paste that token.
• Then approve the pairing request on the gateway host:

openclaw devices list
openclaw devices approve <requestId>

(If you don’t see anything there, also try:)

openclaw nodes pending

4) If it is isolation and you can’t change the router: use Tailscale

Install Tailscale on gateway host + Android, then set:

gateway: { bind: "tailnet" }

and connect using the gateway’s MagicDNS name or 100.x tailnet IP (port 18789) + the same token.

If you tell me:

1. what OS the gateway host is (Linux/macOS/Windows), and
2. whether http://<LAN_IP>:18789/ loads on the phone,

I can tell you exactly which branch you’re in.

[stone dawn]

linux, no it doesnt open on the phone @forest dust

[forest dust]

@stone dawn If http://<gateway-lan-ip>:18789/ doesn’t open from the phone, that’s not an OpenClaw/app issue — it’s basic network reachability (isolation / VLAN / firewall). Since your Gateway is listening on *:18789, the two most common causes are:

1. Wi‑Fi client isolation / guest network (phone can’t reach LAN devices)
2. Linux firewall blocking inbound TCP/18789

Step 1 — confirm you’re using the right LAN IP

On the Linux gateway, paste:

hostname -I
ip route | head -n 5

Make sure Android “Manual Gateway” is using one of those IPs (NOT 0.0.0.0, NOT 127.0.0.1, and not a Tailscale 100.x unless you’re intentionally using Tailnet).

Also check on Android Wi‑Fi details that it’s on the same subnet (e.g. gateway 192.168.1.x and phone [phone].y).

Step 2 — check if Linux firewall is on

On the gateway, paste:

sudo ufw status
sudo iptables -S | head -n 40
sudo nft list ruleset | head -n 60

(Any one of those that applies is fine.)

If ufw is active, you’ll likely need to allow inbound 18789/TCP.

Step 3 — if it’s router isolation, the fix is router-side (or Tailscale)

Things to look for in the router/AP UI:

• “AP isolation”, “Client isolation”, “Wireless isolation”
• “Guest network” / “Guests can access LAN: off”
• Separate “IoT” SSID/VLAN

If you can’t change the network (dorm/hotel/guest Wi‑Fi), the clean workaround is Tailscale on both devices and then:

• set gateway.bind: "tailnet"

• connect Android to the gateway’s MagicDNS / 100.x address on port 18789

If you paste hostname -I + your firewall status (ufw status), I can tell you which of the two it is in one message.

[stone dawn]

hostname -I
ip route | head -n 5
192.168.1.6 172.17.0.1 2603:8098:1bf0:cb80::16a1 2603:8098:1bf0:cb80:496d:a1c:60e7:4606 2603:8098:1bf0:cb80:e25c:dac:bf1a:babe fd00:a08a:6ce:a242:671e:9aa1:edec:d93b fd00:a08a:6ce:a242:503e:282d:53be:ea16
default via 192.168.1.1 dev wlo1 proto dhcp src 192.168.1.6 metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.6 metric 600

[forest dust]

@stone dawn Yep — 192.168.1.6 is the correct LAN IP (ignore 172.17.0.1, that’s Docker).

Since http://192.168.1.6:18789/ times out on the phone, this is almost certainly network isolation or a host firewall (not OpenClaw anymore).

1) The #1 culprit: Wi‑Fi “client/AP isolation” (or Guest/IoT SSID)

Because your gateway host is on Wi‑Fi (wlo1), if the AP has “client isolation” enabled, Wi‑Fi devices can’t talk to each other.

Quick check:

• On Android, confirm its Wi‑Fi IP is also 192.168.1.x (same subnet).
• Make sure the phone is not on a “Guest” / “IoT” SSID.

Fixes:

• Disable AP isolation / client isolation / wireless isolation in the router/AP, or
• Plug the Linux gateway into Ethernet (wired often bypasses Wi‑Fi client isolation), or
• Use Tailscale on both devices (bypasses LAN policies entirely).

2) If it’s a Linux firewall, you’ll see it immediately

On the Linux gateway, can you paste:

sudo ss -lntp | grep 18789
sudo ufw status

If ufw is active, the usual fix is allowing the port:

sudo ufw allow 18789/tcp

3) One more super-fast sanity test

If you have any other device on the same Wi‑Fi (laptop/desktop), try opening:

http://192.168.1.6:18789/

• If that device works but the phone doesn’t → it’s phone Wi‑Fi isolation / SSID issue.
• If nothing on Wi‑Fi can reach it → firewall or AP isolation affecting all clients.

If you tell me whether the gateway host is on the main SSID vs guest/IoT, I can say which fix is most likely.

[stone dawn]

but my node web apps work when i expose them with --host in the config so is it really AP isolation / client isolation / wireless isolation ?

[forest dust]

@stone dawn Not 100% — “other web apps work with --host” proves some LAN reachability, but it doesn’t prove port 18789 is reachable.

Two common scenarios where both are true:

1. Host firewall / router rule blocks only certain ports (your web apps might be on 80/443/3000/etc, but 18789 is blocked).
2. Your “web apps” are reachable via a different path (reverse proxy, Tailscale, port forward), while 192.168.1.6:18789 is pure LAN.

Let’s make it concrete with 2 quick tests:

Test A (port-specific vs isolation)

From the phone, try any other port on that same machine that you know works (e.g. your node web app port).
If that loads but http://192.168.1.6:18789/ times out → it’s not general AP isolation, it’s port 18789 being blocked (firewall/router).

Test B (see if the phone’s packets even reach Linux)

On the Linux gateway, run this, then try opening the URL on the phone:

sudo tcpdump -ni wlo1 'tcp port 18789'

• If you see no SYN packets when the phone tries → router/Wi‑Fi isolation / different VLAN/SSID.
• If you see SYNs arriving but no connection → Linux firewall (ufw/nftables) is blocking.

If you paste sudo ufw status (or tell me “ufw not installed”), I can give the exact allow rule (LAN-only, not internet-exposed).

[stone dawn]

sudo ufw status was inactive,
port 18789 is not working but my node apps in 5173
wait no even 5173 isnt working right now

[forest dust]

@stone dawn If even 5173 stopped working from the phone, then this is no longer “port 18789 vs OpenClaw” — your phone can’t reach your Linux box on the LAN at all (or you’re accidentally not on the same network).

A few fast sanity checks:

1) Make sure the phone is really on the same Wi‑Fi (not cellular / not guest)

On Android Wi‑Fi details, confirm:

• IP looks like 192.168.1.xxx
• Gateway/router is 192.168.1.1
• Same SSID as the Linux machine is connected to

(Quick test: temporarily disable mobile data so it must use Wi‑Fi.)

2) Prove basic LAN reachability with a dumb HTTP server

On the Linux host run:

python3 -m http.server 8000 --bind 0.0.0.0

Then from the phone try:

• http://192.168.1.6:8000/

If that also doesn’t load → it’s almost certainly AP/client isolation, guest Wi‑Fi, or VLAN separation on the router/AP.

3) Check whether packets from the phone even arrive

While trying the URL from the phone, run on Linux:

sudo tcpdump -ni wlo1 'host 192.168.1.0/24 and (tcp port 8000 or tcp port 18789)'

• No packets at all → router/AP is blocking client-to-client (common “Wireless isolation” setting).
• Packets arrive but still no connect → then we look at local firewall/rules beyond ufw (nftables/firewalld) or binding issues.

If you paste:

• the phone’s Wi‑Fi IP + gateway (just those numbers),
• plus nmcli -t -f active,ssid dev wifi | head -5

…I can tell you immediately if you’re on guest/isolated Wi‑Fi vs something else.

[stone dawn]

phones : 192.168.1.245
gateways : 192.168.1.1

[forest dust]

@stone dawn Those IPs look correct (same subnet, same router), so in a normal LAN 192.168.1.245 → 192.168.1.6 should work.

Since it doesn’t, it’s almost always one of these:

1. Client isolation / guest Wi‑Fi rules (even if you’re still in 192.168.1.x, the AP can block Wi‑Fi→Wi‑Fi traffic)
2. A VPN on the phone (WireGuard / “always-on VPN”) blocking local LAN access
3. Less common: some other firewall on Linux (nftables/firewalld), even though ufw is inactive

Do these 2 quick tests to identify which:

Test 1: “dumb HTTP server” + phone browser

On the Linux box:

python3 -m http.server 8000 --bind 0.0.0.0

On the phone, try:

• http://192.168.1.6:8000/

Also: temporarily disable any VPN on the phone and retry that URL (VPNs commonly break LAN access).

Test 2: did the packets reach the Linux box?

While trying the URL on the phone, on Linux run:

sudo tcpdump -ni wlo1 'tcp port 8000'

What it means:

• If you see nothing in tcpdump when the phone tries → router/AP is blocking client-to-client (AP/client isolation, guest/IoT SSID policy, etc.). Fix is router setting, or move one device to Ethernet, or use Tailscale.
• If you do see SYN packets arriving but it still won’t load → then it’s host-side filtering; paste:

sudo nft list ruleset | head -n 80
sudo iptables -S | head -n 80