OpenRouter API 總逾時？Clash 分流 OpenRouter 與模型閘道網域實測（2026）

1. 為什麼 OpenRouter 特別需要閘道級分流

一般使用者在瀏覽器裡開 OpenRouter 控制台，看起來「只要會連上網就好」；但開發者工作階段通常同時存在網頁登入與 cookie、REST 或串流 API、以及套件管理或建置流程（例如從 npm拉 CLI、從 GitHub拉範例或鎖檔）。當訂閱規則把某些海外網域一概丟進「自動選最快」的群組，或終端機沒有繼承與瀏覽器相同的系統代理時，你會得到一種很典型的假性矛盾：主控台列表能刷新，程式範本裡同一金鑰卻在二秒、十秒、三十秒後才回錯誤碼，或直接顯示 ETIMEDOUT。

Clash能做的，是把這些連線對齊到可預期的出站：讓 openrouter.ai與你在日誌裡看到的實際子網域，與 CLI、IDE、瀏覽器共用同一策略組；並透過日誌了解是規則沒命中、解析走錯上游，還是單純節點品質問題。先把期待放在正確層級：若供應商端返回 5xx或明確的額度錯誤，調代理不會變成通靈術；但若連線根本沒進隧道，或每秒換一個出口，調規則通常立刻有感。

與只談「ChatGPT 網頁能不能開」類文章不同，OpenRouter 場景更靠近模型閘道與金鑰式 API：讀者搜尋 OpenRouter、API 逾時時，多半已經在程式側重現問題。這也是為什麼本篇會反覆提開發者代理與終端機一致性，而不是只列一張靜態網域表就結束。

2. 常見現象：API 逾時、控制台載入失敗與路徑割裂

你可能遇過：以 curl或 SDK 呼叫時，TLS 握手拖很久後才失敗；或在網頁上按「試跑」可以，但 CI 或本機腳本同樣參數卻固定逾時。另一種常見樣態是靜態資源或第三方驗證腳本被某條過寬規則導去直連，導致主文件走代理、子請求卻從 ISP 出去，瀏覽器主控台出現單點紅字，整頁看起來像「一直載入」。這類問題與 HTTP/3（QUIC）走 UDP、而 TCP 代理路徑不一致時也有關：表現為間歇性失敗，而不是穩定全紅。

排查時請維持單一變因：同一輪實驗只調整規則順序、或只關閉 QUIC／瀏覽器 DoH 做對照，並在 mihomo 日誌裡記下主機名與策略組。若你有併用 MCP 或大量從套件庫拉工具，也可交叉閱讀 MCP 與 npm／GitHub一文，避免只修了閘道、另一條鏈路仍直連。

3. 建議覆蓋的網域與開發鏈依賴

實際子網域會隨產品迭代改變，唯一可靠來源仍是你本機連線日誌、瀏覽器 Network 面板、以及 SDK 的除錯輸出。下列清單是 2026 年實務上常見的起點，請以 DOMAIN-SUFFIX置於訂閱規則中「大範圍直連／國內」之前，並在發現新主機名時補列。

• OpenRouter 閘道本體：openrouter.ai，以及日誌中出現的 api.、ac.、static.、cdn.等子網域（請以你實測為準）。
• 身分與帳務週邊：若控制台會跳轉至通用登入或帳單供應商，請把該次連線出現的完整主機名一併納入同一策略組，避免「前半段代理、驗證回呼直連」。
• 套件與原始碼：常用 registry.npmjs.org、github.com與 objects.githubusercontent.com（是否全導代理視你公司政策；實務上 IDE 與 CLI 常需與閘道同一出口才穩）。
• 若你同時直連上游模型商：例如 OpenAI、Anthropic，請另外對照站內 ChatGPT 分流或 Claude／Anthropic專文，避免同一專案混用兩種地理或不一致的 IP 形象。

4. mihomo 規則與策略組範例

以下片段示範如何為模型閘道／開發鏈建立獨立策略組，並在 rules前段加入可讀條目。請將策略組名稱與節點名稱替換為你環境中的實際字串；註解使用英文以利版本控管。

