Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix gateway status dashboard URL uses http when TLS is enabled [1 pull requests, 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#71494•Fetched 2026-04-26 05:12:09
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
deepkilodeepkilo
Participants
deepkilodeepkilo
Timeline (top)
referenced ×2closed ×1cross-referenced ×1

When gateway.tls.enabled=true, openclaw gateway status still renders the Dashboard URL with http://... instead of https://....

This is confusing because the gateway is actually serving HTTPS/WSS.

Root Cause

This is confusing because the gateway is actually serving HTTPS/WSS.

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)

Code Example

Probe target: wss://127.0.0.1:18789
Dashboard: http://172.18.0.1:18789/

---

curl -I http://127.0.0.1:18789/
# curl: (1) Received HTTP/0.9 when not allowed

curl -k -I https://127.0.0.1:18789/
# HTTP/1.1 200 OK

---

https://<host>:<port>/

---

wss://<host>:<port>
RAW_BUFFERClick to expand / collapse

Summary

When gateway.tls.enabled=true, openclaw gateway status still renders the Dashboard URL with http://... instead of https://....

This is confusing because the gateway is actually serving HTTPS/WSS.

Environment

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

Observed output

openclaw gateway status prints:

Probe target: wss://127.0.0.1:18789
Dashboard: http://172.18.0.1:18789/

The probe target correctly uses wss://, but the Dashboard URL uses http://.

Local protocol check:

curl -I http://127.0.0.1:18789/
# curl: (1) Received HTTP/0.9 when not allowed

curl -k -I https://127.0.0.1:18789/
# HTTP/1.1 200 OK

So the displayed Dashboard scheme should be https:// when TLS is enabled.

Expected behavior

When gateway.tls.enabled=true, status/dashboard links should use:

https://<host>:<port>/

and the corresponding WebSocket endpoint should use:

wss://<host>:<port>

Suspected cause

The Dashboard link rendering path appears to construct httpUrl/wsUrl without considering gateway.tls.enabled, while the probe target does consider TLS.

Observed related code path during diagnosis:

  • resolveControlUiLinks
  • openclaw gateway status

Suggested fix

Pass TLS state into the dashboard/control UI link resolver and render:

  • https:// / wss:// when TLS is enabled
  • http:// / ws:// otherwise

extent analysis

TL;DR

Pass the TLS state to the dashboard link resolver to correctly render https:// or http:// based on the gateway.tls.enabled configuration.

Guidance

  • Review the resolveControlUiLinks function to ensure it considers the gateway.tls.enabled configuration when constructing the Dashboard URL.
  • Update the openclaw gateway status command to pass the TLS state to the link resolver.
  • Verify that the gateway.tls.enabled configuration is correctly set to true in the gateway config.
  • Test the fix by running openclaw gateway status and checking that the Dashboard URL uses https:// when TLS is enabled.

Example

No code snippet is provided as the issue does not include the relevant code, but the fix should involve updating the resolveControlUiLinks function to consider the gateway.tls.enabled configuration.

Notes

The fix assumes that the resolveControlUiLinks function is responsible for constructing the Dashboard URL and that the gateway.tls.enabled configuration is correctly set.

Recommendation

Apply workaround: update the resolveControlUiLinks function to consider the gateway.tls.enabled configuration, as this is the most direct way to fix the issue without upgrading to a potentially fixed version.

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

When gateway.tls.enabled=true, status/dashboard links should use:

https://<host>:<port>/

and the corresponding WebSocket endpoint should use:

wss://<host>:<port>
#configuration error#environment variable#network issue#logging issue#authentication 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