Cursor 連不上怎麼辦？Clash 逾時與代理設定完整排查

先確認逾時發生在哪一層

Cursor 開不起來、登入頁面載入失敗、AI 補全一直顯示載入中，或聊天視窗回傳 timeout，不一定代表 Cursor 本身故障。這類問題通常會經過多個網路環節：Cursor 應用程式建立 HTTPS 連線、系統或應用程式讀取代理設定、Clash 將流量交給策略組、代理節點連線到服務端，最後才由 Cursor 取得登入、模型或補全回應。任何一層沒有正確接上，都可能只在介面上呈現「連線逾時」。

排查前先記錄具體症狀。若 Cursor 完全無法登入，優先檢查網域解析、系統代理與節點可用性；若登入成功但 Chat 或 Tab 補全失效，可能是特定 API 網域沒有進入代理；若只有工作區中的擴充功能無法下載，則要另外檢查 Cursor 的擴充功能服務與應用程式代理設定。不要一開始就同時更換節點、開啟 TUN、修改 DNS，否則很難確認是哪個變更真正解決問題。

檢查 Clash 核心、模式與代理連接埠

Cursor 能否使用 Clash，首先取決於 mihomo 核心是否正在執行，以及本機代理連接埠是否真的有程序監聽。FlClash 或其他圖形客戶端顯示「已啟動」，不一定表示設定檔已成功載入。建議先查看核心日誌，確認沒有 YAML 解析錯誤、策略組不存在、代理節點握手失敗或連接埠被其他程式占用。

常見的設定會使用 mixed-port: 7890，這個連接埠同時接受 HTTP 與 SOCKS5 請求；控制介面則可能使用 external-controller: 127.0.0.1:9090。9090 是 API 控制連接埠，不是給 Cursor 填寫的代理連接埠。Cursor 的代理欄位應填入 127.0.0.1:7890，實際數值仍以目前設定檔中的 mixed-port 或客戶端顯示為準。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

在 Windows 可以使用命令提示字元檢查連接埠：

netstat -ano | findstr :7890

macOS 或 Linux 可以使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN

如果沒有任何監聽結果，先不要修改 Cursor 設定，應回到 Clash 客戶端啟動核心。若連接埠被其他 Clash 實例占用，可能出現新核心啟動失敗但舊核心仍在運作的情況。此時先退出其他代理客戶端，再重新啟動目前使用的 FlClash 或 mihomo，避免多個核心互相競爭相同的連接埠。

確認規則模式與策略組

Cursor 相關流量通常不只來自一個網域。登入、更新、擴充功能、模型請求與遙測可能使用不同的主機名稱。若使用 rule 模式，某個網域命中 DIRECT，而本地網路又無法直連，就會出現部分功能正常、部分功能逾時的情況。切換到全域代理只能作為診斷手段，不建議長期不加區分地代理所有流量。

1. 在 Clash 的連線或日誌頁面啟動 Cursor，等待一次失敗請求。
2. 搜尋與 Cursor、登入、更新或模型服務相關的連線記錄。
3. 確認請求是否出現，以及它使用的是哪個策略組。
4. 若請求顯示 DIRECT，可暫時切換到代理策略測試。
5. 若請求完全沒有出現，優先檢查 Cursor 是否繞過了系統代理，或是否需要 TUN 接管。

在 Cursor 中設定代理並完成一次測試

如果瀏覽器已經可以透過 Clash 開啟網站，但 Cursor 仍然逾時，應檢查 Cursor 是否使用了獨立的應用程式代理設定。Cursor 建立於 VS Code 類型的桌面架構，部分網路請求會參考應用程式設定中的 http.proxy、http.proxySupport 與憑證選項；不同版本的介面名稱可能略有差異，因此應以目前版本的 Settings 搜尋結果為準。

在 Cursor 按下 Ctrl+,（macOS 為 Cmd+,）開啟設定，搜尋 proxy，檢查是否存在過期、錯誤或指向其他工具的代理網址。若要明確指定本機 HTTP 代理，可以使用類似以下的設定。使用 mixed-port 時，通常填寫 HTTP 形式的本機位址即可：

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxySupport": "override"
}

