把閘道當成「OpenAI 相容 HTTP 面」時，最常翻車的是同一組憑證在 HTTP 與 CLI 走了不同車道：curl 打 /v1/models 正常，/v1/chat/completions 卻 401；或 CLI 已連上 RPC，HTTP 仍缺標頭。2026.5.x 起請把變更單寫成「路徑 × 標頭 × 是否需要 RPC」三欄，再用 openclaw gateway status --require-rpc 與最小 curl 交叉驗收。鑑權與 loopback 錯位可對照 Gateway loopback／token 與 doctor／status／probe 教學；Webhook 場景的 401／逾時分車道可延伸 閘道 Webhook 與 GitHub 整合的排錯節奏。
一、/v1/models 與 /v1/chat/completions：先對照 CLI 通道
GET /v1/models 多半走輕量列舉，用來驗證 base URL、TLS 與讀取型鑑權是否對齊；POST /v1/chat/completions 才會觸發完整推理與外掛鏈路，也更容易暴露上游逾時或串流連線被中間設備掐斷。實務上請固定同一 Authorization: Bearer …（或專案文件指定的等效標頭），先對 models 拿到 200，再切 chat；若 models 已失敗，不要急著開串流，先把 bind、SNI 與閘道對外的 OPENCLAW_* 與 plist 兩份環境對 digest。CLI 若顯示已註冊模型而 HTTP 列表為空，多半是快取或不同 workspace，請用 status 對齊工作目錄與設定載入順序。
二、鑑權標頭：Bearer、自訂標頭與閘道設定同一平面
相容層通常期待 Authorization: Bearer <token>；若你改用自訂 API key 標頭，請確認閘道與反向代理沒有剝標頭（常見於 Nginx proxy_set_header 遺漏）。401 的可複現套路：故意少送 Bearer、送過期 token、或在兩個終端機各匯出一組不同的 OPENCLAW_GATEWAY_TOKEN，觀察閘道日誌是否出現同一來源 IP、不同憑證版本交錯。修復時一次只改一維：先凍結輪替，再對齊標頭與 status 顯示的 auth 模式，最後才動 listen。
三、openclaw gateway status --require-rpc 交叉驗收
--require-rpc 的用途是把「只看本機行程綠燈」升級成控制面 RPC 也必須可用：適合在升級 2026.5.x 後第一次通電、或遠端 SSH 除錯時當關卡。建議順序：1）本機 doctor 無阻塞；2）status（含 require-rpc）與變更單上的 channel／digest 一致；3）對 /v1/models 與非串流 chat 各打一槍；4）最後才開 stream: true。任一步失敗都先回到上一步，避免把「RPC 暫時不可達」誤判成 token 壞掉。
四、串流逾時：可複現與觀測點
串流連線常見症狀是第一包有資料、之後卡住，或客戶端報讀逾時。可複現步驟：用最小 prompt 開串流，刻意拉長 max_tokens，同時在閘道主機觀察 CPU／記憶體與上游 RTT；再把負載切到非串流對照。若只有串流失效，優先檢查中介代理的讀逾時、HTTP/2 閒置逾時、以及客戶端是否正確處理 chunked。2026.5.x 維運上請把「串流逾時閾值」寫進 Runbook，並與監看 probe 週期解耦，避免探針把慢推理當成 crash 而觸發重啟風暴。
五、401 對照表與分車道收斂
將 401 分三類記錄：A）models 與 chat 同時 401，偏向全域 token／閘道 auth 模式；B）僅 chat 401，偏向路由或上游供應商拒絕；C）間歇 401，偏向輪替窗口重疊或雙行程各持一份設定。每一類附上對應的 curl -v 片段、status 輸出摘要與時間戳，與前文 Webhook 教學同一稽核欄位對齊即可。收斂時禁止同時改 token、反代與上游模型別名，避免錯位疊加。
六、遠端高記憶體 Mac 常駐範例（約 64GB）
範例：高記憶體遠端 Mac 以 launchd 常駐閘道，本機另跑長上下文 Agent 與索引外掛。HTTP 面對外公網 TLS，RPC 與 status 僅走 tailnet；大型推理尖峰時，請將 /v1/models 探測與管理 RPC降頻，並監看 swap 與閘道延遲 P95，避免監看誤判。升級 2026.5.x 後務必跑一次「require-rpc + models + 短 chat + 串流 chat」四段式驗收，再開放給多客戶端。外溢期間不要同步修改鑑權與 listen，以免與 loopback 文章所述錯位疊加。
在 Mac mini 上把 HTTP 閘道與常駐跑穩
本文的 curl 驗收、launchd 常駐與 SSH 遠端除錯，在 macOS 上與 Homebrew、原生 TLS 工具鏈銜接最順；Apple Silicon 統一記憶體有利同時承載閘道、中大型外掛工作集與長上下文推理，降低「換頁尖峰」造成的假逾時。Gatekeeper、SIP、FileVault 則收斂無人值守面。Mac mini M4 待機約 4W、體積小、噪音低，長期電費與機房熱負載更可控。若要把 OpenClaw 相容 HTTP 閘道跑在穩定且性價比高的硬體上，Mac mini M4 是值得優先評估的起點；雲端專屬節點與區域選型見 Macstripe 首頁。想把本文流程跑在更流暢的近端或雲上 Mac，現在即可從首頁了解方案並選型。
