這次把 OpenClaw 部署在一臺(tái) Ubuntu 服務(wù)器上，使用 Docker 運(yùn)行，再通過寶塔面板中的 Nginx 站點(diǎn)做反向代理，最后綁定域名，通過 HTTPS 訪問控制界面。

最終訪問鏈路如下：

瀏覽器
  ↓
https://你的https域名
  ↓
Nginx（寶塔站點(diǎn)）
  ↓
127.0.0.1:18789
  ↓
OpenClaw Gateway

這篇主要記錄整個(gè)部署過程，以及順手完成的幾項(xiàng)加固：Docker 端口只綁定本地、Nginx 白名單限制、UFW 拒絕端口直連。目標(biāo)很明確，不只是把服務(wù)跑起來，而是讓它以一個(gè)更適合長(zhǎng)期使用的方式對(duì)外提供訪問。

環(huán)境準(zhǔn)備與安裝初始化

服務(wù)器環(huán)境是 Ubuntu 24，已經(jīng)安裝寶塔面板，并啟用了 Nginx。OpenClaw 通過 Docker Compose 運(yùn)行，域名通過寶塔站點(diǎn)綁定并配置 SSL。

本次部署使用到的環(huán)境信息如下：

源碼獲取方式

由于服務(wù)器訪問 GitHub 不太穩(wěn)定，這次沒有直接拉倉(cāng)庫(kù)，而是先在本地下載壓縮包，再上傳到服務(wù)器。

壓縮包路徑如下：

/www/docker/openclaw/openclaw-main.zip

解壓后目錄如下：

/www/docker/openclaw/openclaw-main

進(jìn)入項(xiàng)目目錄后的常規(guī)操作：

cd /www/docker/openclaw/openclaw-main
ls
chmod +x docker-setup.sh
./docker-setup.sh

安裝腳本是交互式的，這次采用的是盡量輕量的初始化方式，關(guān)鍵選擇如下：

安裝過程本身并不復(fù)雜，真正需要處理的重點(diǎn)在于，如何把 OpenClaw 接到一個(gè)合理、安全的公網(wǎng)入口上。

OpenClaw 配置與 Docker 端口收口

OpenClaw 配置文件位置

有一個(gè)地方比較容易找錯(cuò)：OpenClaw 的實(shí)際配置文件并不在項(xiàng)目目錄里，而是在下面這個(gè)位置：

/root/.openclaw/openclaw.json

項(xiàng)目目錄下的內(nèi)容主要是運(yùn)行環(huán)境和 Compose 配置，真正控制 Gateway、認(rèn)證方式和 UI 來源校驗(yàn)的，是這個(gè) openclaw.json。

本次用到的關(guān)鍵配置如下：

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token"
    },
    "controlUi": {
      "allowedOrigins": [
        "https://你的https域名",
        "http://你的https域名"
      ],
      "dangerouslyAllowHostHeaderOriginFallback": true
    }
  }
}

這里最重要的是兩個(gè)配置項(xiàng)：

• controlUi.allowedOrigins
• dangerouslyAllowHostHeaderOriginFallback

因?yàn)?OpenClaw 在非本地訪問場(chǎng)景下會(huì)做來源校驗(yàn)。如果你是通過域名訪問控制 UI，但沒有把域名加入允許來源列表，網(wǎng)關(guān)可能直接拒絕啟動(dòng)，或者前端能打開但后端無法連接。

所以只要不是在本機(jī) localhost 上使用，而是通過域名反代訪問，這段配置基本都需要處理。

修改 Docker Compose 端口綁定

OpenClaw 默認(rèn)的 Compose 配置，會(huì)把 18789 和 18790 直接映射到公網(wǎng)。

默認(rèn)寫法如下：

ports:
  - "${OPENCLAW_GATEWAY_PORT:-18789}:18789"
  - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"

這種方式在測(cè)試階段沒有問題，但如果直接用于公網(wǎng)服務(wù)器，就意味著外部可以通過 服務(wù)器IP:18789 直接訪問 Gateway。

更合理的做法，是只讓 Docker 端口綁定到本地回環(huán)地址，讓外部流量統(tǒng)一從 Nginx 入口進(jìn)入。

修改后如下：

ports:
  - "127.0.0.1:${OPENCLAW_GATEWAY_PORT:-18789}:18789"
  - "127.0.0.1:${OPENCLAW_BRIDGE_PORT:-18790}:18790"

