Clash Connection Timeout: Troubleshoot Subscriptions, DNS, Ports, and System Proxy

1. Identify Whether the Issue Is a Node Timeout, Subscription Failure, or Unproxied Traffic

If you see “Timeout,” don’t reinstall the client just yet. A failed latency test only means that one test didn’t finish within the allotted time. A subscription that won’t update, a browser that isn’t using the proxy, and an unreachable remote node are three different failure paths. Pin down the symptom first so you know what to change next.

Pause any other proxies or VPNs, then note the client name and version, core version, and active config name. Clash is a common name for a family of proxy cores and their configuration ecosystem; many current clients use mihomo, the core that continues the development of the original Clash.Meta. Core capabilities and supported protocols and fields vary, so don’t assume that a menu or config option in one client is standard across all products.

Symptom	Check first	What it tells you
Subscription update returns 401 or 403	Provider account and subscription access	The request was denied; that doesn’t mean the node server timed out
Every node test times out	Config loading, network, and DNS	A shared dependency is more likely to be the cause
Only one node times out	That node’s address, port, and service status	Other nodes work on the same device
Node latency test succeeds, but browser pages won’t load	System proxy, rules, and connection logs	A successful test doesn’t mean app traffic reached the core
Web pages load, but the latency test fails	Test URL and timeout setting	The test target may be unreachable or blocked

2. Check Your Internet Connection, System Time, and Subscription

Rule out captive portals and incorrect system time

Temporarily turn off the client’s system proxy and TUN, then test a website that normally works without a proxy. If your school, hotel, or public Wi-Fi requires a web sign-in, complete that first.
On Windows 11, go to Settings → Time & language → Date & time. Check “Set time automatically,” then select “Sync now.” On macOS, go to System Settings → General → Date & Time and check that the date and time are set automatically.
Switch from your current Wi-Fi to a mobile hotspot without changing the config or node, then test again. If the connection works only on the hotspot, that points to an issue with the local network path or its policies.

A badly incorrect system clock can cause TLS certificate validation to fail and may affect time-based authentication. If the logs show certificate has expired or certificate is not yet valid, check the device clock and certificate validity period first. Don’t hide the problem by disabling certificate checks. connection refused usually means the connection was actively rejected; it’s not the same as a request that waits until it times out.

Make sure the subscription updated successfully and is active

Using the common Clash Verge Rev interface as an example, open “Subscriptions,” find the active subscription card, and update it. Then confirm that the config is selected. Button locations may vary by version; check the update result, last-updated time, and whether the node list changed as expected. Downloading a new file doesn’t mean it loaded successfully. If the config has syntax errors, the client may keep using the previous working config.

Returns 401 or 403: Check your provider account, subscription validity, and whether the subscription URL has been reset. The HTTP status code alone doesn’t prove that your plan has expired.
Returns 200 but import fails: Check whether the response is actually a sign-in page, an error message, or an unsupported format instead of a valid Clash YAML config.
Nodes are still listed but none work: Old configs can remain saved locally, and node names may not disappear when an account expires. Check remaining data and the expiration date in your provider account.
Update through the proxy fails: If the client offers a proxy option for subscription updates, check whether you’re stuck in a loop where you must connect to a dead node before you can update. Try updating directly, based on your current network conditions.

Subscription URLs often contain access tokens. Don’t post the full link in public forums, screenshots, or log attachments. If you need to import it again, copy the current valid URL from your provider account and keep the original config for comparison.

3. Check Local Ports and Confirm the Core Is Listening

Apps must connect to the port that’s actually listening. The examples below use 127.0.0.1:7890; 7890 is not a fixed default for every client. Check mixed-port, port, and socks-port in the client settings or active config, then substitute the actual port in the commands. external-controller is a management interface, not a proxy port for web traffic.

Windows: Check the listening port and owning process

Open PowerShell and run these commands. The first checks whether a local TCP connection can be established; the second lists the ID of the process listening on the port.

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

TcpTestSucceeded : True only means the port is reachable. In Task Manager, open the Details tab and find the process with the matching PID. If it belongs to another proxy app, there may be a port conflict. If nothing is listening, check for a core startup or config loading error before changing remote nodes.

macOS and Linux: Check the same listening port

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

