Proxy Node Timeout While the Internet Works: A Troubleshooting Order for Subscriptions, DNS, and Connection Paths

1. First distinguish a timed-out latency test from a real connection failure

A browser opening familiar local websites while the Clash client marks a node as “timeout” is not contradictory. Local connectivity only proves that one direct route works; a node latency test usually also involves the proxy server, protocol handshake, and a specified test endpoint. A failure at any stage may be reduced to the same timeout message in the interface.

The client handles the interface, subscriptions, and configuration management; the core handles proxy connections, rules, DNS, and related processing. Clash and Clash Meta, now commonly called mihomo, differ in supported fields and behavior. Test entry points, default URLs, and timeout thresholds also vary between clients. During troubleshooting, record both the client version and the core version actually running instead of noting only the app name.

2. Check local connectivity: rule out captive portals and leftover proxy settings

Save the current settings first, then disable the client’s system proxy and TUN interception. If other VPN or proxy apps are running, exit them as permitted. Closing a window does not necessarily stop background services, and it certainly does not guarantee that system proxy settings are cleared. Check the system settings instead of relying only on the tray icon.

Confirm the direct-connection baseline on Windows

1. Open Windows 11 “Settings” → “Network & internet” → “Proxy” and record the previous state of the automatic setup script and manual proxy. Do not change settings deployed by your organization without authorization.
2. Visit two websites that normally work over a direct connection and make sure Wi-Fi is not stuck on a hotel, campus, or public-hotspot sign-in page. Opening the router’s admin page only proves that the local network is reachable.
3. Check “Settings” → “Time & language” → “Date & time” and confirm that the date, time zone, and time synchronization are correct. A significant clock error can cause TLS certificate validation to fail.

If curl is installed, run the following direct request in PowerShell. On Windows, use curl.exe to avoid PowerShell environments that interpret curl as another command. On macOS and Linux, you can use curl instead.

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://example.com/

--noproxy "*" tells curl not to use a configured explicit proxy, but it cannot bypass an active TUN interface, transparent gateway, or organizational network policy. Here, example.com is only a demonstration target; replace it with an address you know works directly. One unreachable example site does not prove that local connectivity is down. Five seconds is the connection-phase limit, while 15 seconds is the total limit for this operation; neither is measured latency.

3. Check subscription status: a successful update does not guarantee usable nodes

In the details of the configuration currently used by the client, confirm whether the latest update succeeded, whether the node count is as expected, and whether the client actually switched to that configuration afterward. Some clients continue running an old configuration, so seeing the node list still present does not prove that the subscription update just completed successfully.

• Account status: On the subscription provider’s account page, check the expiration date, remaining traffic, and device or concurrency limits. If the client does not display usage information, do not assume that sufficient traffic remains.
• Response status: 401 or 403 indicates an authorization or access-policy issue; 429 usually means stopping repeated updates and waiting; for 5xx, check the service side first.
• Response body: An HTTP 200 response may still contain a login page or error message. A complete YAML file, node-only data, and a single-node share link may not be handled by the same import entry point.
• Update route: Some clients let you choose whether subscription updates use a direct connection or a proxy. If the node required for the update has already failed, this can create a loop: the update needs a proxy, but the proxy needs the new subscription.

Only try changing the subscription update route when the client explicitly provides that setting. Then run one manual update and inspect the logs. Do not click Update repeatedly, and never paste a private subscription URL into a public online converter or diagnostic service. Tokens in the URL are often the access credentials themselves.

4. Check node parameters: separate port reachability from protocol handshakes

Select one failed node and verify its protocol, server, port, and authentication parameters. For nodes using TLS, WebSocket, or gRPC, also verify the server name, transport type, path, or service name supplied by the provider. Extensions such as Reality require core support; do not copy fields from another protocol without checking.

Check the node server’s TCP port first

The following is an interactive Windows PowerShell check. Enter the real server address and port for the current node when prompted. Enter only a hostname or IP address for the server—without an https:// prefix—and do not enter a subscription URL.

$nodeHost = Read-Host "Enter node server address"
$nodePort = [int](Read-Host "Enter node port number")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed

Run this check from a direct-connection baseline with interception such as TUN disabled; otherwise, the result may pass through an existing proxy. TcpTestSucceeded: True only proves that this TCP connection was established successfully. It does not prove that the password, UUID, TLS, or proxy protocol is correct. If the result is False, continue by checking address resolution, the remote listener, and restrictions in the network path.

This is not a general-purpose test for UDP nodes. Proxy protocols based on QUIC, for example, primarily use UDP, so a failed TCP port test does not prove that they are unusable. Likewise, ping tests ICMP; a server that does not respond to ICMP may still provide proxy service normally.

• The port connects, but the log reports an authentication failure: verify the account and node parameters before changing DNS.
• A certificate-name mismatch appears: verify the server name, system time, and server certificate. Do not disable certificate verification as a routine fix.
• Only one network fails: if permitted, switch the same device to a mobile hotspot and retest, recording the difference. A single network switch is still not enough to establish that the carrier is imposing a restriction.

5. Troubleshoot DNS: verify the node domain and target domain separately

A proxy connection may involve at least two kinds of domains: the node server’s own domain and the target domain the browser is trying to reach. If the former fails to resolve, the connection usually has not reached the node yet. How the latter is resolved depends on the protocol, DNS settings, and how traffic enters the core.

