---
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="/zh-Hant/docs/openclaw/official/01-gateway-runtime/automation" title="自動化" description="安全邊界清楚之後，再配置 cron、tasks、hooks、standing orders 和 heartbeat。" />
  <Card href="/zh-Hant/docs/openclaw/official/01-gateway-runtime/channels" title="Channel 配置" description="如果入口訪問控制還沒分清，先回到上一章。" />
  <Card href="/zh-Hant/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)
