本文目錄
瀏覽器能用、Cursor 超時，要分開看四條網路路徑
給 Cursor 設定 Clash，不能只證明瀏覽器能開啟網頁。帳號登入、模型串流請求、MCP 子處理程式和整合終端分別發起連線，其中某一條可能讀取系統代理，另一條只看自己的環境變數。
先定位失敗動作
| 失敗位置 | 應該觀察什麼 |
|---|---|
| 登入或帳號頁面 | 跳轉後的 HTTP 狀態、應用診斷與 Clash Connections |
| 模型一直 Connecting / 請求超時 | Cursor Network Diagnostics、固定節點、串流連線 |
| MCP 工具紅色或啟動失敗 | 傳輸類型、處理程式日誌、mcp.json 與環境變數 |
| 整合終端 git / npm 超時 | shell 的 HTTP_PROXY / HTTPS_PROXY 和實際連接埠 |
後面只處理正在失敗的那一條。為了讓結果可比，在 Clash 的 Proxies 中固定節點並保留 Rule 模式；自動組在請求過程中換出口，會讓登入、下載和長回覆更難判斷。
用系統代理建立 Cursor 的基礎連線
Cursor 的基礎代理設定
在 Clash 的 Proxies 固定節點
選擇一條已確認可用的具體節點，模式保持 Rule。
開啟 Clash 的 System Proxy
確認系統代理指向目前 mixed-port，並退出其他代理用戶端。
完全退出後重開 Cursor
讓 Cursor 新處理程式重新讀取作業系統代理設定。
開啟 Cursor 的 Network 頁面
進入 Cursor Settings > Network，準備執行應用內建診斷。
這一步只負責給 Cursor 一個清楚的系統代理起點。接下來執行應用內建診斷，並把結果與 Clash Connections 對上，才能決定是入口、節點、帳號，還是 MCP 自己的問題。
Network Diagnostics 的結果決定下一條檢查線
診斷結果怎麼接著查
| 結果 | 接下來的位置 |
|---|---|
| 診斷透過，登入和模型也正常 | 基礎連線已經完成，只處理仍失敗的 MCP 或終端 |
| 診斷失敗，Connections 沒有新請求 | Cursor 沒有進入系統代理，轉到 TUN 對照 |
| 診斷失敗，請求已走固定節點並 timeout | 比較節點、接入網路和連線持續性 |
| 診斷或登入回傳 401 / 403 / 429 | 讀取帳號、權限或用量提示，不繼續改代理連接埠 |
執行 Run Diagnostics 時記下失敗專案和時間，隨後在 Connections 尋找同一時刻的請求。這個對應關係比單獨儲存一個紅色圖示更有用，後面的登入和模型測試都沿用同一固定節點。
Cursor 登入失敗，盯著登入按鈕後的那次跳轉
按一下 Sign in 後頁面打不開、回到原登入頁或一直等待，先保持固定節點，重新按一下一次，同時查看 Connections。沒有任何登入請求，說明 Cursor 應用沒有進入目前系統代理；請求已經出現，再按 timeout、401 或 403 分開處理。
401 更靠近登入狀態，403 要看頁面給出的帳號或地區提示，timeout 才需要比較節點和網路。登入過程中不要讓自動策略切換出口，否則授權頁和回呼可能來自不同位址，結果會表現為反覆跳轉。
Cursor 登入修復後的結果
- Sign in 跳轉請求出現在 Connections
- 授權頁面和回呼使用同一固定出口
- Cursor 帳號區域顯示已登入
- 重新啟動 Cursor 後登入狀態仍然保留
能登入但模型超時，別反覆清帳號
登入成功說明認證頁面至少走通；模型仍停在 Connecting、Network Error 或回覆中斷，應單獨重現模型請求。用短問題驗證能否開始回傳，再用稍長問題觀察串流連線是否持續，期間不要切換節點。
Cursor 的開發者工具可以顯示請求狀態。開啟命令面板執行 Developer: Toggle Developer Tools；需要更完整記錄時，執行 Developer: Open Logs Folder。
記錄 Request ID、發生時間和 Cursor 版本。分享日誌前刪去 token、程式碼內容和個人路徑。
短回覆成功，長回覆反覆中斷
固定出口，比較另一節點與另一網路，檢查串流連線穩定性。
模型請求回傳 401
查看 Cursor 登入狀態或相關認證資訊，網路已經到達服務。
診斷和模型請求同時 timeout
對照 Clash 是否有記錄，再決定處理入口還是節點。
頁面回傳 429
檢查帳號用量或頻率限制，不用繼續改代理連接埠。
Connections 裡沒有 Cursor，請求還沒進 Clash
開啟系統代理後再次執行 Network Diagnostics。若瀏覽器有記錄、Cursor 仍沒有，目前版本或某條子處理程式可能沒有使用系統代理。此時可以用 TUN 做對照，讓更多處理程式流量進入 Mihomo；TUN 只解決入口問題，不能修復 401、403 或 MCP 設定錯誤。
TUN 開啟後，重新執行同一診斷。Connections 新出現 Cursor 請求並成功，說明之前確實繞過了系統代理；記錄出現但仍 timeout，則回到節點和網路路徑。這個前後對照比長期同時開啟多套代理更可靠。
入口切換後的判斷
- 系統代理下 Cursor 請求是否出現在 Connections
- 開啟 TUN 後是否新增相同目標連線
- 新增連線命中 DIRECT 還是代理策略
- 錯誤從無記錄變成 timeout，還是已經消失
MCP 先看 transport：stdio 和遠端 HTTP 是兩種連線方式
Cursor 支援本機 stdio、SSE 和 Streamable HTTP 等 MCP 傳輸。stdio 服務由 Cursor 啟動本機命令，第一步是看可執行檔案、參數和環境是否正確；SSE 或 Streamable HTTP 才需要檢查遠端 URL、認證和代理路徑。
專案設定通常在 .cursor/mcp.json，全域設定位於 ~/.cursor/mcp.json。修改前確認正在生效的是哪一份，避免專案檔案和全域檔案定義同名 server。JSON 能透過解析，只說明語法正確，服務處理程式是否啟動還要看 MCP 日誌。
{
"mcpServers": {
"local-tool": {
"command": "/absolute/path/to/node",
"args": ["/absolute/path/to/server.js"],
"env": {
"HTTP_PROXY": "http://127.0.0.1:7890",
"HTTPS_PROXY": "http://127.0.0.1:7890",
"NO_PROXY": "localhost,127.0.0.1,::1"
}
}
}
}MCP 「啟動失敗」和「工具呼叫超時」要分開
- spawn ENOENT
- Cursor 找不到 command；使用可執行檔案的正確路徑，並在相同環境裡手動執行。
- JSON parse error
- mcp.json 語法錯誤；檢查逗號、引號和對象層級。
- server exited
- 本機處理程式啟動後退出；查看 stderr、依賴和工作目錄。
- HTTP 401 / 403
- 遠端 MCP 已收到請求，檢查認證與服務權限。
- tool call timeout
- 服務已連線但呼叫沒有按時完成，查看伺服器端日誌和外部依賴。
修復後在 Cursor 的 MCP 面板裡重新載入服務。可用狀態不僅是綠點，還要完成一次最小工具呼叫，並在日誌裡看到請求與回傳；若工具內部還會存取外部網路，它也需要自己的代理環境。
Cursor 終端超時，要在終端裡驗證環境變數
整合終端繼承 shell 環境，不一定跟隨 Cursor 介面的網路設定。先列印 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，再用 curl 存取一個測試位址；如果 Clash Connections 沒有記錄，說明變數沒有生效或連接埠寫錯。
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.comWindows PowerShell、Git、npm 和各語言套件管理員讀取代理的方式可能不同，應按工具文件設定。不要在專案原始碼或提交記錄中硬編碼代理認證資訊。連接埠仍以 Clash 目前顯示為準，7890 只是示例。
修好哪一步，就重做當時失敗的操作
登入問題以成功進入帳號為準；模型問題要讓一條回覆完整結束；MCP 要實際呼叫一個工具；終端則讓原來失敗的 git、npm 或 curl 得到結果。四項不必一起測試，但每項都要對應自己的 Connections 或日誌證據。
如果模型已經穩定，而某個 MCP 仍報 spawn ENOENT，這篇文章的主路徑已經把問題留在 MCP 的本機命令層。此時檢查 command 和檔案路徑即可，不必再動已經可用的 Cursor 網路設定。