為什麼 Cursor、GitHub 與擴充功能常一起「逾時」？
許多開發者會把問題簡化成「AI 服務被封鎖」或「節點太慢」，但實務上更常見的是路由與解析不一致：Cursor IDE、GitHub、Visual Studio Code 擴充功能市集、套件 CDN、以及各家模型供應商的 API，往往分散在不同網域與雲端出口上。當你使用 Clash／Mihomo 時，只要其中一條連線被錯誤地直連、繞了不穩定的線路，或被另一條寬鬆規則提前命中，整體體感就會變成「什麼都連不上、什麼都在轉圈圈」。
另一個典型情境是全域代理搭配對 GitHub 類站點不友善的節點：下載延伸模組或大型語言模型資產時，長連線更容易觸發逾時；反之，若你習慣國內直連優先，則某些海外 API 可能被留在直連路徑上，導致金鑰驗證或串流失敗。解法不是單純開關「系統代理」，而是把開發者會用到的網域與行程拆出來，寫成清楚、可排序、可維護的分流規則。
若你對 rules 與訂閱合併仍不熟，建議先搭配站內使用文件把基礎架構跑通，再回到本文針對「AI 程式設計工具鏈」補上精準規則。
先把流量分桶：代理、直連與「不要動」
在動手寫規則前，建議先用紙筆或筆記軟體列出三類目標。第一類是明確需要穩定海外出口的：例如 GitHub 網頁與 API、Cursor 相關網域、部分雲端供應商的授權與下載端點、以及你實際使用的模型 API 存取網域。第二類是應該直連的：公司內網、區域性套件鏡像、或你已確認走代理反而更慢的本地服務。第三類是暫時不處理、交給底層 MATCH 或訂閱預設策略的：避免一開始就把規則表膨脹到難以除錯。
分桶完成後，請記住 Clash 系列核心的鐵則：規則由上而下匹配，先命中者優先。這代表「想把開發流量送進特定策略組」時，對應的 DOMAIN／DOMAIN-SUFFIX／RULE-SET 必須放在會誤傷它們的寬鬆規則之前。許多「我明明寫了代理，怎麼還是直連」的問題，其實是排序被訂閱內建規則或超大的 GEOIP 規則蓋過去。
若你會大量使用第三方網域清單，可延伸閱讀Rule Providers 進階指南，把長清單模組化，主設定檔只保留開發者相關的「精簡高優先規則」。
域名規則範例：GitHub、市集與常見 API
以下 YAML 片段僅為結構示意；實際網域會隨產品更新而變動，請務必以你電腦上失敗請求的實際主機名稱為準（開發者工具「網路」面板或 Clash 連線記錄均可）。策略名稱請替換成你設定檔中的代理群組，例如 PROXY、Auto 或你自訂的「低延遲」群組。
# Example only — replace PROXY with your real policy group name
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,githubassets.com,PROXY
- DOMAIN-SUFFIX,github.io,PROXY
- DOMAIN,marketplace.visualstudio.com,PROXY
- DOMAIN-SUFFIX,vscode-cdn.net,PROXY
- DOMAIN-SUFFIX,cursor.com,PROXY
- DOMAIN-SUFFIX,cursor.sh,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY為什麼要拆到 githubusercontent.com、githubassets.com 這類子網域？因為複製連結、Release 附件、Raw 檔與 CI 日誌常落在不同主機上，只寫 github.com 仍可能漏掉真正逾時的那條連線。GitHub Copilot 與部分企業功能還可能依賴額外的 API 端點；若你啟用相關外掛後才開始逾時，請優先把失敗網域補進規則表前方，而不是整體換節點。
Cursor IDE 的後端網域同樣可能調整；若更新後突然無法登入或對話卡住，請重新抓一次實際連線目標再更新規則。對於透過外掛呼叫的第三方模型服務，也建議各自補上對應後綴，避免它們落入過於寬鬆的 GEOIP 規則。
行程規則與優先順序：讓「只有編輯器」走特定出口
在某些核心與 GUI 版本中，可使用基於行程名稱的規則（名稱與語法依版本與平台而異，例如桌面環境常見的 Cursor.exe、Code.exe）。這類規則適合處理「同一台電腦上，只有開發工具需要特定線路」的情境，能減少瀏覽器與其他軟體被一起拖慢的情況。不過要注意：不是所有組建都完整支援行程級規則，且沙箱化或更新後的執行檔路徑也可能改變，因此仍建議以域名規則為主、行程規則為輔。
排序方面，實務上可採用「由窄到寬」：先放你已確認的開發者網域，再放第三方 RULE-SET，然後才是 GEOIP 與 MATCH。若你使用訂閱商內建的廣告攔截或地區規則，請確認它們插入的位置是否會在 GitHub 或 Cursor 規則之上；若是，要嘛調整 GUI 的規則合併順序，要嘛把開發者規則改寫到訂閱合併後仍可插入的最前段（依你所用客戶端能力而定）。
與 DNS 強相關的怪症狀（例如「網站顯示開了，但 API 一直失敗」）常來自 fake-ip 與規則匹配順序的交互作用；可對照DNS 防洩漏與設定指南檢查你的解析模式是否與分流邏輯一致。
TUN、系統代理與「沒走代理」的程式
即使規則寫得正確，若應用程式本身不使用系統代理，而你又未啟用 TUN 模式，該程式仍可能直接走預設閘道，導致你看著 Clash 日誌卻完全沒有對應連線。對開發者而言，這常發生在某些 CLI、容器工具或獨立更新器上。若你已啟用 TUN，則需再確認路由表、防火牆與其他 VPN 是否互斥；Windows 使用者若遇到驅動或斷網問題，可參考Wintun／TUN 疑難排解一文依序排查。
另一個細節是 HTTPS 與 HTTP/2 長連線：節點若頻繁斷線或延遲抖動大，IDE 內建的語言伺服器或 AI 面板更容易出現「請求逾時」而非立即報錯。此時除了規則，也應評估代理協定與節點品質，必要時為開發流量單獨準備一組較穩定的策略組，與下載大檔或觀影用途分流。
建議除錯順序：從可觀測證據開始
當 Cursor 或 GitHub 再次逾時，建議依序檢查：（1）該請求的主機名稱與通訊協定是否出現在 Clash 連線日誌；若沒有，代表流量未進入代理或未被 TUN 攔截。（2）若有日誌，命中的是哪一條規則、走向哪個策略組；與你預期是否一致。（3）暫時將該網域手動寫成明確的 DOMAIN-SUFFIX 規則並置頂，重試後是否恢復；若恢復，即可判定為排序或規則集誤判問題。（4）若仍失敗，再換節點或協定，避免一開始就全盤推翻設定檔。
最後，請保留一點工程務實：第三方服務的網域與 API 路徑會變，教學只能提供方法與範本。當官方文件更新或客戶端大版本升級後，重新抓一次連線樣本，比死背網域清單更可靠。若你希望整體連線更敏捷，亦可一併參考Clash 提速實用技巧，從 DNS、訂閱與測速策略收斂延遲來源。
寫在最後
相較於只把「全域開代理」當成萬靈丹，為 Cursor IDE、GitHub 與擴充市集單獨設計 Clash 分流規則，通常能同時改善穩定性與日常網路體驗：該直連的內容不被拖去繞路，該走 開發者代理 的 API 存取也不會卡在錯誤的預設路由上。這種設定一旦整理成可重複套用的片段，未來換機或換訂閱時也能快速還原。
選擇內建較新核心、對規則編輯與連線日誌友善的用戶端，能讓你在排查逾時時少花一半時間。若你尚未安裝或正準備更換客戶端，可從本站下載頁取得對應平台版本，先以預設策略跑穩，再將本文的開發者規則逐步併入。
若需查核開源授權、上游版本或社群討論，亦可另行前往 GitHub 等頁面；日常安裝與更新用戶端仍建議以本站下載入口為主，與原始碼瀏覽用途分開，較不容易誤點到過期或非預期的組建連結。