Run the following command in the PowerShell window from the previous step to observe how the system resolves the node domain. If server is already an IP address, you can skip this step.

Resolve-DnsName -Name $nodeHost -Type A
Resolve-DnsName -Name $nodeHost -Type AAAA

The absence of an AAAA record is not necessarily an error, and the presence of one does not mean that the current network has a working IPv6 route. If the log shows a connection attempting an IPv6 address and timing out while the IPv4 path works, check the IPv6 path and the core’s address-selection settings instead of immediately disabling IPv6 system-wide.

Why can system resolution succeed while the core still reports an error?

• The core may have its own DNS handling enabled and use different upstream servers, so a successful system command cannot replace the core logs.
• An encrypted DNS upstream may itself require domain resolution or a proxy channel. Misconfiguration can create a startup dependency loop.
• Rules or overrides may have changed DNS routing, so the active configuration may not exactly match the subscription file.

Some mihomo versions support proxy-server-nameserver to specify the upstream used to resolve node server domains. Whether to use it should be confirmed against the actual version and the complete DNS configuration. Do not add it to every Clash configuration without checking. For the relationship between fields, see the DNS section in the configuration reference.

After changing DNS, reload the configuration using the method supported by the client and establish a new test connection. Windows ipconfig /flushdns clears only the system DNS cache; it does not also clear browser or core caches or existing connections.

6. Check proxy interception: isolate system settings with a local port

Once the node and DNS show no obvious problems, check whether application requests are entering the core. The system proxy affects only apps that follow that setting. TUN takes over traffic through a virtual network interface and routing, requires the appropriate system permissions, and may conflict with routes from another VPN. Enabling TUN does not automatically repair a failed node, nor does it guarantee that all traffic enters the proxy.

The commands below assume that the HTTP or mixed listener in the active configuration is 127.0.0.1:7890. 7890 is a teaching example, not a fixed value for every client; confirm it in the active configuration or listener information first. If the port requires authentication, provide credentials locally as documented by the client, and remove sensitive content before sharing records.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

This command connects explicitly to the local proxy and does not depend on whether the browser uses the system proxy. The empty --noproxy list overrides existing proxy-bypass settings. Still inspect the matched rule and final exit in the connection record: even if the request enters the local port, it may be routed to DIRECT, which is not proof that the node itself works.

For diagnosis, you can briefly switch to Global mode and explicitly select a test node, but record the original mode and restore Rule mode afterward. Existing connections may continue using the old exit, so close old test connections and start new requests after switching. Do not use Global mode to hide rule-configuration errors long term.

7. Test endpoints and logs: identify where the timeout occurs

If the explicit proxy can reach the actual service target while the client’s latency test still times out, check the test URL first. The test service may be down, may limit frequent requests, or may be unreachable from certain exits; some implementations also verify the expected HTTP status code. Do not delete the entire configuration based on one red latency label.

Change only one test condition at a time

1. Record the current test URL and threshold. If the interface allows it, temporarily change 3000 milliseconds to 10000 milliseconds, then test the same node three times. This is a diagnostic setting, not a recommended latency standard.
2. Use a small HTTPS target that you are authorized to access and that responds reliably for comparison. Changing the target helps distinguish a test-service failure; it is not about choosing an endpoint that always returns success.
3. For targets that do not support HEAD, change -I in the curl command to -o NUL to send a normal GET and discard the response body; on macOS and Linux, use -o /dev/null.
4. Check the core logs and connection records together to confirm that the accessed domain, matched rule, policy group, and actual node are consistent.

curl exit code 7 usually means that a connection could not be established, 28 indicates an operation timeout, and 60 is related to certificate verification failure. None is a universal “node offline” code. When using an HTTP proxy to access HTTPS, 200 Connection established in the output only means that the CONNECT tunnel stage succeeded; you must also inspect the subsequent TLS and target HTTP response.

Contexts such as lookup, dial tcp, and handshake in the logs help identify the stage involved, but do not capture only the final “timeout” line. Keep records from the same time window and label the test target. Restore the normal log level promptly after temporarily increasing it to avoid accumulating access records.

8. Restore settings and prepare a useful report

After troubleshooting, restore the original rule mode, DNS settings, and interception method, and check whether the automatic policy group needs to be enabled again. Do not treat a longer timeout, a temporarily fixed node, or paused TUN as the final configuration. Final verification should include at least one newly established web connection and the application scenario that originally failed.

• Environment: Operating system, architecture, client version, actual core version, and the network type when the issue occurred.
• Scope: All nodes or one node, all targets or one target, and whether the system proxy and TUN behave differently.
• Evidence: Exact test time, port used, matched rule, actual exit, and a redacted error context.
• Actions taken: Subscription update time, account-status checks, DNS results, comparison after switching networks, and whether the original settings have been restored.

Before sharing screenshots or feedback, cover subscription URLs, tokens, passwords, UUIDs, and server information you do not want to disclose. If the same node cannot complete a handshake on multiple networks, send redacted records to the subscription provider. If the explicit proxy works but client interception does not, report the issue to the relevant client project instead. Finding the maintainer responsible for the failing layer is more likely to produce an actionable fix than repeatedly reinstalling.