Process details may be restricted by system permissions. If the logs show address already in use, quit the process using the port or change the proxy port to an unused one, such as 7893. Update the system proxy, browser extensions, and terminal proxy environment variables too; changing only the YAML isn’t enough.

4. Use an Explicit Proxy to Separate System Proxy Issues from Node Failures

Once the local port is reachable, make a request with the proxy explicitly specified. This avoids the uncertainty of whether an app reads the system proxy, but the client’s current mode and routing rules can still affect the result. To test a specific node, temporarily switch to Global mode and select that node explicitly. Restore your original rule mode when you’re done.

# Windows PowerShell; use curl.exe to avoid the same-name alias in older environments
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

Here, 5 seconds is the connection timeout and 15 seconds is the overall request limit; neither is a measured latency. The example command assumes the port supports HTTP proxying. If it only accepts SOCKS connections, use the corresponding port and the socks5h:// scheme. example.com is just a fixed test target. If the result looks unusual, cross-check with another HTTPS site you know works.

Can’t connect to 127.0.0.1: Check the local listener again; the remote node isn’t involved yet.
You only see 200 Connection established: This means the HTTP proxy established a tunnel. Check whether TLS and the final website response complete as well.
You get a final HTTP response: This request made it through the chain. Even if the response is 403 or 405, distinguish the website’s access policy from a connection timeout.
Explicit proxy works, but the browser doesn’t: Check browser extensions, system proxy bypass lists, and the app’s own proxy settings first.

Make sure the system proxy toggle matches the OS settings

On Windows 11, go to Settings → Network & internet → Proxy and check that the manual proxy address and port match the client. On macOS, go to System Settings → Network → select your current connection → Details → Proxies, then check Web Proxy and Secure Web Proxy. Don’t leave an unknown automatic proxy script enabled alongside a manual proxy.

Open the client’s Connections and Logs pages, then refresh the web page. If there’s no matching connection, traffic may not have reached the core, or the browser may have reused an existing connection. Close the page, reopen it, and check again. If the log shows DIRECT as the target, check which rule matched instead of assuming the proxy node has failed.

5. Distinguish DNS Resolution Failures from fake-ip Issues

Check DNS at two levels: can the node server’s hostname resolve, and how are website hostnames resolved? If the node address itself can’t be resolved, testing another website won’t help. If website lookups are failing, that doesn’t prove all nodes are broken.

Check the hostname and failure stage in the logs

Open the client logs, temporarily choose a log level that shows connection errors, and repeat the failed action once. Note the hostname, port, and time shown in the error. no such host usually points to a name resolution failure. For i/o timeout, use the surrounding log entries to tell whether the timeout happened during a DNS query, a connection to the remote server, or a protocol handshake. A screenshot of the final “Timeout” alone often isn’t enough.

# Windows: check the system resolution path
Resolve-DnsName example.com

# macOS / Linux: use nslookup if available
nslookup example.com

These commands mainly verify the system’s resolver path; their results may differ from mihomo’s built-in DNS. If system resolution works but the core still reports a lookup failure, check the active config’s dns section, whether the DNS servers are reachable, and the node hostname resolution settings. Repeatedly clearing the browser cache won’t help.

A fake-ip address is not the node server’s address

In fake-ip mode, the core may assign a synthetic address from the configured pool; a common example is 198.18.0.1/16. An app receiving one of these addresses doesn’t mean DNS has been poisoned. The core uses its mapping to recover the hostname, then applies rules and makes the connection. Check the active config to see whether this range is actually in use.

Apps still use synthetic addresses after TUN is turned off: They may be using a cached DNS result. Quit the affected apps, restore the original resolution path, then reopen them. On Windows, run ipconfig /flushdns to clear the system DNS cache.
Only one LAN app has issues: Check whether it relies on real IP addresses, LAN discovery, or its own DNS. Adding exceptions for the specific hostnames involved is easier to maintain than excluding every domain from fake-ip.
Timeouts started after switching to encrypted DNS: Check whether the DNS service is reachable and whether its hostname needs bootstrap resolution. Encrypted DNS isn’t guaranteed to work on every network.

To compare, temporarily switch to another DNS mode supported by the client and core in a backed-up config, then load it and restart the app you’re testing. Change one thing at a time. Remote subscription updates may overwrite direct edits, so use the client’s override or merge mechanism for lasting changes. For specific fields, see the configuration reference.

