您已在小記憶體 Ubuntu/Debian VPS 上跑通 OpenClaw Gateway，但一旦啟用需要 Chromium 的瀏覽器能力，日誌就出現無顯示、找不到執行檔或沙箱相關錯誤。本文給要把 無圖形介面 Linux 當正式環境 Gateway 的工程師：先用七條清單拆 DISPLAY / Xvfb / browser.executablePath 的隱性假設，再用對照表收斂「虛擬幀緩衝對上實機顯示」的維運成本，最後提供 六步可重現 Runbook（安裝依賴、拉起 Xvfb、匯出環境、驗證設定、接入 systemd/Docker、最小驗收），並對齊站內 跨平台安裝、not ready 排錯、觀測篇 的分工。
官方文件常假設有顯示堆疊；正式環境更常見 headless VPS。以下七條把爭論從「裝 Chrome 就好」收斂成可簽核的風險表。
以為 Gateway 行程會自動繼承 shell 裡的 DISPLAY：systemd 若未寫 Environment=，瀏覽子程序仍可能落在空顯示上。
把 browser.executablePath 設成桌面發行版路徑：容器或最小映像路徑不同，症狀像 spawn ENOENT。
忽略字型與 ICU 依賴：無字型套件時，渲染可能靜默失敗或逾時，看起來像 Gateway「卡住」。
用 root 跑瀏覽器沙箱：Chromium 常以降級沙箱或拒絕啟動回應；應使用專用非特權使用者，並與 安全加固篇 的最小權限一致。
未把 Xvfb 與 Gateway 啟動順序寫死：競態下首次工具呼叫失敗、重試又「自癒」，難以穩定重現。
把瀏覽器記憶體與模型呼叫記憶體混在同一預算：小記憶體機器先 OOM 的很可能是 Chromium，而不是 LLM。
日誌只看 Gateway 不看子程序結束碼：瀏覽器閃退會在下游表現為工具逾時；需結合 openclaw logs 與系統 journal 對時間軸。
這些假設的共同根因，是把瀏覽器當成外掛，而不是 帶作業系統依賴鏈的執行環境。與 MCP 握手篇 分工：MCP 處理工具探索與工作階段；本文處理 瀏覽器執行檔＋顯示堆疊 的最小閉環。
若同時跑 Docker 正式環境 與裸機 systemd，請把「DISPLAY 與 Xvfb 由誰拉起」寫進拓撲圖，避免兩套編排搶同一顯示編號。
沒有銀彈：您選的是 可重現性 與 排錯表面積。
| 維度 | Xvfb + DISPLAY | 實機／VNC 顯示 | 僅 Chromium --headless（無 Xvfb） |
|---|---|---|---|
| 依賴面 | 需維護 Xvfb 程序、顯示編號、字型套件 | 需維護工作階段、解析度與人為介入窗口 | 依版本對 headless 策略，升級後行為可能漂移 |
| 可重現性 | 高：單元化 systemd 或 compose 可固定環境變數 | 中：受桌面工作階段與鎖定畫面影響 | 中至高：取決於發行版與沙箱組合 |
| 排錯訊號 | 清晰：DISPLAY、Xvfb 日誌、Chromium stderr | 複雜：GUI 狀態與權限彈窗 | 偶發：無 GPU 主機上 GPU/ANGLE 相關路徑更易踩坑 |
| 典型適用 | 小記憶體 VPS、只要擷圖／自動化類能力 | 強 GUI 或簽署彈窗類流程 | 工具鏈已驗證可在該版本裸跑 headless |
「可重現」在此的含義是：同一套 systemd 單元或 compose 檔，換一台乾淨 VPS 仍能穩定拉起 Xvfb + Gateway + 瀏覽器。
與 not ready 篇 聯動：若 Gateway 程序尚未穩定監聽，先不要疊加瀏覽器層排錯，否則日誌會互相污染。
下列順序強調「先顯示堆疊，再 Gateway，再工具」；指令以 Debian／Ubuntu 系為例，其他發行版請替換套件名稱。
安裝 Chromium 與字型依賴：apt install 選擇發行版提供的 chromium 或 google-chrome-stable，並補齊 fonts-noto 等常用字型套件。
安裝 Xvfb：確認 Xvfb :99 -screen 0 1920x1080x24 可手動啟動且無通訊端衝突。
匯出 DISPLAY：在執行 Gateway 的同一環境設定 DISPLAY=:99；systemd 使用 Environment=DISPLAY=:99，Docker 使用 environment 區塊。
寫入 browser.executablePath：以 which chromium 或套件安裝路徑對齊設定，變更後執行 openclaw doctor（或同等驗證）。
以 systemd 或 compose 固定啟動順序：Xvfb 先就緒再啟動 Gateway；為 Xvfb 加重啟策略與日誌落盤。
最小驗收：Gateway 健康後觸發一次僅開啟 about:blank 的瀏覽器工具呼叫，確認日誌無沙箱／顯示錯誤，再放行業務流量。
# 手动验证（维护窗）： Xvfb :99 -screen 0 1920x1080x24 & export DISPLAY=:99 chromium --no-sandbox --disable-dev-shm-usage --headless=new --dump-dom about:blank >/tmp/blank.html # 然后以相同 DISPLAY 启动/重启 Gateway（systemd 或 docker compose）
提示：--no-sandbox 僅供受限診斷環境；正式環境請回到非 root 使用者、最小權限與 networkPolicy 組合收斂暴露面。
與 觀測篇 對齊：把 Xvfb 與 Chromium 的 stderr 納入同一工單時間軸，避免「Gateway 綠但工具紅」被誤判為模型後端問題。
把下面這張表貼在 on-call 頻道，可減少無效標註。若錯誤已涉及 WebSocket 關閉碼，請改看 gateway closed(1000) 篇。
cannot open display：檢查 DISPLAY 與 Xvfb 是否存活。executablePath ENOENT：檢查路徑與容器內是否掛載同一二進位檔。zygote / sandbox：先確認非特權使用者與核心參數，再考慮暫時診斷開關。
注意：不要在正式環境長期保留寬鬆沙箱參數；診斷結束後應回滾設定並記錄變更單，滿足稽核要求。
Docker 場景下還要核對 /dev/shm 與共享記憶體大小：過小會導致 Chromium 異常結束，表現為工具間歇性失敗。
下列欄位用於二線對齊；外寄前請去識別。
/etc/os-release、uname -r，以及 Chromium 主版本號。ss -lxn | grep X11 或同等監聽檢查結果。dmesg 是否出現 OOM killer。僅把 Gateway 綁在隨時可能休眠的個人筆電上，顯示堆疊與網路都不穩定；純最小 VPS 又常被瀏覽器與模型並發頂到 OOM。若您需要長期上線、可合約化的 macOS 或獨佔算力承載 OpenClaw 與周邊工具鏈，獨佔遠端 Mac通常比「勉強用本機」更穩。相較自建零散機器，NodeMini 的 Mac mini 雲端租賃在固定 SSH、清晰磁碟檔位與可複製的節點畫像上更利於平台治理；規格與價格見 租賃價格說明，接入見 說明中心，OpenClaw 系列可從 部落格分類 進入。
瀏覽器層穩定後，建議把本次根因標籤寫進變更紀錄，避免下次升級 Chromium 時重複踩同一坑。
DISPLAY 是否指向正在監聽的 Xvfb；browser.executablePath 是否與實際二進位檔一致；systemd／Docker 是否把 DISPLAY 與字型套件注入 Gateway 程序。需要算力規劃見 算力訂購。
not ready 聚焦連接埠、記憶體、逾時與容器啟動順序；本文聚焦瀏覽子系統與顯示堆疊。若仍失敗，再對照 not ready 篇 與 closed(1000) 篇。
從 部落格 OpenClaw 分類進入安裝、Docker、systemd、安全、觀測與 MCP 篇；需要接入協助見 說明中心。