現象：為什麼你的 Cursor Composer 頻繁超時？

到了 2026 年，Cursor AI 已成為開發者的標配工具。然而，許多使用者在開啟 Composer 進行大規模代碼重構，或是在初次開啟專案進行 Codebase Indexing 時，經常會遇到「Connection Timeout」或「Indexing Failed」的錯誤提示。這並非單純的伺服器負載問題，更多時候是網路層級的分流失效與連線重置所致。

Cursor 的工作原理與傳統瀏覽器不同。它不僅需要訪問 cursor.sh，還需要與 Anthropic (Claude)、OpenAI 的後端端點，以及其專有的向量資料庫（用於代碼索引）維持穩定的 gRPC 或 WebSocket 長連線。如果你的 Clash 配置僅僅是「全域代理」或依賴過時的「AI 規則集」，往往會因為DNS 污染或系統代理無法接管 IDE 內部行程而導致索引超時。

編輯備註：Cursor 的後端域名會隨版本更新調整。若你發現配置後依然超時，請務必查看 Clash 的「Connections（連線）」列表，搜尋關鍵字 cursor 找出漏網之魚。

為什麼傳統系統代理對 Cursor 不夠用？

許多開發者習慣在 Windows 或 macOS 上開啟「系統代理（System Proxy）」。這種模式下，瀏覽器能流暢訪問 ChatGPT，但 Cursor 的索引行程（如 cursor-indexer）有時會繞過環境變數，直接嘗試直連。特別是在 2026 年，Cursor 引入了更複雜的本地與雲端協同索引機制，這些後台行程的流量特徵往往不符合標準的 HTTP 代理協議。

這就是為什麼我們強烈建議使用 TUN 模式。TUN 模式通過建立虛擬網卡，在 IP 層級截獲所有流量，確保無論 Cursor 內部如何調用系統 API，流量都能正確進入 Clash 核心。如果你還在猶豫，可以參考 Clash TUN 模式指南 了解其技術優勢。

核心解決方案：精準的 Cursor 分流規則

要徹底解決超時，第一步是在你的 Clash 配置（YAML）中加入專屬的 Cursor 規則組。不要將其與普通的「Google」或「GitHub」規則混在一起，因為 Cursor 的伺服器對延遲極其敏感，且經常被誤判為直連流量。

1. 必須涵蓋的域名清單

請在你的 rules 板塊中，將以下域名指向一個延遲穩定、頻寬充足的代理組（例如 [Proxy] 或 [AI-Services]）：

  • DOMAIN-SUFFIX,cursor.sh（主站與 API）
  • DOMAIN-SUFFIX,cursor.com（新版資源域名）
  • DOMAIN-SUFFIX,cursor.com.cdn.cloudflare.net（CDN 加速）
  • DOMAIN-SUFFIX,todesktop.com（Cursor 使用的桌面應用更新與分發平台）
  • DOMAIN-KEYWORD,cursor-controllers（內部控制器）
  • DOMAIN-SUFFIX,anthropic.com（若使用 Claude 模型）
  • DOMAIN-SUFFIX,openai.com（若使用 GPT 模型）

2. 推薦的 YAML 配置片段

YAML# 策略組建議
proxy-groups:
  - name: Cursor-AI
    type: select
    proxies:
      - 香港優質節點
      - 美國優質節點
      - 台灣優質節點

# 規則設定
rules:
  - DOMAIN-SUFFIX,cursor.sh,Cursor-AI
  - DOMAIN-SUFFIX,cursor.com,Cursor-AI
  - DOMAIN-SUFFIX,todesktop.com,Cursor-AI
  - DOMAIN-KEYWORD,cursor,Cursor-AI
  # 兜底 AI 規則
  - RULE-SET,ai-services,Cursor-AI

進階優化：開啟 TUN 模式與 DNS 修正

配置了規則卻依然在「Indexing」階段卡住？這通常是因為 DNS 污染。Cursor 在索引代碼庫時，會並發發起大量解析請求。如果 DNS 解析返回了被干擾的 IP，Clash 即使有規則也無法正確轉發。

DNS 配置建議

在 Clash 的 dns 板塊中，請確保啟用了 fake-ip 模式，並將 Cursor 的域名加入 fake-ip-filter（如果需要直連）或確保 nameserver 中包含可靠的加密 DNS（DoH/DoT）：

  1. 確認 dns.enable 為 true。
  2. 設置 enhanced-mode 為 fake-ip。
  3. 在 default-nameserver 中填入 119.29.29.29 等本地快速 DNS。
  4. 在 nameserver 中填入 https://dns.cloudflare.com/dns-query 以保證解析準確。

開啟 TUN 模式的步驟

無論你使用的是 Clash Verge Rev 還是 Mihomo Party，開啟 TUN 模式的邏輯是一致的：

  1. 以管理員權限執行 Clash 客戶端。
  2. 進入設置介面，安裝 Service Mode（部分客戶端需要此步以獲取系統權限）。
  3. 切換 TUN Mode 開關。
  4. 在系統網路設置中，確認出現了一個名為 clash 或 utun 的虛擬網卡。

常見誤區：為什麼換了節點還是沒用？

有些使用者發現，切換到美國節點後，Composer 依然提示超時。這裡有幾個隱藏的坑：

  • UDP 流量被攔截：Cursor 的部分底層通信可能嘗試使用 QUIC (UDP) 協議。如果你的代理節點不支援 UDP，或者你的 Clash 配置中 udp: false，就會導致降級失敗進而超時。請確保 udp: true。
  • 節點 IP 被風控：Cursor 背後調用的 Anthropic/OpenAI 對 IP 有嚴格限制。如果節點 IP 被標記為「High Risk」，連線會被靜默丟包。建議選擇原生 IP 或家寬節點。
  • 併發連線數限制：索引專案時會產生數百個併發連線，部分平價機場會限制單帳號連線數，導致部分索引請求被強行切斷。

超時排查清單（2026 版）

  1. 連線列表檢查：在 Cursor 報錯時，立即查看 Clash 的「Connections」。過濾出 cursor 關鍵字，看是否有顯示為 Match: Match（即走直連）的紅色失效連線。
  2. 日誌等級調整：將 Clash 日誌等級設為 debug，觀察是否有 DNS Resolution Error。
  3. 排除系統防火牆：Windows Defender 有時會攔截虛擬網卡的異常流量，嘗試暫時關閉防火牆測試。
  4. 更新 Mihomo 核心：2026 年的 Cursor 可能使用了更新的 TLS 特性，請確保你的核心版本不低於最新穩定版。可參考 Mihomo 核心升級指南。

結語

相比之下，市面上不少同類 AI 工具在網路環境適配方面配置繁瑣，且缺乏針對開發場景的專屬優化， 對新手來說容錯空間極小，稍有不慎就會在索引階段卡死，白白浪費訂閱費用。Clash 官網 在 Cursor AI 網路優化方面做了大量實測， 通過精準的規則分流與穩定的 TUN 模式接管，整個流程按照本文步驟操作即可順利完成。 如果你正好在尋找一款能夠完美支持 Cursor 索引與 Composer 功能的代理工具，不妨 免費下載 Clash 官網 試試，幾分鐘內就能跑起來，徹底告別 Connection Timeout。