proxy-groups:
  - name: 🧭 Model Gateway
    type: select
    proxies:
      - LOW-LATENCY-A
      - LOW-LATENCY-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,openrouter.ai,🧭 Model Gateway
  - DOMAIN-SUFFIX,registry.npmjs.org,🧭 Model Gateway
  # Add GitHub hosts only if your logs prove IDE/CLI pulls need the same exit
  - DOMAIN-SUFFIX,github.com,🧭 Model Gateway
  - DOMAIN-SUFFIX,objects.githubusercontent.com,🧭 Model Gateway
  # If you call upstreams directly alongside OpenRouter, align with their rules too
  # ... GEOIP DIRECT and MATCH below

5. DNS、Fake-IP 與終端機代理對齊

當你啟用 Fake-IP時，最惱人的症狀之一是「解析看起來正確、規則卻像沒命中」。請對照 Fake-IP 與 redir-host專文，確認 dns區塊、fake-ip-filter與 rules順序是一致的同一套故事，而不是各自改一點。若瀏覽器另外啟用「安全 DNS」（DoH）直連公共解析器，也會讓你在 Clash 日誌裡看不到預期查詢；與系統層校準可延伸閱讀 Windows／Chrome／Edge 與系統代理對照篇。

終端機方面，請確認 HTTP_PROXY、HTTPS_PROXY是否指向與圖形客戶端相同的 mixed-port，且 NO_PROXY沒有不小心把 openrouter.ai排除；若你仰賴 TUN統一承載行程，請確認相關行程確實進入 TUN 而不是繞過。若仍卡住，可對照 DeepSeek API 與 DNS一文的「工具鏈分裂」敘事：症狀不同，但拆法類似。

最後，若你也使用 DoH 上游與跨境策略組綁定，建議完整閱讀一次 Clash Meta DoH 與 fake-ip 聯調：許多「偶發 API 逾時」其實是解析路徑在兩個上游之間搖擺，而不是節點真的炸了。

6. 長連線、串流回應與 url-test 取捨

OpenRouter 與多家供應商支援串流式回應：連線會持續開著數秒到數分鐘。若策略組背後的 url-test在這段期間因為延遲變化而切出口，用戶端常看到中斷後重試或直接視為逾時。實務上會建議：長任務用固定節點，並在客戶端設定合理的讀取逾時與指數反向退避；同時確保沒有其他本機防火牆或公司代理在中途攔掉 WebSocket／chunked路徑。

若你發現只有大型回應失敗、短提示詞正常，也可以對照 CDN 與 TLS 指紋相關討論；但在進入這類深水區之前，仍應先用日誌排除「規則沒命中」這種低成本錯因。

7. 驗證清單與延伸閱讀

完成設定後，建議依序確認：①openrouter.ai與日誌中其它閘道子域是否命中 🧭 Model Gateway（或你自訂的同名策略組）；②瀏覽器、IDE、終端機是否共用同一隧道或代理埠；③DNS 查詢是否繞過 Clash 本機監聽；④若併用多模型供應商，各供應商規則是否彼此一致而不互相打架。

常見誤區包括：只看延遲測試、不看規則命中；把整包海外流量粗暴導向同一「自動」群組；以及把帳號問題誤判成純網路問題。若你需要重建基底設定，可先走 訂閱匯入教學確保核心與 GUI 同步，再合併本篇片段。

8. 常見問題

OpenRouter 已走代理，為什麼還會 API 逾時？常見原因是只有瀏覽器吃系統代理，終端機或執行 CI 的執行緒仍直連；或是規則順序讓某個子網域落回直連／另一策略組，導致同一金鑰、兩條路徑。請以連線日誌逐筆對照主機名與出口，而不是只看延遲測試數字或節點排行榜。

需要把上游模型商網域也通通寫進規則嗎？不一定。若應用程式統一透過 OpenRouter閘道出站，優先鎖定 openrouter.ai與日誌實測出現的主機名通常就夠用。若你同時在程式裡直連 OpenAI、Anthropic 或其他供應商，請與站內對應專文的分流策略對齊同一地理與固定節點邏輯，避免同一專案混兩種 IP 形象觸發風控。

url-test 自動選節點會影響長連線嗎？會。頻繁切換出口可能讓長連線或串流式回應重試。需要穩定寫入或大量產文時，可改手動固定節點，或調整 url-test／fallback 的探測間隔，必要時參考 策略組教學避免「為了快而頻繁換路」。