如何在 VPS 上安全執行 OpenClaw

OpenClaw 是什麼，以及為什麼要先強化它

OpenClaw 是自行代管的 AI 代理程式。您可以在自己的伺服器上執行它，將它連接至大型語言模型。它能執行 shell 命令、控制瀏覽器、讀寫檔案，也能處理您從聊天應用程式傳送給它的訊息。這種控制範圍正是此工具的用途，也是它的完整風險。能執行任意命令的代理程式，其安全性取決於執行它的主機，以及您為它設定的限制。

本指南的基調建立在兩項事實上。第一，OpenClaw 的設計是由您負責強化。其安全模型將嚴格的工具政策、沙箱與妥善的權限設定交由操作人員負責，而不是依賴安全的預設值。第二，該專案已發生過嚴重的安全事件：2026 年 3 月，在 4 天內揭露了 9 個安全問題，其中包括 CVE-2026-32922 這項嚴重的權限提升漏洞，評分為 10 分中的 9.9 分。這兩項事實都不代表您應該避免使用 OpenClaw。它們表示您不應以草率方式執行它，而本指南提供的是審慎的做法。審慎做法的一部分，是預先決定代理程式在不詢問您的情況下可以執行多少操作。Claude Code 會透過權限模式明確呈現這項選擇；對於您不在其前方操作的伺服器，權限設定應比您正在監看的筆記型電腦更嚴格。

此外也有好消息。OpenClaw 已替您做出一項安全選擇：其 gateway 是控制所有功能的單一程序，預設會監聽 loopback 位址。因此，除非您刻意將它公開，否則網際網路無法連線至它。以下大部分工作，都是維持這項設定，並在發生問題時限制影響範圍。

為 OpenClaw 建立專用的非特權使用者

絕對不要以 root 身分執行代理程式。如果 OpenClaw 以 root 身分執行，無論問題源自錯誤、錯誤指示，或上述的 CVE，造成的損害都沒有上限。請建立專用的系統使用者，不授予登入 shell，也不授予 sudo 權限，並以該使用者身分執行代理程式：

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw 所有的資料都位於 /opt/openclaw 下，且由該帳戶擁有。這是最重要的步驟，也遵循 以非特權使用者身分執行服務 中介紹的相同原則：代理程式執行所使用的帳戶權限，就是它可能造成損害的上限。

安裝 OpenClaw

OpenClaw 以 npm 套件發佈，因此如果伺服器尚未安裝 Node.js，請先安裝。全域安裝套件後，openclaw binary 會加入 PATH，所有使用者都能使用。接著執行一次性 onboarding 步驟：

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

以 openclaw user 執行 onboarding，表示 agent 的設定會寫入其家目錄 /opt/openclaw，而不是 root 的家目錄。此專案也提供 curl -fsSL https://openclaw.ai/install.sh | bash installer，可用一行指令完成相同的安裝。執行 onboarding 時請略過 --install-daemon flag；該 flag 會註冊 OpenClaw 自己的服務，而下方建立的 hardened systemd unit 具有更嚴格的設定。

將 gateway 綁定在 loopback，置於防火牆後方

gateway 預設會綁定至 127.0.0.1。請維持此設定。幾乎沒有理由將該埠公開到網際網路。這麼做會讓任何找到它的人，都能取得一個會執行命令之程序的遠端立足點。

在主機前方設定預設拒絕的防火牆，避免服務意外暴露：

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

這裡有兩個需要避免的陷阱。只涵蓋 IPv4 的防火牆，可能讓同一項服務在 IPv6 上完全開放。這正是讓許多人中招的 IPv6 防火牆漏洞。如果需要從筆記型電腦連線至 gateway，也不要開放該埠。請透過 VPN 或 SSH tunnel 連線，讓 agent 永遠不會監聽公開網際網路。

隔離其機密

OpenClaw 需要連線至語言模型的 API key。這組 key 可以使用你的費用，並透過 agent 代表你執行操作，因此應將它視同密碼。不要將它放在 unit file 或任何 repository 中。請將它存放在只有 OpenClaw 使用者能讀取的檔案中：

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd unit 會使用 EnvironmentFile 載入該檔案，因此 key 不會出現在 command line、log 或 shell history 中。這種做法適用於伺服器上的所有 secret：對自架 Vaultwarden 進行 強化檢查，重點在於其 admin token 與 backup file，而不是加密機制，因為檔案權限才真正決定誰能讀取靜態儲存的 secret。

