On this page
Being able to sign in to the editor does not mean model responses, external tools, and terminal commands can all connect. When something stalls, identify the result you are waiting for: an account page, a complete response, a tool result, or a download. Each has its own diagnostics and logs; you do not need to redo all proxy settings at once.
Troubleshooting Cursor Login, Models, MCP, and the Terminal Separately
Repeat only the failing action in Cursor and compare it with the connection records in Clash. Login, streaming model requests, MCP subprocesses, and the integrated terminal each open their own connections. Some use the system proxy, while others read only their own environment variables; use the table below to find the relevant diagnostics.
Find Settings for the Failing Action
| Failure location | What to observe |
|---|---|
| Sign-in or account page | HTTP status after redirect, app diagnostics, and Clash Connections |
| Model remains on Connecting / request times out | Cursor Network Diagnostics, a fixed node, and the streaming connection |
| An MCP tool is red or fails to start | Transport type, process logs, mcp.json, and environment variables |
| git / npm times out in the integrated terminal | The shell's HTTP_PROXY / HTTPS_PROXY and actual port |
Configure the System Proxy and Restart Cursor
Basic Cursor proxy configuration
Pin a node in Clash Proxies
Choose one specific known-good node and keep the mode on Rule.
Enable Clash System Proxy
Confirm that the system proxy points to the current mixed-port, and quit other proxy clients.
Quit Cursor completely and reopen it
Let the new Cursor process reread operating-system proxy settings.
Open the Cursor Network page
Go to Cursor Settings > Network and prepare to run the built-in diagnostics.
Run Diagnostics in Settings > Network
Where each diagnostic result leads
| Result | Next location |
|---|---|
| Diagnostics pass, and sign-in and models work | The basic connection is complete; address only a still-failing MCP integration or terminal |
| Diagnostics fail, and Connections shows no new request | Run diagnostics again and check the system proxy. If the browser has records but Cursor still does not, compare with TUN |
| Diagnostics fail, and the request uses the fixed node but shows timeout | Compare nodes, access networks, and connection persistence |
| Diagnostics or sign-in returns 401 / 403 / 429 | Read the account, permission, or usage message; do not keep changing the proxy port |
When running Run Diagnostics, record the failing item and time, then find the request at that moment in Connections. This correlation is more useful than saving a red icon alone. Keep using the same fixed node for subsequent sign-in and model tests.
Page Not Opening, Repeated Redirects, or Endless Waiting After Sign in
If Sign in fails to open a page, returns to the login page, or keeps waiting, retry with the same fixed node and note where it fails. Check the external browser and Cursor separately. If the new request is absent from Connections, first verify the requesting program uses the current proxy, then handle timeout, 401, or 403 accordingly.
401 points more toward sign-in state; for 403, read the account or region message on the page, while timeout calls for comparing nodes and networks. Keep a fixed outbound route during login and check external authorization requests separately from the return to Cursor. Returning to the app does not necessarily involve a proxied request to a remote service.
Results after fixing Cursor sign-in
- The Sign in redirect request appears in Connections
- Login authorization returns to Cursor successfully, and external requests use the same fixed outbound route
- The Cursor account area shows that you are signed in
- Sign-in state remains after restarting Cursor
Troubleshooting Connecting and Interrupted Long Replies
A successful sign-in proves that the authentication page works. If the model still stays on Connecting, reports Network Error, or stops mid-response, reproduce the model request separately. Use a short prompt to verify that output begins, then a longer one to test whether streaming continues, without switching nodes.
Cursor developer tools can display request status. Open the command palette and run Developer: Toggle Developer Tools. For more complete records, run Developer: Open Logs Folder.
Record the Request ID, time, and Cursor version. Remove the token, code content, and personal paths before sharing logs.
Short responses work, but long ones repeatedly stop
Keep a fixed outbound route, compare another node and network, and inspect streaming stability.
The model request returns 401
Inspect Cursor sign-in state or related credentials; the network already reached the service.
Diagnostics and model requests both show timeout
Check whether Clash records this request: if not, check the app proxy; if it is recorded but times out, check the node.
The page returns 429
Inspect account usage or rate limits; there is no need to keep changing the proxy port.
If Cursor Is Missing from Connections, Compare with TUN
Run Network Diagnostics again after enabling the system proxy. If the browser has records but Cursor still does not, this version or a subprocess may not be using the system proxy. Compare with TUN to send more process traffic into Mihomo. TUN only helps requests enter the proxy; it cannot fix 401, 403, or MCP configuration errors.
Run the same diagnostic after enabling TUN. If new Cursor requests appear in Connections and succeed, they previously bypassed the system proxy. If records appear but still show timeout, return to the node and access network checks.
MCP Connections: Local stdio and Remote HTTP
For local stdio, Cursor starts a command and communicates over standard input and output. SSE and Streamable HTTP connect to an MCP service by URL; the service can run locally or remotely. Check the executable, arguments, and environment for the former, and the URL, authentication, and proxy path for the latter.
Project configuration is usually in .cursor/mcp.json, while global configuration is in ~/.cursor/mcp.json. Identify which file is active before editing so project and global files do not define the same server name. JSON parsing proves only that the syntax is valid; inspect MCP logs to determine whether the service process starts.
{
"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"
}
}
}
}spawn ENOENT, Parsing Errors, and Tool-Call Timeouts
- spawn ENOENT
- Cursor cannot find command; use the correct executable path and run it manually in the same environment.
- JSON parse error
- mcp.json has invalid syntax; inspect commas, quotation marks, and object nesting.
- server exited
- The local process starts and exits; inspect stderr, dependencies, and the working directory.
- HTTP 401 / 403
- Remote MCP received the request; inspect authentication and service permissions.
- tool call timeout
- The service connected, but the call did not finish on time; inspect server logs and external dependencies.
After fixing it, reload the service in Cursor's MCP panel. A green indicator alone is insufficient: complete one minimal tool call and find the request and response in logs. If the tool itself accesses the internet, it needs its own proxy environment.
Environment Variables and Ports in the Integrated Terminal
The integrated terminal inherits its shell environment, which may differ from the Cursor UI’s network settings. Print HTTP_PROXY, HTTPS_PROXY, and NO_PROXY, check the current port and bypass entries, then repeat the request with curl. If Connections has no new record, check whether the tool reads those variables.
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, and language-specific package managers may read proxies differently; configure each according to its documentation. Do not hard-code proxy credentials in project source or commit history. Use the port currently shown by Clash; 7890 is only an example.
Verify Login, Complete Replies, Tool Calls, and Terminal Requests
A sign-in issue ends when you enter the account; a model issue requires one complete response; MCP requires a real tool call; and a terminal issue requires the formerly failing git, npm, or curl command to return a result. You do not need to test all four together, but each needs its own Connections or log evidence.