---
title: "配置安全与远程访问"
description: "理解 OpenClaw 安全与远程访问：个人助手信任模型、security audit、Control UI、Tailscale、SSH tunnel、sandbox 和共享入口风险。"
verifiedAt: "2026-05-06"
---

OpenClaw 的安全前提很明确：它是个人助手信任模型，不是给多个互不信任用户共用的多租户安全边界。新手必须先理解这个前提，否则后面讨论 allowlist、pairing、Control UI、远程访问和 sandbox 都会跑偏。

一句话：不要把一个有真实工具权限的 OpenClaw Gateway，当成可以随便给陌生人访问的公共服务。

> [!NOTE]
> **这一章用 15 分钟换什么**：你会知道谁能发消息、谁能打开 Control UI、Gateway 应该绑定在哪里、远程访问该走 Tailscale 还是 SSH tunnel，以及什么时候必须拆 Gateway。

## 1. 先理解：信任边界是什么

官方安全页的核心说法是：一个 Gateway 应该属于一个受信任的操作边界。可以是一个人，也可以是一个可信团队；但不能是多个互不信任的人共享同一个有工具权限的 Agent。

推荐边界是一个用户或可信团队、一个 Gateway、一套 credentials、一个 OS 用户或一台主机。

不推荐的边界是：公开群组直接接入可执行命令的 Agent；多人共享同一套个人浏览器、账号和密钥；Gateway 端口裸露到公网；把运行时凭据和 session transcript 提交到 workspace 仓库。

如果确实有互不信任用户，正确做法不是“多写几个规则”，而是拆 Gateway，最好拆到不同 OS 用户、不同主机或不同 VPS。

```mermaid
flowchart TD
    Trust["一个信任边界"]
    Gateway["一个 Gateway"]
    Credentials["一套 credentials"]
    Host["一个 OS 用户 / 主机"]
    Agents["一个或多个 Agent"]
    Untrusted["互不信任用户"]
    Split["拆 Gateway / OS 用户 / 主机"]

    Trust --> Gateway
    Trust --> Credentials
    Trust --> Host
    Gateway --> Agents
    Untrusted --> Split

    style Trust fill:#dcfce7,stroke:#22c55e,stroke-width:2px
    style Gateway fill:#e0f2fe,stroke:#0284c7,stroke-width:2px
    style Untrusted fill:#fee2e2,stroke:#ef4444,stroke-width:2px
    style Split fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
```

> [!WARNING]
> **sessionKey 不是授权边界**：它只是路由和上下文选择，不是用户认证。多个不可信用户不能靠 sessionKey 变成安全多租户。

## 2. 怎么判断入口是否安全

先问“谁能发消息”。DM 默认应该走 pairing 或 allowlist；群组入口也应该 require mention 或 allowlist。陌生人能直接驱动工具，是 OpenClaw 里最危险的形态。

再问“这个 Agent 能做什么”。能读文件、写文件、执行命令、控制浏览器、发消息、访问网络的 Agent，都不应该暴露给不受信任入口。

再问“上下文是否隔离”。不要让陌生人共享 main session。多用户场景至少使用 per-channel-peer 或 per-account-channel-peer 这类 session scope，避免一个人的输入污染另一个人的上下文。

最后问“远程入口如何保护”。远程访问优先用 Tailscale / VPN，其次 SSH tunnel；只有在受控反代、TLS、认证、trusted proxy 和审计都到位时，才考虑公网入口。

| 问题 | 错误答案 | 正确方向 |
|------|------|------|
| 谁能发消息 | 先 open，后面再说 | pairing / allowlist / group allowlist |
| Agent 能做什么 | 先给完整 tools | 共享入口只给最少 tools |
| 上下文怎么隔离 | 所有人 main session | per-channel / per-account / per-peer |
| 远程怎么访问 | 直接公网端口 | loopback + Tailscale / SSH tunnel |

## 3. 先跑安全审计

每次改 channels、Gateway、Control UI、sandbox、tools、远程访问后，都应该跑官方 security audit。

```bash
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json
```

普通审计看明显危险配置；deep 审计看更细的组合风险；fix 只做有限修复，不替你决定业务策略。它能帮你发现开放 DM、开放 group、危险 Control UI flag、共享 main session、debug 绕过、权限过宽等问题。

