Cursor 無法連線怎麼辦?Clash 逾時與代理設定完整排查
使用 Clash 開啟 Cursor 時遇到登入失敗、載入卡住或 AI 補全逾時?本文以實際排錯順序檢查代理模式、分流規則與節點狀態,協助你快速恢復開發環境。
先分清 Cursor 逾時的實際症狀
Cursor 開啟後出現「登入失敗」、「載入工作區卡住」、「AI 補全一直轉圈」或「Request timed out」時,不一定代表訂閱服務或帳號本身故障。Cursor 桌面版通常同時依賴登入頁面、編輯器更新服務、AI 請求與遙測連線,其中任何一類網路請求被錯誤分流,都可能讓畫面看起來像整個應用程式無法連線。
排查時要先確認問題範圍。若瀏覽器可以正常開啟一般網站,但 Cursor 登入頁載入失敗,優先檢查系統代理、HTTPS 連線與規則匹配;若登入成功但 AI 補全逾時,則要檢查相關 API 請求是否被送到不可用的節點;如果 Cursor 和其他應用程式全部變慢,才需要把重點放在節點品質、DNS、TUN 或整體代理配置。
| 現象 | 較常見原因 | 優先檢查位置 |
|---|---|---|
| 登入頁空白或登入逾時 | 系統代理未生效、HTTPS 請求被 DIRECT、節點無法建立 TLS | 系統代理、Rule 模式、節點連通性 |
| 工作區載入很久 | 背景服務被錯誤分流、DNS 解析失敗、連線被防火牆攔截 | Clash 記錄、DNS、Windows 防火牆 |
| AI 補全一直轉圈 | API 網域走了失效節點、節點丟包、HTTP/2 或長連線不穩 | 代理組、節點延遲、全域對照測試 |
| 瀏覽器正常但 Cursor 不行 | Cursor 沒有遵循系統代理,或使用了獨立的代理環境變數 | TUN 模式、應用程式代理設定、環境變數 |
不要一開始就重裝
重裝 Cursor 通常不會修復節點失效、規則誤判或本機代理埠未開啟這類問題。先用 Clash 的連線記錄確認請求有沒有進入核心,再決定要不要清除登入狀態或重新安裝。
先檢查 Clash 的基本狀態
第一輪檢查應該只花幾分鐘,目標不是立刻找出所有原因,而是確認 Clash 是否真的處於可以轉發流量的狀態。打開 Clash Verge、Clash Verge Rev 或其他 mihomo 用戶端,先看目前是否已載入有效設定檔,再確認代理核心正在執行。設定檔名稱出現不代表核心已成功啟動,還要觀察控制面板是否能顯示節點、延遲與連線記錄。
- 在設定檔頁面確認目前使用的是最新且完整的設定檔。若更新時間很久以前、節點數量變成零,先不要繼續測試 Cursor,改為重新更新訂閱。
- 進入代理頁面,選一個延遲較低且最近測試成功的節點。不要直接使用一個長時間未測試的節點作為唯一判斷依據。
- 把模式暫時切換成「全域(Global)」,並開啟「系統代理」。這一步只是建立對照組,不代表日常一定要使用全域模式。
- 先用瀏覽器開啟一般 HTTPS 網站,再重新啟動 Cursor。若瀏覽器也無法連線,問題在 Clash、節點或本機網路,不必先調整 Cursor。
- 在 Clash 的連線或日誌頁搜尋與 Cursor 相關的連線記錄。若啟動 Cursor 後完全沒有新請求,代表流量尚未進入 Clash,應優先處理系統代理或 TUN。
常見的混合連接埠是 7890 或 7897,但實際值必須以目前設定檔及用戶端顯示為準。可以在設定檔中看到類似以下欄位:
mixed-port: 7890
allow-lan: false
mode: rule
mixed-port 同時接受 HTTP 與 SOCKS5 請求,應用程式手動設定代理時通常填 127.0.0.1 加這個連接埠。若把 7890 寫死,但目前用戶端實際使用 7897,Cursor 便會直接連線失敗或回退到直連,看起來就像服務逾時。
Windows 可在命令提示字元執行 netstat -ano | findstr :7890,macOS 或 Linux 可執行 lsof -i :7890,確認該連接埠是否真的有程序監聽。若沒有輸出,表示不能只靠手動填入這個連接埠;需要先啟動核心、修正埠號,或改用 TUN 接管。
代理模式與分流規則的排錯方法
Cursor 的登入與 AI 請求通常是 HTTPS 流量,不能只看瀏覽器是否能開啟首頁來判斷它們是否走對節點。Rule 模式下,Clash 會從上到下比對規則,第一個命中就停止。如果某個服務網域先被 DIRECT 規則接走,後面即使存在代理規則也不會生效;如果所有請求最後都命中 MATCH,DIRECT,Cursor 就會繞過代理直連。
最有效的做法是先用全域模式建立基準,再回到 Rule 模式逐步縮小範圍。全域模式下若 Cursor 立即恢復,表示節點和核心大致正常,問題多半在規則或 DNS;全域模式仍然逾時,則應轉向節點品質、TUN、TLS 或本機安全軟體排查。
- 全域模式正常、Rule 模式失敗:查看連線記錄中的策略名稱,確認 Cursor 相關請求是否命中
DIRECT、錯誤的代理組或不存在的策略組。 - 瀏覽器正常、Cursor 沒有記錄:應用程式可能不遵循系統代理,先開啟 TUN;Windows 還要確認服務模式已安裝並獲得管理員權限。
- 請求進入代理但反覆逾時:記下該請求所使用的節點,切換到另一個節點再測試。若只有一個節點失敗,不要先改規則。
- 只有登入成功但 AI 失敗:登入頁與 AI API 可能使用不同網域或長連線方式,應分別觀察記錄,不要把兩者當成同一條連線。
若設定檔使用 mihomo,可用明確的代理策略組承接需要代理的流量,再把它放在最終規則之前。示意寫法如下,CursorProxy 必須替換成設定檔中真實存在的策略組名稱:
proxy-groups:
- name: CursorProxy
type: select
proxies:
- 自動選擇
- 手動節點
rules:
- DOMAIN-SUFFIX,example.invalid,CursorProxy
- MATCH,PROXY
上面使用 example.invalid 只是示意,不代表實際服務網域。不要把未確認的網域清單直接貼進設定檔,也不要使用過寬的 DOMAIN-KEYWORD 規則;關鍵字規則可能誤傷其他網站,讓本來正常的連線也被送到錯誤節點。
不要只看延遲數字
節點測試顯示 80 毫秒,不代表 Cursor 的長連線一定穩定。延遲測試通常只驗證一次 TCP 或 HTTP 請求,無法反映丟包、TLS 交握失敗、連線中途重置與長時間保持連線的表現。排查 AI 逾時時,要同時觀察請求是否完成和連線是否反覆重試。
動手操作:用三組測試定位逾時來源
以下流程適合 Windows、macOS 與 Linux 桌面環境。每完成一組測試就記錄結果,不要同時更改五六個設定,否則即使問題恢復,也無法知道真正有效的是哪一步。
測試一:確認代理埠可用
先在終端機對本機代理埠發出測試請求。以下命令只用於確認本機 HTTP 代理是否能接收請求,網址使用保留示例網域,實際測試時請換成你平時能正常開啟的 HTTPS 網址:
curl -I -x http://127.0.0.1:7890 https://example.invalid
如果回覆「Failed to connect」或顯示連接埠拒絕,先修正 Clash 核心、埠號或防火牆;如果能建立連線但回應逾時,則查看 Clash 記錄與節點狀態。如果命令正常,而 Cursor 仍然逾時,代表 Cursor 沒有使用同一個代理入口,應檢查 TUN 或應用程式自身設定。
測試二:比較 Rule 與 Global
保留同一個節點,先在 Rule 模式啟動 Cursor,再切換 Global 模式重新啟動。兩次測試都應先完全結束 Cursor 程序,避免舊連線仍在背景保持。Windows 可從工作管理員結束相關程序;macOS 可使用「活動監視器」確認程序已退出。
- 只有 Global 成功:查看 Rule 模式下的命中策略,通常是規則順序、代理組或 DNS 導向問題。
- 兩種模式都失敗:切換另一個節點,並查看是否有 TLS handshake、connection reset 或 timeout 記錄。
- 瀏覽器和 Cursor 都失敗:確認系統時間、網路防火牆、DNS 與訂閱狀態,因為這已不是單一應用程式問題。
測試三:必要時啟用 TUN
部分桌面應用程式不完整遵循作業系統的 HTTP 代理設定,這時即使系統代理已開啟,Cursor 仍可能直連。mihomo 的 TUN 模式透過虛擬網卡接管更完整的 TCP、UDP 流量,適合用來判斷「應用程式沒有遵循系統代理」這一類問題。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
Windows 通常需要安裝服務模式並以管理員權限啟用;macOS 需要允許網路擴充功能或輔助程式;Linux 則可能需要 root 或相應的網路權限。開啟 TUN 後先測試一般網站,再測試 Cursor。若 TUN 開啟後所有流量都變慢,先關閉其他 VPN、網路加速器與安全軟體的流量攔截功能,避免多個虛擬網卡互相競爭。
DNS、TLS 與環境變數的進一步檢查
Cursor 逾時不一定是代理節點本身無法連線,也可能是服務網域沒有正確解析。當 DNS 回傳錯誤位址、回傳本機不可達的 IPv6 位址,或 DNS 請求繞過 Clash 被污染時,代理策略即使設定正確,也會在建立連線前卡住。
在 Clash 的 DNS 設定中,確認 enable: true,並查看目前使用的是 fake-ip 還是 redir-host。若使用 fake-ip,應確認沒有把需要代理的服務網域錯誤加入 fake-ip-filter;若應用程式對 fake-ip 相容性不佳,可暫時改用 redir-host 作為對照。不要在沒有理解規則的情況下同時更改 nameserver、fallback、TUN 和 fake-ip,否則很難判定是哪個元件造成問題。
可以先把設定簡化成單一穩定的 DNS 上游,確認解析是否恢復,再逐步加入 fallback 或依規則解析。若連線記錄顯示 DNS 查詢完全沒有進入 Clash,TUN 的 dns-hijack、作業系統 DNS、瀏覽器安全 DNS 以及其他 VPN 軟體都需要一併檢查。
另外要留意環境變數。命令列啟動的開發工具可能讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY,但 Cursor 桌面版不一定使用同一組變數。若這些變數指向已關閉的連接埠,終端機工具會逾時;若值格式錯誤,例如把 SOCKS5 代理寫成普通 HTTP 代理,也會出現連線失敗。可在終端機檢查目前值:
echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $ALL_PROXY
Windows PowerShell 可使用 Get-ChildItem Env:HTTP_PROXY,HTTPS_PROXY,ALL_PROXY。如果不需要這些變數,先暫時清除後重新啟動終端機與 Cursor;如果開發工具確實需要代理,則填入目前有效的本機埠,並按照工具要求使用 http:// 或 socks5:// 格式。
TLS 憑證錯誤不要直接忽略
若記錄出現憑證驗證失敗、主機名稱不匹配或系統時間錯誤,請先校正系統時間、檢查是否有 HTTPS 攔截軟體,再確認節點與 DNS。不要為了讓 Cursor 暫時連線而關閉 TLS 驗證,這會降低所有 HTTPS 連線的安全性,也可能讓登入權杖暴露在不可信的中間設備上。
常見問題
為什麼瀏覽器能用,Cursor 卻顯示逾時?
瀏覽器通常完整遵循系統 HTTP 代理,而桌面應用程式可能使用自己的網路層,或只遵循部分系統設定。先查看 Clash 是否有 Cursor 的連線記錄;完全沒有記錄時,優先開啟 TUN 或確認 Cursor 是否被防火牆攔截。有記錄但走了 DIRECT,則檢查 Rule 順序與代理組。
一定要把 Clash 切成全域模式嗎?
不需要。全域模式適合用作排錯對照,確認節點和核心是否能承接 Cursor 請求。確認全域正常後,建議回到 Rule 模式,查看實際命中策略並建立更精確的分流,避免所有本地與不需要代理的流量都經過節點。
切換很多節點都無法解決 AI 補全逾時,下一步做什麼?
先確認請求確實進入 Clash,並檢查 DNS 是否能解析、系統時間是否準確、TUN 與其他 VPN 是否衝突。若不同節點都能建立連線但長連線反覆中斷,應查看核心日誌中的 TLS、HTTP/2、connection reset 或 timeout 訊息,再暫時停用會攔截 HTTPS 的安全軟體作對照。
清除 Cursor 登入資料可以解決問題嗎?
只有在代理通道已確認正常、但登入狀態損壞或瀏覽器回呼流程卡住時,清除登入資料才有幫助。清除前先記下目前帳號與工作區設定,並避免在代理尚未修好的情況下反覆登入,否則只會產生更多逾時與重新驗證提示。
完成排查後的穩定配置
建議日常使用 Rule 模式、保留一個可手動切換的代理組,並把 TUN 作為不遵循系統代理之應用程式的備用方案。每次更新訂閱後重新測試 Cursor,確認代理組仍然存在、規則沒有被覆蓋,遇到逾時時就能按照「核心狀態 → 代理埠 → Rule/Global → DNS/TUN → 節點」的順序快速定位。
下載 Clash 用戶端
規則分流的前提是用戶端先接管流量。前往下載中心依平台選擇用戶端,再回到教學文章完成系統代理或 TUN 接管設定。