前言：先分清楚是哪一段連線出問題
OpenClaw 模型連不上，不一定代表模型服務故障。從 OpenClaw 發出請求，到模型供應商回應，中間可能經過應用程式設定、作業系統代理、Clash 規則、代理節點、DNS 解析，以及供應商 API 等多個環節。只要其中一段沒有接上，就可能看到啟動逾時、請求失敗、連線重設或認證錯誤。
排查時先確認 OpenClaw 實際使用的模型供應商、API 網域與連接埠，再檢查該網域是否交由 Clash 代理。不同供應商的 API 網域並不相同；即使使用同一個模型名稱，也可能因為自訂 API Base URL、相容介面或企業閘道而走向不同主機。因此，不建議只複製一份網路上流傳的規則清單，而應以自己的 OpenClaw 設定與連線紀錄為準。
排查順序
先驗證 API 金鑰與供應商服務，再確認 Clash 節點可用、代理連接埠正確，最後檢查 OpenClaw 流量是否命中預期的分流規則。
1先定位錯誤：網路、代理還是 API 設定
請先查看 OpenClaw 的錯誤訊息與執行紀錄，將問題大致分類。逾時或連線重設通常與網路路徑、DNS 或節點品質有關；HTTP 401 常見原因是 API 金鑰錯誤、缺少授權標頭或讀取了舊環境變數；HTTP 403 可能涉及帳戶權限、服務地區或供應商政策；HTTP 404 則應優先核對 API Base URL、路徑及模型識別名稱。HTTP 429 通常表示速率或額度限制，單純切換 Clash 節點未必能解決。
| 觀察到的狀況 | 優先檢查項目 | 建議處理方式 |
|---|---|---|
| 一直等待，最後逾時 | 節點連通性、代理連接埠、DNS、API 網域規則 | 先用瀏覽器或命令列測試代理，再查看 Clash 連線紀錄 |
| 401 或授權失敗 | 金鑰是否有效、環境變數是否載入、供應商是否匹配 | 確認金鑰來源與服務商設定，不要把金鑰貼入公開紀錄 |
| 404 或找不到模型 | API Base URL、API 路徑、模型名稱 | 對照供應商文件，確認 OpenClaw 使用的端點格式 |
| 429 或回應中提示額度不足 | 帳戶額度、速率限制、並行請求數 | 查看供應商控制台與 OpenClaw 重試設定 |
在 Clash Verge 中先確認訂閱已更新、代理核心已啟動，並在「代理」頁面手動選擇一個可用節點。不要一開始就同時更改 DNS、TUN、規則與節點；一次只調整一項，才能判斷哪個變更真正有效。若瀏覽器能開啟一般網站，也不代表 OpenClaw 的請求必然經過代理，因為命令列程式、背景服務或容器可能使用不同的網路環境。
小撇步
在 Clash Verge 的「連線」或日誌頁面觸發一次模型請求，搜尋供應商 API 網域。若完全沒有相應紀錄，先檢查 OpenClaw 是否使用系統代理、環境變數代理或獨立容器網路。
2在 Clash Verge 設定代理與 API 分流
最容易維護的做法，是先沿用訂閱提供的策略組，再為 OpenClaw 的 API 網域加入明確規則。開始修改前，先備份目前使用的設定檔；若訂閱會定期更新，應優先使用 Clash Verge Rev 支援的覆寫或合併設定方式，避免直接改動每次更新都會被覆蓋的訂閱原檔。
找出 OpenClaw 實際連線的網域
查看 OpenClaw 的模型供應商設定，記下 API Base URL 的主機名稱。例如設定可能指向供應商官方 API、相容服務，或自訂閘道。只需使用主機網域撰寫規則，不要把完整 URL、查詢參數或帶有個人識別資訊的路徑直接放進規則。若設定使用多個網域，例如登入、模型 API 或檔案上傳服務，應分別確認各自用途，不要假設它們都由同一個主機提供。
加入規則並確認策略組名稱
以下是規則格式示例。請把網域替換成你實際使用的 API 主機，並將 AI-Proxy 改成設定檔中確實存在的代理策略組名稱。規則必須放在通用兜底規則（例如 MATCH）之前，否則前面的規則可能已先決定流量去向。
若供應商使用多個子網域，可視實際情況改用 DOMAIN-SUFFIX，例如 DOMAIN-SUFFIX,example.com,AI-Proxy。但這會涵蓋該主網域下的其他服務，範圍比單一 DOMAIN 更廣。若只需代理特定 API，優先採用精確網域規則；也不要把不存在的策略組名稱直接貼入設定，否則可能造成設定載入失敗。套用變更後，確認 Clash 顯示設定有效，再重新載入核心。
重要提醒
不要把 API 金鑰、完整請求標頭或含有機密資料的設定檔分享給他人。Clash 規則只負責決定流量走向，不能修復無效金鑰、供應商額度不足或 API 端點填寫錯誤。
3動手測試：讓 OpenClaw 流量經過 Clash
完成分流後，建議按以下步驟驗證，不要只憑瀏覽器能否開啟網站來判斷 OpenClaw 已連通。Clash Verge 的 HTTP 或混合代理連接埠常見預設值是 7890，但你的設定可能不同，請以「設定」頁面顯示的實際連接埠為準。
- 在 Clash Verge 確認核心正在執行，並記下 HTTP 代理連接埠。先手動選擇一個穩定節點，避免自動選擇組在測試期間更換出口。
- 將
api.example.com換成 OpenClaw 設定中的實際 API 主機，將7890換成你的代理連接埠，執行以下命令測試代理連線：
收到 HTTP 回應碼，即表示目前至少能連到該主機；回應 401、403 或 404 仍代表網路可能已通，但 API 認證或路徑需要另外檢查。若命令出現無法連線到代理伺服器，請核對 Clash 是否啟動、代理連接埠是否正確，以及該連接埠是否只允許特定介面使用。
- 如果 OpenClaw 支援讀取環境變數代理，可在啟動程式的同一個終端機工作階段設定代理。不同安裝方式與版本的支援情況可能不同，請依 OpenClaw 文件確認：
- 在同一個工作階段啟動或重新啟動 OpenClaw，發出一次模型請求，同時查看 Clash 連線紀錄，確認 API 網域被送往預期的策略組與節點。
- 測試完成後，查看 OpenClaw 的回應碼與錯誤內容。若命令列測試成功、OpenClaw 仍逾時，問題通常在程式啟動環境、代理支援方式或容器網路，而不一定是 Clash 規則。
有些程式只讀取大寫的 HTTPS_PROXY，有些程式使用自己的代理欄位，也有程式不支援環境變數代理。變數必須在 OpenClaw 啟動前設定；若服務由系統服務管理器、排程工作或背景程序啟動，從一般終端機設定變數不會自動套用到該程序。設定後仍應重新啟動服務，並以 Clash 連線紀錄確認，而不是只看環境變數是否存在。
4仍無法連線時的進階排查
檢查 TUN 模式與容器網路
若 OpenClaw 不讀取系統代理或代理環境變數，可評估在 Clash Verge 啟用 TUN 模式，讓更多系統流量進入 Clash 處理。啟用前先確認核心支援、授權或管理員權限已就緒，並留意虛擬網卡、DNS 與其他 VPN 軟體可能互相衝突。TUN 模式不是解決所有問題的開關：若規則把 API 網域送往 DIRECT，或 DNS 將請求導向錯誤地址，仍需要修正規則或解析方式。
如果 OpenClaw 在 Docker 或其他容器中執行，容器內的 127.0.0.1 通常指向容器本身，不是執行 Clash 的主機。因此，容器設定代理時不能直接假設 127.0.0.1:7890 可用。應依作業系統與容器網路模式，設定容器可到達的主機位址，並確認 Clash 監聽介面與防火牆沒有阻擋連線。不要為了測試而將代理服務無限制暴露到公用網路。
核對 DNS、規則順序與日誌
若日誌顯示網域解析失敗，先確認 OpenClaw 所在環境能解析該 API 主機，再查看 Clash DNS 設定與 DNS 覆寫規則。若連線紀錄顯示請求命中 DIRECT，檢查自訂規則是否排在前置規則之後，或網域是否與實際端點不符；若顯示送往正確策略組但仍逾時，則可換一個節點比較，並確認供應商是否限制該地區或出口 IP。
每次只改一個項目並記錄結果，例如「更換節點後命令列有回應，但 OpenClaw 仍出現 401」，這樣便能把問題縮小到授權或應用程式設定。排查結束後，移除臨時測試用的代理變數與寬泛規則，保留必要的精確網域規則。若錯誤訊息包含金鑰、請求內容或使用者資料，分享日誌前務必先遮蔽。
快速判斷
命令列直連失敗、經 Clash 代理成功，通常表示代理路徑有效；命令列成功而 OpenClaw 失敗，優先檢查程式的代理設定、API Base URL 與啟動環境；兩者都失敗，則回頭檢查節點、DNS、供應商狀態或帳戶權限。
總結來說，OpenClaw 與 Clash 的配合重點不是盲目開啟全域代理，而是確認實際 API 網域、選擇可用節點、設定正確規則，並從 OpenClaw 所在的執行環境驗證連線。完成這些檢查後，即使問題仍存在，也能更清楚分辨是代理路徑、應用程式設定，還是模型供應商端的限制。