override 會讓應用程式優先使用指定代理，適合用來判斷「Cursor 沒有讀取系統代理」這種情況。測試完成後，若公司網路或本機環境需要讓不同請求採用不同代理，可再改回較符合日常需求的模式。不要把控制介面 127.0.0.1:9090 填入 http.proxy，也不要把 SOCKS 代理寫成 HTTP 協定；協定與連接埠不匹配時，常見結果就是立即拒絕或連線逾時。

動手操作：用單一變數找出問題

1. 先關閉 Cursor，再在 FlClash 中確認 mihomo 核心正在執行，並記下實際的 mixed-port。
2. 在瀏覽器透過同一個 Clash 節點開啟一般 HTTPS 網站，確認節點不是完全失效。
3. 暫時將 Clash 切換至全域代理，重新啟動 Cursor，只測試登入或 Chat，不要同時改 DNS。
4. 若全域模式成功，回到規則模式，查看 Cursor 失敗時的連線記錄，找出被分到 DIRECT 或錯誤策略的網域。
5. 若全域模式仍失敗，在 Cursor 設定中明確填入 http://127.0.0.1:7890，重新啟動應用程式。
6. 若明確指定代理後成功，表示原本的系統代理沒有被 Cursor 正確讀取；若仍失敗，改用另一個穩定節點測試。
7. 每次只改一項設定，並在 Clash 日誌中觀察新的請求是否出現，避免將多個變更混在一起。

測試期間可以將 Clash 的 log-level 暫時設為 info。不建議長時間使用過度詳細的除錯層級，因為大量日誌可能掩蓋真正的失敗請求，也可能在記錄中留下網域、查詢參數或其他敏感資訊。排查完成後，可將日誌層級恢復為 warning 或日常使用的值。

應用程式代理無效時檢查 TUN、DNS 與防火牆

有些程式不讀取系統代理，也不完全遵循 Cursor 的代理設定。這種情況下，即使 http.proxy 填寫正確，部分背景程序仍可能直接連線。mihomo 的 TUN 模式可以透過虛擬網路介面接管較廣泛的系統流量，適合需要代理命令列工具、容器、遊戲或不支援代理設定的應用程式。不過 TUN 不是「開啟後必然修復」的按鈕，錯誤的路由或 DNS 接管反而可能造成所有網路都變慢。

啟用 TUN 前，先關閉其他 VPN、企業安全軟體或舊版代理的虛擬網卡，並確認客戶端取得系統管理員權限。在 mihomo 設定中，常見的起點如下：

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
dns:
  enable: true
  enhanced-mode: fake-ip

以上只是測試方向，不應直接覆蓋現有訂閱設定。不同平台、核心版本與客戶端對 TUN 欄位的支援可能不同。若啟用後出現網站全部無法開啟、區域網路裝置消失或 DNS 反覆失敗，先關閉 strict-route 或整個 TUN，恢復到系統代理模式，再從核心日誌判斷路由問題。

DNS 解析與憑證錯誤

Cursor 逾時不一定是節點速度不足，也可能是目的地網域被解析到不可達的 IP。若 Clash 使用 fake-ip，而某些系統服務、企業防毒或應用程式不接受虛擬 IP，可能出現連線異常。可以暫時測試 redir-host 或確認相關網域是否被加入合理的 fake-ip 過濾清單。修改 DNS 後應重新啟動 Cursor，因為應用程式或作業系統可能仍保留先前的 DNS 快取。

若日誌出現 x509、certificate verify failed 或 TLS 握手錯誤，不要直接關閉憑證驗證。先檢查系統時間、節點的 TLS 設定、公司代理是否進行 HTTPS 檢查，以及是否安裝了錯誤的根憑證。關閉 TLS 驗證會降低安全性，也可能讓帳號認證與模型請求暴露在中間人攻擊風險中。

防火牆與安全軟體的攔截

Windows 防火牆、macOS 網路過濾器、企業端點安全軟體或第三方防毒，可能允許瀏覽器通過，卻阻擋 Cursor 或 mihomo 核心建立外部連線。當 Clash 日誌完全看不到 Cursor 的請求，而 Cursor 又一直逾時時，可檢查作業系統的應用程式網路權限。只允許必要的 Cursor 與 mihomo 程序，不要為了測試而長時間關閉整個防火牆。

常見問題與最後檢查清單