Fix Cursor Not Working With Clash: Troubleshoot Network Timeouts

Identify the failing layer before changing Clash settings

When Cursor stops loading AI features, shows a request timeout, or remains stuck while generating code, the installation is not necessarily broken. Cursor traffic can be affected by the active Clash mode, the selected policy group, DNS resolution, a rule that sends the request DIRECT, or a local proxy setting that points to the wrong port. A healthy browser connection does not prove that Cursor is using the same route.

Start by separating the symptoms. If Cursor opens normally but chat requests time out, the problem is likely related to API routing, the selected node, or an application-specific proxy path. If the editor cannot sign in, check authentication and browser hand-off separately. If extensions fail to install, the extension marketplace may be using a different request path from the AI provider. If every application loses connectivity after enabling TUN, investigate Clash itself, DNS, or the virtual interface before focusing on Cursor.

Understand what a timeout actually means

A timeout can happen at different stages. A DNS timeout means the hostname was not resolved in time. A connection timeout means Clash or the operating system could not establish a TCP connection to the destination. A TLS timeout or reset means the connection reached a remote endpoint but failed during encryption negotiation. A request timeout after the connection was established may indicate an overloaded node, an upstream service delay, or a long-lived streaming connection being interrupted.

These cases are different from an HTTP response such as 401, 403, or 429. An HTTP error proves that a server or gateway responded; it is not the same as a network timeout. Repeatedly changing the Clash node will not fix an expired account session or an access policy rejection. Conversely, reinstalling Cursor will not fix a rule that sends an AI request to a dead DIRECT route.

Check Clash mode, policy groups, and matching rules

For an initial test, use Rule mode rather than Global or Direct. Rule mode gives you visibility into which rule matched each connection, while Global mode can hide whether the configuration contains an incorrect domain rule. Direct mode is useful as a controlled comparison only when the destination is expected to be reachable without a proxy.

In the Clash client, open the connections or logs view while starting a new Cursor chat request. Look for newly created connections at the exact time of the failure. The useful fields are the destination hostname, destination port, matched rule, selected policy, connection status, and error message. A connection marked DIRECT is not automatically correct, and a connection marked with a proxy policy is not automatically healthy. The important question is whether the route matches the network requirement for that destination.

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

rules:
  - MATCH,PROXY

This simplified example sends unmatched traffic to a policy named PROXY. The exact policy name in a subscription may be different, such as Node Select, Proxy, or a provider-specific group. Do not paste this fragment over a complete subscription without understanding its proxy definitions. It is a diagnostic example, not a universal replacement configuration.

Verify the active policy instead of only testing latency

A node can return a low latency value while still failing to carry the particular traffic used by Cursor. A latency test may use a lightweight URL, whereas AI requests can involve different hostnames, TLS behavior, response sizes, or long-lived connections. Select a known working node manually, send one Cursor request, then test a second node. If one node works and another consistently times out, keep the policy selection as the primary suspect.

• Check the policy group: Confirm that Cursor traffic is using the intended group, not an empty group, a disabled provider, or a fallback with no available nodes.
• Check the rule order: Clash evaluates rules from top to bottom. A broad DOMAIN-SUFFIX, GEOSITE, or GEOIP rule placed above a more specific rule can send traffic to the wrong policy.
• Check the final catch-all: A final MATCH,DIRECT rule may route unknown AI service domains directly. Use the connection log to confirm whether that is intentional.
• Check rule-provider status: An unavailable or outdated rule set can produce unexpected matches. Update it only after saving the current configuration and note whether the result changes.
• Check IPv6 behavior: If the node or local network has unreliable IPv6 connectivity, a hostname may resolve to an IPv6 address that never completes. Compare behavior with IPv6 disabled in the client or configuration, if that option is available.

Cursor may contact multiple service domains for authentication, model requests, updates, extension services, and telemetry. Avoid adding a random list copied from an unverified source. Capture the actual destination shown in the Clash log, verify that it belongs to the service you intend to use, and then create the narrowest rule necessary. Service hostnames can change, so a hard-coded domain list should be reviewed when the application or provider changes its architecture.

Perform a controlled test from the local proxy to Cursor

Run the following checks in the middle of troubleshooting, after recording the current settings. The purpose is to compare three paths: a direct request, a request through the Clash mixed port, and the actual Cursor process. A command-line result does not reproduce every Cursor request, but it can quickly show whether the local proxy is listening and whether a selected route can complete an HTTPS connection.

