為什麼「官網能開，Cursor 裡面卻一直逾時」？

Cursor 本質上建立在 VS Code 技術堆疊之上：延伸模組市集、帳號登入、更新檢查、以及內建的 AI 補全與模型對話，往往會打到與一般瀏覽器分頁不完全相同的主機名稱與 API 端點。2026 年仍常見的情況是，使用者在 Chrome 裡能順利開啟產品頁或說明文件，但回到編輯器就開始出現登入失敗、市集連線錯誤、或 AI 請求卡住。這不一定是節點品質問題，而是流量沒有穩定走進你預期的代理鏈：例如瀏覽器跟著系統 HTTP 代理，而 Electron 架構的應用程式改用內建網路堆疊；或部分連線在 DNS 階段就繞過 Clash，導致規則引擎根本來不及判定。

處理這類問題，與我們在 ChatGPT／Claude 分流一文強調的重點一致：要把「服務實際連到哪裡」寫進規則，並讓 DNS 解析與規則匹配走同一條邏輯。差別在於，Cursor／VS Code 場景多了市集 CDN、GitHub 相關 API、以及發行商更新網域，需要一份更貼近「開發者 IDE 棧」的維護清單，而不是只寫幾個聊天機器人的首頁網域。

HTTPS 流量長什麼樣子：IDE 與瀏覽器的差異

多數使用者只看到「連不上」的結果，但底層幾乎全是 TLS 加密後的 HTTPS：你無法從封包內文直接讀出 URL，只能在客戶端或代理核心上觀察SNI（伺服器名稱指示）與解析到的目標主機。Cursor 與 VS Code 在背景會發起大量小請求：檢查更新、下載延伸模組套件、同步設定、向模型供應商送出補全請求等。這些連線若有一部分落到直連、另一部分落到代理，體感就會像「偶爾能用、偶爾全紅字」，或登入流程在 OAuth 跳轉後突然斷掉。

實務排查時，建議優先在 Clash／mihomo 的連線日誌中核對實際連線主機名稱是否與你的規則相符，而不是只看瀏覽器能否開啟某個行銷頁。若你希望先補齊規則語意與策略組型態，可搭配閱讀 Clash 規則分流詳解，再把本篇當成 IDE 場景的網域備忘錄。

常見網域與規則片段（示意，請依環境調整）

以下主機名稱會隨產品更新而變動，僅供設定思路參考；正式環境請以你實際連線日誌、官方文件與訂閱規則集為準。目標是將「IDE 會用到的那一批」集中導向獨立策略組（例如 DEV-IDE），並把規則放在寬泛的 GEOIP 或大型規則集之前，避免永遠命中不到。

  • Cursor 產品與服務：cursor.com、cursor.sh、api.cursor.com（實際子網域請以日誌為準）。
  • VS Code 延伸模組市集：marketplace.visualstudio.com、vscode.blob.core.windows.net，以及常見的 *.vscode-unpkg.net 類 CDN（套件下載）。若你使用 Open VSX，另需涵蓋 open-vsx.org 等來源。
  • 帳號與 OAuth 常見依賴：github.com、api.github.com（登入與市集常與 GitHub 身分鏈結）；部分組織環境還會碰到 Microsoft 身分平台網域，需另行觀察。
  • AI 供應商 API：視你啟用的模型與供應商而定，可能與 通用 AI 站點分流重疊，建議以專用策略組統一承接，避免與一般影音流量搶同一節點。
# Example: route IDE / marketplace / Cursor hosts to a dedicated group (illustrative)
rules:
  - DOMAIN-SUFFIX,cursor.com,DEV-IDE
  - DOMAIN-SUFFIX,cursor.sh,DEV-IDE
  - DOMAIN-SUFFIX,api.cursor.com,DEV-IDE
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,DEV-IDE
  - DOMAIN-SUFFIX,vscode-unpkg.net,DEV-IDE
  - DOMAIN-SUFFIX,vscode.blob.core.windows.net,DEV-IDE
  - DOMAIN-SUFFIX,open-vsx.org,DEV-IDE
  - DOMAIN-SUFFIX,github.com,DEV-IDE
  - DOMAIN-SUFFIX,api.github.com,DEV-IDE
  # ... insert before broad GEOIP / RULE-SET and final MATCH
若你使用社群維護的規則集，請確認其中是否已含市集與 GitHub 相關條目，以及它在規則鏈中的順序；過於寬鬆的 DIRECT 規則若排在前面，會讓後面的 IDE 專用規則形同虛設。

策略組：把「開發工具出口」獨立出來

為 Cursor／VS Code 相關網域建立獨立策略組的核心好處，是與日常瀏覽、串流或下載分流：你可以挑一個對長連線與 API 較友善的節點，而不必為了讓編輯器穩定，就把整機所有流量都鎖在同一出口。對 AI 補全這類低延遲、怕抖動的工作負載，手動 select 固定節點通常比過於激進的 url-test 更穩；若你需要備援，可再評估 fallback 或較長間隔的自動測速，避免節點頻繁切換導致 TLS 會話中斷。