新手不要把 audit 当形式。它应该是每次开放新入口前的检查点。

官方 `security audit --fix` 的修复范围是刻意收窄的：它会修一些常见 open group policy、日志脱敏、权限和文件模式问题，但不会替你决定业务上谁该拥有工具权限。

> [!IMPORTANT]
> **audit warning 要逐条解释**：不是所有 warning 都要自动修，但每一个都要有“已修复 / 已接受 / 需要拆分 Gateway”的结论。

> [!TIP]
> **安全审计要留下判断**：能自动修的修；不能修的写清为什么接受；涉及互不信任用户、公开入口或个人账号混用时，默认结论应该是拆 Gateway 或拆运行环境。

## 4. Control UI 不要降级认证

Control UI 最适合在 localhost 或 HTTPS 安全上下文里使用。官方文档里有一些兼容或调试 flag，但它们不应该被当成远程访问方案。

尤其要警惕 `gateway.controlUi.allowInsecureAuth` 和 `gateway.controlUi.dangerouslyDisableDeviceAuth`。前者是本地兼容开关，不是远程放行；后者属于严重降级，只能短时调试，调完立刻关。

新手判断标准很简单：如果你说不清为什么必须开这个 flag，就不要开。

## 5. 远程访问优先顺序

第一选择是 Tailscale 或 VPN，让 Gateway 不直接暴露在公网。

第二选择是 SSH tunnel。远端 Gateway 仍然绑定 loopback，本机通过隧道访问 `127.0.0.1:18789`。这能显著降低误暴露风险。

第三选择才是公网入口，而且必须有 TLS、认证、可信反代和日志审计。

远程连接不是“能打开页面就安全”。Gateway auth、device pairing、token 保管和 allowlist 仍然要保留。

| 方式 | 适合 | 安全前提 |
|------|------|------|
| Tailscale Serve / VPN | 常驻主机、家用服务器、VPS | Gateway 继续 loopback，tailnet 身份可信 |
| SSH tunnel | 通用兜底、临时远程 | 本地转发到远端 loopback |
| TLS + trusted proxy | 明确公网入口 | auth、TLS、审计、代理身份头都到位 |
| 直接公网 ws | 不建议 | 容易变成裸露控制面 |

SSH tunnel：

```bash
ssh -N -L 18789:127.0.0.1:18789 user@host
```

如果用 `--url` 访问远程 Gateway，CLI 不会自动复用隐式 config 或 env credentials。需要显式传 `--token` 或 `--password`，缺失就是错误。

> [!CAUTION]
> **`gateway.remote.token` 不是 server auth**：它是客户端凭据来源，不会自动配置服务端认证。服务端仍然要配置 `gateway.auth.*` 或 trusted proxy。

## 6. Tailscale 的安全定位

OpenClaw 可以用 Tailscale Serve 或 Funnel 暴露 Gateway dashboard 和 WebSocket port。更稳的默认是 Serve：tailnet-only，Gateway 仍然绑定 loopback，Tailscale 提供 HTTPS、路由和身份头。

Funnel 是 public HTTPS，安全要求更高。新手不要把 Funnel 当成“比 SSH tunnel 更省事”的默认方案。

| 模式 | 暴露范围 | 新手建议 |
|------|------|------|
| Serve | tailnet 内 | 推荐 |
| Funnel | 公网 HTTPS | 谨慎，必须确认 auth 和暴露面 |
| SSH tunnel | 使用方本机 | 最通用兜底 |

## 7. Sandbox 只降低爆炸半径，不等于完美隔离

OpenClaw 可以把 tools 放进 sandbox backend 里执行，例如 Docker、SSH 或 OpenShell。它能降低文件和进程访问范围，但不是完美安全边界。

被 sandbox 的通常是 tool execution，例如 `exec`、`read`、`write`、`edit`、`apply_patch`、`process` 等。Gateway 进程本身不在 sandbox 里；明确 elevated 的工具也可能绕开 sandbox。