6. Test TUN Separately and Check for Conflicts with Other VPNs or Network Tools

If the system proxy works but TUN doesn’t, check the traffic interception path first.TUN handles traffic through a virtual network interface and routing, so it covers different traffic from the system proxy. Enabling it won’t fix an expired subscription or a remote server that’s down. Temporarily pause other VPNs, accelerators, and virtual network adapter tools during testing to avoid multiple apps changing the default route or DNS at the same time.

Turn off TUN but leave the system proxy enabled, then run the explicit proxy request from the previous section. If it succeeds, the local proxy entry point and selected node can at least complete that request.
Turn off the system proxy, enable TUN, and use a regular browser to visit the same test website while checking the connection log.
If the second test fails, check whether the client reports that a service isn’t installed, permissions are insufficient, or the virtual interface couldn’t be created. Desktop clients may require the relevant system service to be installed or started first.
Restore the original toggles. Make sure the network still works normally after you quit the client, then decide whether to keep TUN enabled.

On Android, typically only one app in a user profile can use the system VPN service at a time; starting another VPN may replace the existing connection. Network extensions on iOS are also subject to OS and client implementation limits. On mobile, check the system VPN status and client logs first rather than repeating the desktop 7890 port checks.

If only some large web pages, uploads, or videos stall under TUN while small requests work, then look into path MTU, UDP support, or protocol-specific issues. Don’t copy MTU values from an unknown source. Record the reproducible target, traffic type, and network first, then compare one setting at a time.

7. Verify the Remote Node and Latency Test Target

Only assess node reachability once you have clear evidence that the local listener, traffic interception, and DNS are working. Keep the same device, network, and test website, and switch only the node. If one node fails repeatedly while another succeeds repeatedly, the problem is more likely with the failing node or the network path to it.

A latency test doesn’t prove the node is fully usable

A client’s latency test usually requests a specific URL through the node. The test URL, timeout threshold, and server response policy can all affect the result. If the client lets you set a timeout, temporarily raise it from, say, 3,000 ms to 8,000 ms for comparison. This gives the request more time; it doesn’t make the connection faster. Passing a lightweight test doesn’t guarantee that video, UDP, or long-lived connections will work.

A reachable remote TCP port only proves that the TCP handshake succeeded; it doesn’t prove that authentication, TLS, or the proxy protocol handshake will succeed. Some nodes use UDP-based transport, so a TCP port test may not apply at all. Don’t judge a node by whether ping succeeds: the server may ignore ICMP while the proxy service still works.

Only one node fails: Update the subscription, check whether the provider replaced the node, and look for maintenance notices.
Every node fails on one network, but works on a hotspot: Focus on outbound restrictions, DNS, and the route to the remote server on the affected network.
Both networks fail and the logs say the protocol isn’t supported: Check the config requirements against the core’s capabilities and update to a compatible version released by the client’s official source. Don’t rewrite protocol names at random.
The logs show an authentication or TLS error: Check the account, node parameters, and system time. Not every handshake failure is a network timeout.

8. Gather Details for Support and Restore Your Usual Settings

If the issue persists, prepare the details below before asking for help. This is more useful than simply saying “all nodes time out.” Keep only the relevant 30–60 seconds of logs around the failure, and remove subscription tokens, passwords, UUIDs, and other authentication details first.

Client name and version, core version, and operating system version.
When the issue occurred and your time zone, plus whether you were using Wi-Fi, Ethernet, or a mobile hotspot.
Whether the failure is a subscription update, node test, or access from a specific app.
The actual local proxy port, whether the correct process is listening, and the result of the explicit proxy request.
Whether system proxy and TUN are enabled, rule mode or Global mode, and the policy group that matched.
Results after switching nodes, networks, or test targets; change only one thing at a time.

When testing is done, restore your usual rule mode, original DNS settings, and any proxy toggles you need, then turn off temporary debug logging. Base your final diagnosis on repeatable evidence: is the port listening, does the request reach the core, does the hostname resolve, and does the remote handshake complete? Following these steps will usually narrow “Clash won’t connect” down to one issue you can address. If you’re new to the initial setup, start with the quick start guide. For common client issues, visit the Help Center.