1. In FlClash or another Clash client, confirm that the core is running and note the actual mixed port. Do not assume it is 7890; some configurations use 7897, 7898, or another value.
2. Confirm that the system proxy points to the same host and port. A common local address is 127.0.0.1:7890, but the value must match the active configuration.
3. Use the Clash connection log and start a new Cursor request. Record the matched rule and selected policy.
4. Switch only the policy group to a second known-good node and repeat the same request.
5. Disable TUN while keeping system proxy enabled, then repeat the test. If the result improves, focus on TUN routing or DNS rather than the subscription node.
6. Restore the original setting after each comparison unless you have confirmed that the new setting is stable.

On a desktop system, you can test the local HTTP or mixed proxy with curl. Replace the example hostname with a service endpoint that you are authorized to access. Do not paste subscription tokens, cookies, authorization headers, or private response content into a public issue or chat.

curl -v --connect-timeout 10 --max-time 30 \
  -x http://127.0.0.1:7890 \
  https://example.com/ \
  -o /dev/null

If the command reports that the local proxy connection was refused, inspect the core status and port assignment. If it connects to the local proxy but times out while establishing the remote connection, inspect the active policy and node. If it completes successfully while Cursor still fails, focus on Cursor’s proxy inheritance, its process environment, or a destination-specific rule.

Inspect Cursor’s proxy behavior

Cursor is built on the Electron and VS Code application model, so its proxy behavior can depend on application settings, operating-system proxy settings, launch parameters, and environment variables. The exact setting names may vary by release, but search the Settings interface for proxy and inspect whether the application is using system settings, a manually configured HTTP proxy, or a bypass list.

A frequent mistake is leaving an old manual proxy entry in Cursor after changing Clash’s port. For example, Clash may now listen on 127.0.0.1:7897 while Cursor still tries 127.0.0.1:7890. Another common problem is configuring a SOCKS port in a field that expects an HTTP proxy URL. When the client offers a mixed port, use the scheme and format expected by the application, such as http://127.0.0.1:7890, rather than guessing from the port number.

• Remove stale manual proxy values and restart Cursor completely, including its background process.
• Check whether a bypass list excludes the hostnames visible in the Clash log.
• Compare “use system proxy” with a manual proxy setting, but do not enable both conflicting configurations at the same time.
• Inspect shell variables such as HTTP_PROXY, HTTPS_PROXY, and NO_PROXY if Cursor is launched from a terminal or development launcher.
• After changing environment variables, close all Cursor processes and launch a new session; already running processes do not always inherit new values.

Do not assume that changing the browser proxy changes an already running Cursor process. Browser extensions, per-application settings, and desktop launch environments can each use a separate proxy path. The most reliable comparison is to observe the Clash connection log while the exact Cursor action is performed.

Tune DNS, TUN, and connection stability only after routing is known

DNS is often blamed for every timeout, but it should be tested methodically. If the Clash log shows that the hostname never resolves, compare the configured DNS mode and upstream resolvers. If the hostname resolves quickly but the outbound connection times out, changing DNS may not help. If TUN mode is enabled, DNS requests may be intercepted and resolved by mihomo; if only system proxy mode is enabled, some applications may resolve domains outside the proxy path.

For a first comparison, turn off TUN and use system proxy mode. This limits the test to applications that honor the system proxy, including many desktop web and Electron applications. If Cursor works in this state, inspect TUN’s virtual interface, auto-route, strict-route, DNS hijacking, and operating-system permission settings one at a time. If Cursor fails in both modes but browsers work, return to the application proxy and rule checks.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

The fragment above illustrates common mihomo DNS fields, but it is not a drop-in recommendation for every network. The resolver addresses may be blocked or unsuitable in your region, and fake-ip behavior can interact with software that expects real address records. Make a backup before changing DNS mode. If a configuration is supplied by a provider, use its documented override mechanism instead of editing generated YAML that will be overwritten during the next update.

Avoid misreading long-lived AI requests

AI coding responses may be streamed instead of returned as one short response. A node can successfully open a connection but interrupt it during a long response because of congestion, connection limits, idle timeouts, or unstable Wi-Fi. Test the same request on a stable network, with a different node in the same region, and with a smaller prompt. If short responses work but longer generations fail, the issue may be connection stability rather than basic reachability.

Do not lower every timeout value as a first response. A short client timeout can make a slow but usable connection appear broken, while an excessively long timeout only delays feedback when a node is unreachable. Prefer a reliable node, check packet loss and local network stability, and keep the application’s default timeout unless logs demonstrate a specific negotiation or idle-timeout problem.

FAQ: Cursor and Clash timeout troubleshooting