| sandbox mode | 含义 |
|------|------|
| `off` | 不启用 sandbox |
| `non-main` | 只隔离非 main session，群组和频道通常会被隔离 |
| `all` | 所有 session 都进 sandbox |

> [!WARNING]
> **sandbox 不是不做入口控制的理由**：不可信用户能触发工具，本身就是高风险。sandbox 是第二层，不是第一层。

## 8. Workspace 和运行时要分开

Workspace 可以作为私有 git 备份，但运行时状态不要进仓库。

不要提交 `~/.openclaw/openclaw.json`、credentials、auth profiles、Codex home、sessions、全局 skills 等路径。它们可能包含模型授权、渠道登录态、session transcript、密钥和本机状态。

公开教程仓只能放脱敏说明和示例。私有 workspace 仓库也不要提交真实 token、OAuth 文件、密码和私密附件原文。

## 9. 共享入口怎么做

如果要给家人、公司同事或群聊使用，不要直接复用个人 main Agent。更稳的方式是单独建一个 shared Agent，给独立 workspace、独立 session、最少 tools 和尽量只读的访问策略。

共享入口只给完成任务必需的能力。需要写文件、执行命令、发消息、调用外部 API 时，再逐项增加，并重新跑 audit。

公司共享 Agent 可以接受的模式是：大家在同一个信任边界里，并且 runtime 是业务专用的。它应该运行在 dedicated machine / VM / container、dedicated OS user、dedicated browser profile 和 dedicated accounts 上。

不要把个人 Apple / Google 账号、个人密码管理器、个人浏览器 profile 混进公司共享 runtime。

## 10. 新手常见坑

- 把 pairing 当成唯一安全措施：它控制谁能连上，不等于工具权限最小化。
- 让群聊接入个人 Agent：群里任何允许用户都可能诱导工具调用。
- 公网暴露 Gateway 端口：没有 VPN / TLS / auth / trusted proxy 时风险很高。
- 打开危险 Control UI flag 后忘记关闭。
- 把 sessionKey 当授权边界：官方明确它是路由和上下文选择，不是用户认证。
- 把 workspace 备份到公开仓库：长期记忆和运行时凭据很容易混在一起。
- 只靠 prompt 规则防 prompt injection：真正边界要靠 channel policy、tool policy、sandbox、host isolation。

## 11. 怎么验收

你能明确说出：谁能发消息、谁能打开 Control UI、Gateway 绑定在哪个地址、远程访问走 Tailscale / SSH tunnel / TLS 反代中的哪一种。

你能跑完 security audit，并解释每个 warning 是已修复、已接受，还是需要拆分 Gateway。

你能证明共享入口没有使用个人 workspace、个人浏览器 profile、个人账号和个人密钥。

你能证明运行时凭据没有进入 workspace git，也没有出现在日志里。

## 12. 本章自检

1. 为什么 OpenClaw 不是互不信任用户共享的多租户安全边界？
2. 远程访问为什么优先 Tailscale / SSH tunnel，而不是直接公网端口？
3. sandbox、pairing、tool policy 各自管什么？

> [!IMPORTANT]
> **过关标准**：你能用一句话说清 —— “OpenClaw 安全的核心是先切信任边界，再收窄入口、工具、workspace、远程访问和运行时凭据。”

## 13. 接下来去哪

<Cards>
  <Card href="/docs/openclaw/official/01-gateway-runtime/automation" title="自动化" description="安全边界清楚之后，再配置 cron、tasks、hooks、standing orders 和 heartbeat。" />
  <Card href="/docs/openclaw/official/01-gateway-runtime/channels" title="Channel 配置" description="如果入口访问控制还没分清，先回到上一章。" />
  <Card href="/docs/openclaw/understanding/09-channel-security" title="理解：Channel 与安全" description="从理解篇重新核对入口、工具、沙箱和 Gateway 暴露面。" />
</Cards>

## 14. 官方资料

- [Security](https://docs.openclaw.ai/security)
- [Security audit checks](https://docs.openclaw.ai/gateway/security/audit-checks)
- [Remote access](https://docs.openclaw.ai/gateway/remote)
- [Tailscale](https://docs.openclaw.ai/gateway/tailscale)
- [Sandboxing](https://docs.openclaw.ai/gateway/sandboxing)