這樣改完以后，18789 和 18790 只允許本機(jī)訪問，公網(wǎng)無法直接連接。

實(shí)際修改命令如下：

cd /www/docker/openclaw/openclaw-main
cp docker-compose.yml docker-compose.yml.bak
sed -i 's#- "${OPENCLAW_GATEWAY_PORT:-18789}:18789"#- "127.0.0.1:${OPENCLAW_GATEWAY_PORT:-18789}:18789"#' docker-compose.yml
sed -i 's#- "${OPENCLAW_BRIDGE_PORT:-18790}:18790"#- "127.0.0.1:${OPENCLAW_BRIDGE_PORT:-18790}:18790"#' docker-compose.yml

修改完成后重啟容器：

docker compose down
docker compose up -d

這一步非常關(guān)鍵。因?yàn)槿绻幌劝?Docker 端口收口，后面即使配置了域名和 Nginx 反向代理，Gateway 實(shí)際上仍然是對(duì)公網(wǎng)暴露的。那時(shí) Nginx 只是“增加了一層入口”，不是“唯一入口”。

寶塔反向代理與訪問入口配置

這次使用的是寶塔面板，所以站點(diǎn)直接在寶塔里創(chuàng)建。

需要注意的是，站點(diǎn)目錄本身并不是重點(diǎn)。它不會(huì)直接渲染 OpenClaw 頁(yè)面，更像是一個(gè) Nginx 入口，用于完成三件事：

1. 綁定域名
2. 配置 HTTPS 證書
3. 反向代理到本機(jī) OpenClaw Gateway

站點(diǎn)目錄給一個(gè)普通路徑即可，例如：

/www/wwwroot/你的https域名

最終使用的核心 Nginx 配置如下：

location / {
    allow 127.0.0.1;
    deny all;
    proxy_pass http://127.0.0.1:18789;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400;
    proxy_send_timeout 86400;
    proxy_connect_timeout 60s;
    proxy_buffering off;
    proxy_request_buffering off;
}

這段配置主要完成了三件事。

首先是 IP 白名單控制，只允許服務(wù)器本機(jī)和指定公網(wǎng) IP 訪問，其它請(qǐng)求直接返回 403。
其次是補(bǔ)齊 WebSocket 所需代理頭，因?yàn)?OpenClaw 控制界面依賴 WebSocket 與后端通信。
最后才是將流量轉(zhuǎn)發(fā)到 127.0.0.1:18789。

修改完成后，先檢查配置：

nginx -t

確認(rèn)沒有問題后再重載：

nginx -s reload

安全加固與訪問控制

雖然前面已經(jīng)把 Docker 端口綁定到了 127.0.0.1，理論上公網(wǎng)已經(jīng)無法直接訪問 18789 和 18790，但這里我還是補(bǔ)了一層 UFW。

執(zhí)行規(guī)則如下：

ufw deny 18789
ufw deny 18790
ufw enable

這樣做的目的就是多一層保險(xiǎn)。即使后續(xù)某次改動(dòng)誤把 Docker 端口重新暴露出來，防火墻層面仍然可以攔住這兩個(gè)端口，避免被直接訪問。

對(duì)外開放端口建議只保留：

如果服務(wù)器在騰訊云、阿里云等云平臺(tái)上，安全組也建議同步關(guān)閉 18789 和 18790，只保留 22、80、443。

OpenClaw 的認(rèn)證機(jī)制

OpenClaw 默認(rèn)并不是傳統(tǒng)的賬號(hào)密碼登錄系統(tǒng)，而是采用 Gateway Token 模式。

也就是說，用戶可以看到前端頁(yè)面，但如果沒有正確的 Token，就無法真正連接后端。這時(shí)前端通常會(huì)提示：

unauthorized: gateway token missing

Token 存放在：

/root/.openclaw/openclaw.json

結(jié)構(gòu)大概如下：

"auth": {
  "mode": "token",
  "token": "xxxxxxxxxxxxxxxx"
}

這意味著它的訪問控制實(shí)際上分成兩層：

第一層是外層訪問控制，也就是能不能先打開這個(gè)頁(yè)面。這部分由 Nginx 白名單、域名入口和 HTTPS 決定。
第二層是內(nèi)部操作控制，也就是能不能真正控制 Agent。這部分由 Gateway Token 決定。