請留意：策略組只決定「命中規則後要走哪個出口」；若規則本身沒寫到某個子網域，流量仍會落入後面的預設規則。換句話說，代理分流要有效，一定是「規則覆蓋率」與「策略組選擇」兩件事同時到位。

DNS 與 fake-ip：減少解析與規則「各說各話」

IDE 場景裡，DNS 問題往往偽裝成「應用程式壞掉」：同一台機器上，終端機裡的 curl 正常，但編輯器內建程序卻解析到不可路由的位址，或與 Clash 核心的 fake-ip 對不起來。當核心啟用 fake-ip 時，理想情況是應用程式的 DNS 查詢也經過核心，讓「網域名稱 → 規則」在同一路徑完成；否則就容易出現某些程序直連 IP、繞過策略的現象。

實務檢查清單包括：dns.enable 是否開啟；nameserver 與 fallback 是否會被污染或過慢；fake-ip-filter 是否把必須真實解析的網域（例如部分區網或本機服務）排除在外。若你懷疑 fake-ip 與某程式不相容，可在測試環境暫時改用 enhanced-mode: normal 做對照——這屬於排查手段，長期仍應以核心與客戶端文件建議為準。 

# Sketch: keep DNS queries aligned with the core for IDE traffic
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - tls://1.0.0.1:853

僅 IDE 走代理 vs. 全域模式：怎麼選？

僅讓 IDE 相關網域走代理的做法，適合希望「日常網站直連、只有開發與 AI 工具出口受控」的使用者：透過精準的 DOMAIN-SUFFIX／RULE-SET，把市集、GitHub、Cursor 與模型 API 丟進 DEV-IDE，其餘流量維持 DIRECT 或另一組策略。缺點是你必須持續維護網域清單，因為供應商可能新增 CDN 或子網域；一旦漏寫，症狀就會回來。

全域模式（常見實作是開啟 TUN 或讓系統預設路由大量走代理）的好處是覆蓋率高，較不容易漏掉冷門子網域；代價是延遲、相容性與除錯成本可能上升，且不一定符合「最小暴露面」的習慣。若你正在評估是否要用 TUN 解決「某些程式不吃系統代理」的問題，可先參考 Clash TUN 模式指南，再回到本篇微調 IDE 相關規則的優先順序。

兩種做法沒有絕對高下：關鍵是你願意用「規則維護」換取精準分流，還是用「全系統接管」換取覆蓋率。對 Cursor 這類同時打市集、GitHub、與多家模型端點的應用程式，實務上常從「精準規則 + 獨立策略組」開始；若仍遇到頑固的漏網之魚，再考慮提高接管範圍。

排查捷徑：對照症狀縮小範圍

延伸模組市集載入很慢或失敗

先確認 marketplace.visualstudio.com、vscode-unpkg.net、vscode.blob.core.windows.net 等是否在規則中命中預期策略組；再看連線日誌是否有被前置規則誤判為直連。若你使用公司網路，也要排除 HTTPS 檢查設備對大型套件下載的干擾。

AI 補全或模型請求逾時

核對實際 API 主機是否已納入與 ChatGPT／Claude 等相同的 AI 策略桶；並觀察是否為 url-test 切換過於頻繁、或節點對長連線／WebSocket 支援不佳。此時固定 select 節點往往比盲目更換「全域節點」更有效。

登入轉圈、OAuth 完成後仍無法使用

登入流程常跨多個網域與重新導向；若只有主站走代理而 GitHub 或身分提供者相關網域直連，可能出現 Cookie 與端點區域不一致。請把登入日誌中出現的主機一併納入同一策略組，或暫時提高接管範圍做驗證。

請遵守服務條款、授權與當地法規使用開發工具與 AI 功能；本文僅討論網路連線與代理設定層面的穩定性，不提供規避服務商或雇主政策的方法。

總結

Cursor 與底層 VS Code 生態在 2026 年仍是高度依賴 HTTPS 與多網域協作的典型「開發者棧」：市集、更新、GitHub 身分與模型 API 任一環節漏代理或 DNS 不一致，都會表現成登入異常、市集失敗或 AI 逾時。用 Clash／mihomo 時，請優先把實際連線主機寫進規則、以獨立策略組承接 IDE 流量，並讓 DNS 與規則引擎一致；再視需求選擇「僅 IDE 網域分流」或「提高全系統接管」來換取覆蓋率。

相比只調整訂閱或反覆切換「全域節點」，這套做法更貼近多程式並存的現實，也能與通用 AI 站點教學並行維護：一條線照顧聊天與 API 服務，一條線照顧編輯器與市集，長期較不容易互相干擾。

→ 立即免費下載 Clash 官方用戶端，安裝後依本站教學匯入設定，再把本文的網域與策略組思路套進你的 YAML，通常能明顯改善 IDE 內「一下連得上、一下又逾時」的不穩定感。若你希望先從全站功能概覽開始，也可參考 Clash 功能與文件總覽。