以強化的 systemd 服務執行

在 systemd 下執行 agent 可自動重新啟動，透過 journalctl 產生整潔的日誌。更重要的是，它提供一組核心層級的 sandbox 選項。即使 agent 已遭入侵，這些選項也能限制程序可存取的範圍。對 agent 而言，最重要的是 NoNewPrivileges，確保它無法取得新的權限；ProtectSystem=strict，讓檔案系統保持唯讀，僅允許指定位置寫入；PrivateTmp，提供專用且隔離的暫存目錄；以及 ProtectHome，防止它讀取家目錄。

在此產生完整的強化 unit，然後將它複製到 /etc/systemd/system/openclaw.service：

此 unit 會啟動 openclaw gateway，也就是控制 agent 的長時間執行程序。如果 which openclaw 在你的伺服器上顯示不同路徑，請調整 ExecStart 以符合該路徑。這些指令，以及 daemon-reload 和 enable --now 的完整說明，請參閱以 systemd 服務執行程式。貼上 unit 後，簡要步驟如下：

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

也要強化對外入口

Agent 主機的安全性取決於周邊伺服器。再加上兩層防護即可完成設定。將 SSH 改為僅使用金鑰驗證，並停用 root 登入，做法可參考 VPS 上的 SSH 強化，避免管理該主機所使用的帳戶遭到暴力破解。接著加入 Fail2ban，封鎖持續掃描所有公開埠的掃描程式。這兩項設定都不會直接影響 OpenClaw，但能切斷攻擊者用來接觸它的路徑。

刻意保持最新

2026 年 3 月的揭露事件最清楚地說明了為何必須持續更新。代理程式中的權限提升漏洞，遠比一般 Web 應用程式中的同類漏洞嚴重，因為代理程式本來就能執行命令。請關注專案的版本發布，迅速套用安全性更新，並將 OpenClaw 升級視為例行維護，不要延後處理。

若要了解實際強化的對象，OpenClaw 類型代理程式的架構會逐一說明各個組成部分，而在 VPS 上建立自己的 AI 代理程式則涵蓋所有代理程式都具備的一般結構。如果你最後在旁邊執行第二個代理程式，請記住，同一台 VPS 上的兩個 Claude Code 工作階段可以互相交接工作；因此，每個代理程式都需要自己的帳戶與限制，不應直接沿用你的設定。

FAQ

在公開 VPS 上執行 OpenClaw 是否安全？

如果做好強化設定，可以安全執行。OpenClaw 的設計功能強大：它會執行 shell 命令並控制瀏覽器，因此設定不慎確實可能造成危險。該專案也曾出現嚴重的 CVE（2026 年 3 月的 CVE-2026-32922）。它的安全模型預期由操作人員自行加入限制。請使用非特權使用者執行，讓 gateway 維持在 loopback 上，並搭配預設拒絕的防火牆；隔離 API 金鑰，並將其作為強化過的 systemd 服務執行。

是否應該將 OpenClaw gateway 暴露到網際網路？

不應該。gateway 預設繫結至 loopback，請維持此設定。它是控制 agent 的單一程序，因此暴露 gateway 等同於提供一條遠端路徑，讓外部連入一個會執行命令的服務。若需要從遠端存取，請使用 VPN 或 SSH tunnel，不要開放該埠。

OpenClaw 應該以哪個使用者身分執行？

應使用專用的 system user，且不得具備 login shell 或 sudo，絕對不可使用 root。如果 agent 遭到入侵，其使用者帳戶權限就是損害範圍的上限。因此，該帳戶只能擁有自己在類似 /opt/openclaw 目錄下的檔案，不得擁有其他檔案。

如何保護 OpenClaw 的 API 金鑰？

將金鑰儲存在只有 OpenClaw 使用者可讀取的檔案中（mode 600），並使用 systemd 的 EnvironmentFile 將其載入服務。不要將金鑰寫入 unit file、留在 shell history 中，或存放於任何 git repository。如果懷疑金鑰曾經外洩，請立即輪替。