OpenRouter 老是逾時？Clash 分流 API 網域與節點實測步驟

為什麼 OpenRouter 在代理環境裡常變成「逾時」？

許多開發者導入 OpenRouter，是為了用單一金鑰與統一端點呼叫多家模型供應商，省去在多個雲端帳號之間切換設定的摩擦。當您把這條鏈路放在本機或公司網路，並搭配 Clash／Mihomo 做規則分流時，論壇與 Issue 裡最常見的描述往往不是「完全連不上 openrouter.ai」，而是客戶端報告讀取逾時、TLS 握手停在某個百分比、或 SSE／chunked 回應斷在半途。

這類現象多半不是 OpenRouter「整站掛掉」，而是部分請求走了錯誤的策略路徑：例如 API 子網域命中 DIRECT、與網頁控制台不同出口、或長連線在 url-test 輪替節點時被硬切斷。Clash 能做的是把 openrouter.ai 相關流量變成可排序、可觀測、可回滾的規則與策略群組，讓您先用日誌確認「命中了誰」，再談換訂閱或調模型路由參數。

若您仍在匯入訂閱與核對節點顯示名稱，建議先完成 訂閱匯入教學，再回到本文微調規則，避免策略群組引用到訂閱裡不存在的代理名稱。

和 Cursor 專文有什麼不同？

本站另有一篇 Cursor IDE 分流專文，偏重編輯器本體：擴充功能市集、Electron 更新 CDN、以及 Cursor 內建 AI 請求的主機集合。那條鏈路與「應用程式直接呼叫 OpenRouter 的 HTTPS API」不完全重疊。

本篇只聚焦 OpenRouter 公開文件與常見客戶端所指向的 openrouter.ai 網域族，以及如何在 mode: rule 下讓儀表板、金鑰管理與 /api/... 請求穩定落在同一策略群組。若您同時使用 Cursor 與 OpenRouter，兩篇文章應並讀而非互相替代：日誌裡出現的主機名才是唯一真相來源。

應該分流哪些主機？

下列分類是規則設計用的心智地圖，不是保證永不變更的官方清單。聚合平臺會調整閘道、實驗性子網域與靜態資源位址，最可靠的補強方式仍是同時開啟應用程式日誌、HTTP 除錯輸出與 Clash 連線紀錄，找出仍落在直連、或被寬鬆規則提前帶走的主機名，再往回補 DOMAIN 或 DOMAIN-SUFFIX。

核心 API 與網站

• 網域後綴：多數官方範例與 REST 客戶端會指向 openrouter.ai；使用 DOMAIN-SUFFIX,openrouter.ai,OPENROUTER_PROXY 通常可一併覆蓋 api.openrouter.ai、www.openrouter.ai 等子網域（實際仍以日誌為準）。
• 網頁與文件：閱讀文件、登入儀表板與除錯瀏覽器行為時，請確認這些請求與 API 呼叫沒有因規則順序分裂到不同出口，否則可能出現「網頁顯示正常、同一帳號的 API 金鑰請求卻被風控或限速」的錯位感。

帳務、身分與第三方嵌入

當您開啟帳單、付款或第三方登入時，瀏覽器可能另載入金流、OAuth 或分析網域。這些主機不一定應該與 OPENROUTER_PROXY 捆綁；較安全的做法是先看日誌，再決定要否為某個付款閘道獨立建群組，避免過大的 DOMAIN-KEYWORD 規則誤傷無關流量。處理原則可對照 Perplexity 分流文 對 CDN 與子網域的補法。

策略群組 vs. OpenRouter「模型路由」

OpenRouter 允許在請求裡指定模型名稱、供應商偏好與備援排序，這屬於應用層的模型路由。Clash 的 proxy-groups 則是傳輸層的出口選擇：決定這條 TCP／TLS 連線從哪個節點離開您的電腦。

兩者常見的混淆點是：以為在 YAML 裡多開幾個群組就等於「自動幫我選最便宜模型」。實務上，您應先把 openrouter.ai 的流量穩定導向可信出口，再在應用程式裡調整模型清單與逾時秒數；若出口頻繁跳動，再完美的模型路由設定也會被連線重設打斷。

規則順序：為什麼「加了 DOMAIN-SUFFIX 仍像沒加」？

在 mode: rule 下，rules: 由上而下比對，命中即停。因此 OpenRouter 相關規則必須出現在會提早結束的寬鬆規則（含第三方 RULE-SET）之前，否則您以為寫進去的 DOMAIN-SUFFIX 其實從未輪到。

整體分流哲學可與 規則分流深度文一起讀：該文說明 GEOIP、rule-providers 與骨架排序；本篇把「越具體越靠前」收斂到 openrouter.ai。若您使用 TUN 模式，請分開驗證「流量有沒有進核心」與「進核心後由哪條規則命中」，避免跨層除錯。

可照抄的規則清單骨架（請以日誌補齊）

下列條目為教學用骨架，請視環境增刪。優先使用精準的 DOMAIN 或 DOMAIN-SUFFIX。