所以這次的思路很簡(jiǎn)單，外層用 Nginx 白名單限制訪問范圍， 內(nèi)層保留 OpenClaw 自己的 Gateway Token 作為實(shí)際控制權(quán)限。

如果后續(xù)還想進(jìn)一步強(qiáng)化，也可以在 Nginx 層再加 BasicAuth，讓瀏覽器先彈賬號(hào)密碼框。

當(dāng)前這套結(jié)構(gòu)的最終效果

到這里，這次部署的整體安全邊界就比較清楚了。

當(dāng)前已經(jīng)完成的控制如下：

最終訪問表現(xiàn)應(yīng)該如下：

到這一步，至少入口是統(tǒng)一的，權(quán)限是分層的，公網(wǎng)也沒有留下多余暴露面。

問題排查、運(yùn)維命令與后續(xù)優(yōu)化

先看 DNS，再查服務(wù)

這次排查過程中，還有一個(gè)很典型的問題。

一開始域名訪問不上，最先懷疑的是 Docker、Nginx 或者 OpenClaw 配置本身，結(jié)果最后發(fā)現(xiàn)問題根本不在服務(wù)層，而是在 DNS。

你的https域名 這個(gè)子域名，必須先在 DNS 控制臺(tái)中添加 A 記錄，例如：

只有解析生效之后，請(qǐng)求才會(huì)真正打到當(dāng)前服務(wù)器。

可以通過以下命令驗(yàn)證：

ping -c 2 你的https域名
curl -I http://你的https域名
curl -Ik https://你的https域名

如果 DNS 尚未生效，通常看到的報(bào)錯(cuò)會(huì)是：

Could not resolve host
Name or service not known

所以如果遇到域名無法訪問的問題，建議先確認(rèn) DNS 解析是否正確，再去檢查 Docker、Nginx 或 OpenClaw 本身。

常用運(yùn)維命令整理

下面把部署和排查時(shí)比較常用的命令一起記下來，后面復(fù)用會(huì)比較方便。

查看容器狀態(tài)：

cd /www/docker/openclaw/openclaw-main
docker ps
docker compose ps

查看網(wǎng)關(guān)日志：

docker logs --tail 100 openclaw-main-openclaw-gateway-1

重啟 OpenClaw：

cd /www/docker/openclaw/openclaw-main
docker compose down
docker compose up -d

檢查 Nginx 配置：

nginx -t
nginx -s reload

檢查 80 和 443 是否監(jiān)聽：

ss -lntp | grep -E ':80|:443'

檢查 OpenClaw 本機(jī)端口：

curl -I http://127.0.0.1:18789
curl -I http://127.0.0.1:18789/__openclaw__/canvas/

檢查 Nginx 到 OpenClaw 的反代鏈路：

curl -I http://127.0.0.1 -H "Host: 你的https域名"
curl -Ik https://127.0.0.1 -H "Host: 你的https域名"

這些命令都比較基礎(chǔ)，但在排查時(shí)很高頻。尤其是本機(jī)端口和反代鏈路測(cè)試，通常能很快判斷問題到底出在 OpenClaw、Docker、Nginx，還是域名解析層。

后續(xù)還能繼續(xù)增強(qiáng)的方向

目前這套結(jié)構(gòu)已經(jīng)可以穩(wěn)定使用，但如果后續(xù)想繼續(xù)往更完整的生產(chǎn)環(huán)境演進(jìn)，還可以繼續(xù)補(bǔ)幾項(xiàng)：

這些都不是這次部署的必需項(xiàng)，但如果后面要從“自己用”逐步走向“長(zhǎng)期用”或者“多人用”，基本都會(huì)慢慢補(bǔ)上。

總結(jié)

這次部署完成后，OpenClaw 已經(jīng)可以通過 HTTPS 域名正常訪問，Gateway 端口也不再直接暴露到公網(wǎng)。

目前這套結(jié)構(gòu)的核心有三點(diǎn)：

• 域名作為統(tǒng)一入口
• Docker 端口只綁定本地
• Nginx 白名單和 Gateway Token 形成雙層限制

對(duì)個(gè)人長(zhǎng)期使用來說，這樣的結(jié)構(gòu)已經(jīng)比較穩(wěn)，也方便后續(xù)繼續(xù)疊加認(rèn)證或訪問控制。

以上就是OpenClaw在Ubuntu服務(wù)器上的完整部署流程的詳細(xì)內(nèi)容，更多關(guān)于OpenClaw在Ubuntu上的部署的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論