On this page
If the browser works but Cursor times out, separate the four network paths
Configuring Cursor to use Clash requires more than proving that a browser opens a web page. Account sign-in, streamed model requests, MCP subprocesses, and the integrated terminal initiate separate connections. One may honor the system proxy while another reads only its own environment variables.
Locate the failing action first
| 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 |
From here, address only the path that is failing. To keep results comparable, pin a node in Clash Proxies and retain Rule mode. An automatic group that switches outbound routes during a request makes sign-in, downloads, and long responses harder to diagnose.
Use the system proxy to establish Cursor's basic connection
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.
This step only gives Cursor a clear system-proxy starting point. Next, run the built-in diagnostics and correlate the result with Clash Connections. Only then can you distinguish the entry path, node, account, or MCP itself.
Network Diagnostics determines the next troubleshooting path
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 | Cursor is not using the system proxy; 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.
If Cursor sign-in fails, watch the redirect after clicking the sign-in button
If the page will not open, returns to the login screen, or keeps waiting after clicking Sign in, keep the fixed node and click once more while watching Connections. No sign-in request means the Cursor app did not enter the current system proxy. If the request appears, handle timeout, 401, and 403 separately.
401 is closer to sign-in state, 403 requires the account or region message shown on the page, and timeout calls for comparing nodes and networks. Do not let automatic policies switch outbound routes during sign-in; the authorization page and callback may then come from different addresses and create repeated redirects.
Results after fixing Cursor sign-in
- The Sign in redirect request appears in Connections
- The authorization page and callback use the same fixed outbound route
- The Cursor account area shows that you are signed in
- Sign-in state remains after restarting Cursor
If sign-in works but the model times out, stop repeatedly clearing the account
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
Compare whether Clash has a record before deciding between the entry path and node.
The page returns 429
Inspect account usage or rate limits; there is no need to keep changing the proxy port.
If Cursor does not appear in Connections, its request has not entered Clash
Run Network Diagnostics again after enabling the system proxy. If the browser has records but Cursor still does not, the current version or a subprocess may not use the system proxy. Compare with TUN to bring more process traffic into Mihomo. TUN fixes only the entry path; it cannot repair 401, 403, or MCP configuration errors.
After enabling TUN, rerun the same diagnostic. If Connections now shows a successful Cursor request, it previously bypassed the system proxy. If a record appears but still shows timeout, return to the node and network path. This before-and-after comparison is more reliable than leaving several proxy layers enabled.
How to interpret the entry-path switch
- Whether Cursor requests appear in Connections under the system proxy
- Whether the same target connection appears after enabling TUN
- Whether the new connection matches DIRECT or a proxy policy
- Whether the error changes from no record to timeout or disappears
For MCP, start with transport: stdio and remote HTTP are different connection methods
Cursor supports MCP transports such as local stdio, SSE, and Streamable HTTP. A stdio service is a local command started by Cursor; first verify the executable, arguments, and environment. Only SSE or Streamable HTTP requires checking the remote URL, authentication, and proxy path.
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"
}
}
}
}Treat MCP “failed to start” separately from “tool call timed out”
- 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.
If the Cursor terminal times out, verify environment variables in that terminal
The integrated terminal inherits the shell environment and may not follow Cursor interface network settings. Print HTTP_PROXY, HTTPS_PROXY, and NO_PROXY first, then use curl on a test address. If Clash Connections has no record, the variables did not take effect or the port is wrong.
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.
After fixing a step, repeat the action that failed there
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.
If the model is stable but one MCP integration still reports spawn ENOENT, the main path in this article has isolated the problem to MCP's local command layer. Inspect command and file paths only; do not change working Cursor network settings.