• DOMAIN-SUFFIX,openrouter.ai,OPENROUTER_PROXY
• 可選（若日誌出現且與主站分流一致）：DOMAIN,api.openrouter.ai,OPENROUTER_PROXY

若您使用第三方規則集，請先確認其中是否已含上述網域；重複規則通常無害，但順序與來源衝突會讓除錯變困難。建議在客戶端日誌中確認實際命中來源，再決定要覆寫或關閉某段訂閱規則。

從逾時反查：TLS 與 DNS 要先排除什麼？

當錯誤訊息停在 TLS 或證書驗證附近，請先確認同一主機名在 Clash 日誌裡是否始終走同一策略，而不是一次走代理、一次直連。分裂路徑可能導致客戶端快取與實際連線不一致，體感像「偶發逾時」。

DNS 方面，啟用 enhanced-mode: fake-ip 時，規則匹配與應用程式實際解析路徑可能出現落差。若系統或瀏覽器另啟安全 DNS／DoH 繞過本機，也可能讓少數請求躲過 Clash 的規則決策。處理原則與其他 AI API 分流文相同：把 DNS 決策與規則設計放在同一個心智模型裡，必要時暫時關閉 DoH 做 A／B 測試。

節點選擇：延遲低不等於適合長請求

OpenRouter 的聊天補全與串流回應常牽涉較長的單次請求時間。若節點在自動測速群組裡頻繁切換，體感會像「回答斷在半途」或「客戶端讀取逾時」。較穩的做法是：在 OPENROUTER_PROXY 內先放 select，手動固定單一節點做對照；確認穩定後，再考慮用放寬間隔的 url-test 做備援。

若節點會輪換出口位址，遠端也可能視為環境跳動而觸發額外驗證。此時比起盲目堆規則，不如暫時固定單一節點做 A／B 測試；確認穩定後再恢復自動測速。

YAML 範例：插入位置與命名

下列骨架示範在寬鬆 RULE-SET、GEOIP 與 MATCH 之前插入 OpenRouter 規則。節點顯示名稱請替換為您訂閱中的真實值，勿未審核即複製為生產設定：

YAMLproxy-groups:
  - name: "OPENROUTER_PROXY"
    type: select
    proxies:
      - "OR_AUTO"
      - "Your-Stable-Node-A"
      - "Your-Stable-Node-B"
      - DIRECT
  - name: "OR_AUTO"
    type: url-test
    proxies:
      # Inject real proxy names from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # OpenRouter (place BEFORE broad RULE-SET / MATCH)
  - DOMAIN-SUFFIX,openrouter.ai,OPENROUTER_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

重點仍是：任何會提前結束比對的寬鬆集合若放在上述片段之前，您新增的規則可能永遠輪不到。若遇此情況，請改在訂閱合併後的「自訂規則區」插入，或調整 rule-providers 的優先級與插入點（視您使用的前端而定）。

驗證順序：建議照這個順序做

1. 確認模式：客戶端為 Rule，且系統代理或 TUN 已按平台正確授權。
2. 開日誌：用最小請求（例如短提示詞）重現逾時，記錄 Clash 對 openrouter.ai 的命中策略與實際節點。
3. 固定節點對照：在 OPENROUTER_PROXY 內改為單一節點，排除自動測速誤判。
4. 檢查寬鬆規則：暫時停用可疑 RULE-SET 或將 OpenRouter 規則移到更前段，確認命中是否恢復預期。
5. 分開測網頁與 API：儀表板能開不代表 CLI／後端程式已走同一出口；分別觀察日誌。
6. 抽查 TLS 與 DNS：對照是否分裂路徑、或本機安全軟體攔截 HTTPS；必要時暫關瀏覽器 DoH 做對照。

常見踩坑

• 過大的關鍵字規則：寬鬆的 DOMAIN-KEYWORD 可能帶走不相關流量，除錯與風險都會放大。
• 只配主站、忘記實際 API 主機：少數客戶端或重新導向可能指向不同子網域，需以日誌補齊。
• 以為 MATCH 會智慧選路：MATCH 只是兜底命中，並不會自動理解 OpenRouter。
• 忽略第三方規則集插入點：檔案底部新增的規則，若載入順序上仍在巨大規則集之後，可能形同沒寫。
• 把問題誤判成節點壞掉：實際為 DNS、長連線被切換，或子網域直連分裂；先對照日誌再換訂閱。

結語

OpenRouter 作為多模型聚合與統一端點的代表，在 2026 年仍會長期出現在開發者工具鏈裡；在代理環境下，與其只調客戶端逾時秒數，不如先把 openrouter.ai 相關流量收斂到可觀測的策略路徑，並用固定節點與日誌驗證長連線行為。當 DOMAIN-SUFFIX 置前、策略群組與 DNS 設定彼此呼應時，API 逾時與串流中斷通常會顯著減少。

相較於零散工具拼裝，在同一套規則語意下維護桌面與行動用戶端，長期成本通常更低；若您尚未安裝合適版本，建議先從本站下載頁取得對應平台用戶端，並搭配 教學文件完成基礎設定。