Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix gateway.bind=lan can advertise Docker bridge IP for dashboard and QR [2 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71493•Fetched 2026-04-26 05:12:10
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Author
deepkilodeepkilo
Participants
deepkilodeepkilo
Timeline (top)
cross-referenced ×2commented ×1

When gateway.bind=lan is used on a Linux host with Docker bridge interfaces, OpenClaw can advertise a Docker bridge address (172.18.0.1) instead of the real LAN/VPN address.

This affects at least:

  • openclaw gateway status Dashboard URL
  • openclaw qr --json / mobile pairing gateway URL

The gateway itself is listening correctly on 0.0.0.0:18789; the problem is the advertised/discovered address.

Root Cause

When gateway.bind=lan is used on a Linux host with Docker bridge interfaces, OpenClaw can advertise a Docker bridge address (172.18.0.1) instead of the real LAN/VPN address.

This affects at least:

  • openclaw gateway status Dashboard URL
  • openclaw qr --json / mobile pairing gateway URL

The gateway itself is listening correctly on 0.0.0.0:18789; the problem is the advertised/discovered address.

Fix Action

Fixed

PR fix notes

PR #71499: fix(gateway): use secure dashboard links when TLS is enabled

Description (problem / solution / changelog)

Summary

Fixes #71494.

When gateway.tls.enabled=true, dashboard/control UI links now use secure schemes:

  • https://... for HTTP dashboard URLs
  • wss://... for WebSocket URLs

The daemon status path now carries the daemon TLS state into the dashboard link renderer, matching the existing wss:// probe target behavior.

Validation

  • corepack pnpm test src/commands/onboard-helpers.test.ts src/commands/dashboard.test.ts src/commands/dashboard.links.test.ts src/cli/daemon-cli/status.print.test.ts
  • corepack pnpm test src/commands/status-all/format.test.ts
  • PATH="/tmp/openclaw-pnpm-shim:$PATH" pnpm check:changed reached typecheck/lint/import-cycle/guards successfully, then failed in an existing environment-sensitive gateway test because the local host still auto-selects a Docker bridge LAN IP (the separate #71493 issue):
    • src/gateway/server.node-pairing-auto-approve.test.ts > auto-approves first-time node pairing from a matching direct non-loopback CIDR

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/cli/dashboard.md (modified, +2/-0)
  • docs/web/dashboard.md (modified, +4/-0)
  • docs/web/index.md (modified, +3/-0)
  • src/cli/daemon-cli/status.gather.test.ts (modified, +1/-0)
  • src/cli/daemon-cli/status.gather.ts (modified, +4/-1)
  • src/cli/daemon-cli/status.print.test.ts (modified, +57/-1)
  • src/cli/daemon-cli/status.print.ts (modified, +1/-0)
  • src/commands/configure.wizard.ts (modified, +2/-0)
  • src/commands/dashboard.links.test.ts (modified, +1/-0)
  • src/commands/dashboard.test.ts (modified, +3/-0)
  • src/commands/dashboard.ts (modified, +1/-0)
  • src/commands/onboard-helpers.test.ts (modified, +11/-0)
  • src/commands/onboard-non-interactive/local.ts (modified, +1/-0)
  • src/commands/status-all/format.test.ts (modified, +10/-0)
  • src/commands/status-all/format.ts (modified, +1/-0)
  • src/gateway/control-ui-links.ts (modified, +5/-2)
  • src/wizard/setup.finalize.ts (modified, +2/-0)

PR #71503: fix(gateway): prefer physical LAN addresses before bridge interfaces

Description (problem / solution / changelog)

Summary

Fixes #71493.

gateway.bind=lan address selection now prefers physical/default-looking LAN interfaces before Docker/bridge/container-style interfaces when advertising automatic LAN URLs.

The change intentionally does not hard-ban Docker/bridge/veth/cni/virbr/podman-style interfaces. They are only de-prioritized for automatic selection and remain usable when explicitly configured, or when they are the only candidate.

Details

  • Adds a shared LAN IPv4 picker that prefers:
    • exact common physical names (en0, eth0)
    • physical/default-looking names (en*, eth*, wl*, wlan*, etc.)
    • other non-deprioritized interfaces
    • Docker/bridge-style interfaces as final fallback
  • Uses the same selection behavior for pairing setup code LAN URL resolution.
  • Mirrors the behavior in the bundled device-pair plugin path so plugin-issued pairing codes do not drift from core QR behavior.

Validation

  • corepack pnpm test src/gateway/net.test.ts src/pairing/setup-code.test.ts
  • corepack pnpm test extensions/device-pair/index.test.ts
  • corepack pnpm test src/gateway/server.node-pairing-auto-approve.test.ts

Changed files

  • extensions/device-pair/index.ts (modified, +80/-5)
  • src/gateway/net.test.ts (modified, +55/-1)
  • src/gateway/net.ts (modified, +88/-6)
  • src/pairing/setup-code.test.ts (modified, +40/-0)
  • src/pairing/setup-code.ts (modified, +10/-2)

Code Example

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: wss://127.0.0.1:18789
Dashboard: http://172.18.0.1:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.
Connectivity probe: ok
Listening: *:18789

---

{
  "gatewayUrl": "wss://172.18.0.1:18789",
  "urlSource": "gateway.bind=lan",
  "auth": "token"
}

---

br-c87a82b2afb7 172.18.0.1/16
docker0 172.17.0.1/16
wgdh 192.168.178.209/24
wlp13s0 192.168.1.193/22

---

br-c87a82b2afb7 172.18.0.1 internal=false
wgdh 192.168.178.209 internal=false
wlp13s0 192.168.1.193 internal=false
RAW_BUFFERClick to expand / collapse

Summary

When gateway.bind=lan is used on a Linux host with Docker bridge interfaces, OpenClaw can advertise a Docker bridge address (172.18.0.1) instead of the real LAN/VPN address.

This affects at least:

  • openclaw gateway status Dashboard URL
  • openclaw qr --json / mobile pairing gateway URL

The gateway itself is listening correctly on 0.0.0.0:18789; the problem is the advertised/discovered address.

Environment

  • OpenClaw: 2026.4.23 (a979721)
  • OS: Linux 6.17.0-1017-oem
  • Node: 22.22.2
  • Gateway config summary:
    • gateway.mode=local
    • gateway.bind=lan
    • gateway.port=18789
    • gateway.tls.enabled=true
    • gateway.tailscale.mode=off

Reproduction / observed output

openclaw gateway status reports:

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: wss://127.0.0.1:18789
Dashboard: http://172.18.0.1:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.
Connectivity probe: ok
Listening: *:18789

openclaw qr --json resolves the pairing gateway URL to the Docker bridge address:

{
  "gatewayUrl": "wss://172.18.0.1:18789",
  "urlSource": "gateway.bind=lan",
  "auth": "token"
}

Relevant IPv4 interfaces on the host:

br-c87a82b2afb7 172.18.0.1/16
docker0 172.17.0.1/16
wgdh 192.168.178.209/24
wlp13s0 192.168.1.193/22

Node.js sees the Docker bridge as a non-internal IPv4 address:

br-c87a82b2afb7 172.18.0.1 internal=false
wgdh 192.168.178.209 internal=false
wlp13s0 192.168.1.193 internal=false

Expected behavior

For gateway.bind=lan, OpenClaw should not advertise Docker/bridge/container-only interface addresses for dashboard links or mobile pairing URLs.

It should prefer a reachable real LAN/VPN interface, for example:

  • default route / primary route interface when appropriate
  • physical LAN/Wi-Fi interfaces (eth*, en*, wl*, etc.)
  • explicitly configured public/device-pair URL when present

Suspected cause

The current LAN address selection appears to choose the first non-internal/private IPv4 address. Docker bridge interfaces such as docker0 and br-* satisfy that test, so they can win over the actual LAN interface.

Code paths observed during diagnosis:

  • status/dashboard display: resolveControlUiLinks / pickBestEffortPrimaryLanIPv4 / pickPrimaryLanIPv4
  • QR/mobile pairing: resolveGatewayBindUrl via pickLanIPv4

These paths do not appear to consistently filter out container/bridge interfaces.

Suggested fix

Consider centralizing LAN address selection and excluding likely container/virtual bridge interfaces, e.g.:

  • docker0
  • br-*
  • veth*
  • cni*
  • podman*
  • virbr*

Then prefer either:

  1. default route / primary route interface, or
  2. known physical LAN interface prefixes (en*, eth*, wl*, wlan*, etc.), with a safe fallback.

It would also be good for gateway status, qr, and device-pair code to use the same address selection logic so they do not disagree.

extent analysis

TL;DR

The issue can be fixed by centralizing LAN address selection in OpenClaw and excluding container/bridge interfaces, then preferring a default route or physical LAN interface.

Guidance

  • Identify and exclude known container/bridge interface prefixes (e.g., docker0, br-*, veth*) from LAN address selection.
  • Prefer the default route or primary route interface for LAN address selection when available.
  • Use known physical LAN interface prefixes (e.g., en*, eth*, wl*, wlan*) as a fallback for LAN address selection.
  • Ensure consistent address selection logic across gateway status, qr, and device-pair code paths.

Example

No code snippet is provided due to the lack of specific implementation details in the issue.

Notes

The suggested fix requires modifications to OpenClaw's address selection logic, which may involve updating the pickBestEffortPrimaryLanIPv4 and pickLanIPv4 functions to exclude container/bridge interfaces and prefer default or physical LAN interfaces.

Recommendation

Apply a workaround by manually configuring the gateway to bind to a specific LAN interface or IP address, if possible, until the centralized LAN address selection logic is implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

For gateway.bind=lan, OpenClaw should not advertise Docker/bridge/container-only interface addresses for dashboard links or mobile pairing URLs.

It should prefer a reachable real LAN/VPN interface, for example:

  • default route / primary route interface when appropriate
  • physical LAN/Wi-Fi interfaces (eth*, en*, wl*, etc.)
  • explicitly configured public/device-pair URL when present
#environment variable#network issue#logging issue#authentication issue#prompt issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix gateway.bind=lan can advertise Docker bridge IP for dashboard and QR [2 pull requests, 1 comments, 1 participants]