vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-04-24 15:41:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: refresh tailscale auth rate limit refs

Browse Source
This commit is contained in:
Peter Steinberger
2026-04-04 14:30:02 +01:00
parent 7d22a16adb
commit 114496871d
7 changed files with 20 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/help/faq.md
View File

@@ -168,6 +168,7 @@ Quick answers plus deeper troubleshooting for real-world setups (local dev, VPS,
**Not on localhost:**
- **Tailscale Serve** (recommended): keep bind loopback, run `openclaw gateway --tailscale serve`, open `https://<magicdns>/`. If `gateway.auth.allowTailscale` is `true`, identity headers satisfy Control UI/WebSocket auth (no pasted shared secret, assumes trusted gateway host); HTTP APIs still require shared-secret auth unless you deliberately use private-ingress `none` or trusted-proxy HTTP auth.
Bad concurrent Serve auth attempts from the same client are serialized before the failed-auth limiter records them, so the second bad retry can already show `retry later`.
- **Tailnet bind**: run `openclaw gateway --bind tailnet --token "<token>"` (or configure password auth), open `http://<tailscale-ip>:18789/`, then paste the matching shared secret in dashboard settings.
- **Identity-aware reverse proxy**: keep the Gateway behind a non-loopback trusted proxy, configure `gateway.auth.mode: "trusted-proxy"`, then open the proxy URL.
- **SSH tunnel**: `ssh -N -L 18789:127.0.0.1:18789 user@host` then open `http://127.0.0.1:18789/`. Shared-secret auth still applies over the tunnel; paste the configured token or password if prompted.

3
docs/help/troubleshooting.md
View File

@@ -142,6 +142,9 @@ flowchart TD
- That cached-token retry reuses the cached scope set stored with the paired
device token. Explicit `deviceToken` / explicit `scopes` callers keep
their requested scope set instead.
- On the async Tailscale Serve Control UI path, failed attempts for the same
`{scope, ip}` are serialized before the limiter records the failure, so a
second concurrent bad retry can already show `retry later`.
- `too many failed authentication attempts (retry later)` from a localhost
browser origin → repeated failures from that same `Origin` are temporarily
locked out; another localhost origin uses a separate bucket.