Proxy Node Timeout or Connection Failure: Step-by-Step Troubleshooting

1. Tell a speed-test timeout from a connection failure

FlClash latency tests typically send a request through the selected node to a specific test URL; they don't simply ping the node server. A “timeout” means the probe didn't finish within the allotted time. The cause could be the node's entry point, DNS resolution, the protocol handshake, or an unreachable test site. Note what happened before deciding which layer to check.

2. Local network: make sure direct connections work with traffic capture off

First, turn off the system proxy and TUN in FlClash, then try a site you can normally access directly. Check for a manually configured system proxy and clear or restore it if needed; simply quitting the client may leave proxy settings pointing to a local port. The browser will then keep trying to connect to a port that's no longer listening, making it look as if the entire network is down.

Check network access and system time

1. Complete network sign-in. Hotel, campus, and public Wi-Fi may require you to authenticate in a browser first. Check for a system prompt asking you to sign in to the network.
2. Check the system proxy. In Windows 11, go to Settings → Network & internet → Proxy and review the manual proxy and setup script. On macOS, go to System Settings → Network → your current network → Details → Proxies.
3. Correct the system time. In Windows 11, go to Settings → Time & language → Date & time. An incorrect date, time zone, or clock can interfere with TLS certificate validation and authentication in some proxy protocols.
4. Try another network. Keep the node the same and switch your computer from Wi-Fi to a mobile hotspot. If the connection works over the hotspot, check the original network's DNS, firewall, or outbound restrictions first.

If ordinary websites load directly, basic internet access is working—but that doesn't mean the node's port is reachable. Conversely, no ping response doesn't prove a server is offline: the server or its network may block ICMP. Next, test the actual server address and port listed in your subscription.

3. Subscription status: check the download, active configuration, and account

On the Configuration page in FlClash, find the subscription you're using and update it manually. Make sure that configuration is still selected. Button names may vary slightly by version, so follow the labels in your current interface. Once the update finishes, check the node list and selected policy group on the Proxies page. This helps rule out a stale configuration or a node from a different group.

Check these three layers

• Subscription request: HTTP 401 or 403 responses usually point to link credentials or server-side access restrictions; for a 404, check whether the URL has expired or its path changed. HTTP 200 only means the request succeeded—the response could still be a login page rather than a configuration.
• Configuration parsing: Check the logs for YAML syntax errors, unknown proxy types, or configuration load failures. Share links intended for other clients may not import directly as a complete mihomo configuration.
• Service account: Check the provider's website for the expiration date, remaining data, device limit, and maintenance notices. The full node list may still appear locally even if the account is no longer active.

If your configuration uses remote proxy providers, check whether those providers updated successfully too. A successful download of the main configuration doesn't guarantee that every remote resource was refreshed. To import it again, see the subscription import guide. For details on subscription sources, see subscription sources and usage.

4. System proxy and TUN: confirm traffic reaches FlClash

The system proxy mainly affects apps that follow the system proxy settings. TUN captures traffic through a virtual network interface and routing. Start troubleshooting them differently. Test one route at a time; enabling multiple clients, browser proxy extensions, and TUN at once makes the issue harder to isolate.

Desktop: verify the local proxy port first

Turn off TUN but leave the FlClash core running. Check the listening address, mixed port, and system proxy toggle shown in the client. The example below uses the local mixed port 7890; if your configuration uses a different port, replace it with the actual value. Don't guess the port based on a guide.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

In Windows PowerShell, use curl.exe at the start of the command to avoid older environments interpreting curl as a different command. Watch the FlClash connection log as you run it: an HTTP response means the proxied request reached its destination. If the local port refuses the connection, check that the port is listening, the core is running, and nothing else is using the port.

• Command works, browser doesn't: Check the system proxy, browser extensions, the browser's own proxy settings, and whether a different automatic proxy script is in use.
• Traffic reaches the client but takes the wrong route: Check the mode and policy group selected on the Proxies page. In rule mode, the destination may match DIRECT; a successful speed test doesn't mean webpages are using that node.
• No requests appear in the connection log: First check whether the app is bypassing the proxy. Don't keep changing remote node settings at this stage.

TUN: check permissions, routing, and VPN conflicts

Stop other VPNs or TUN-based clients, grant the permissions requested by your system, then enable TUN in FlClash on its own. Check the logs for errors creating the virtual interface, insufficient permissions, or failed route changes. Depending on your system and version, desktop setups may require administrator privileges or a service provided by the client.

On Android, approve the VPN connection request and check whether app access controls exclude the app you're testing. Also check for another “Always-on VPN” or “Block connections without VPN” setting. Don't leave the firewall disabled as a test. Instead, review its blocked-traffic logs and, if the client is trusted, create a narrowly scoped rule.

5. DNS settings: check node and destination domains separately

Proxy connections typically involve two kinds of DNS lookups: resolving the node server's domain to an entry IP, and resolving the website you're trying to visit. If the node's domain can't be resolved, the connection never reaches the proxy server. If the destination domain can't be resolved, the node's speed test may work while some webpages fail to load. Use the hostname shown in the error log to tell which lookup failed.

Compare with system DNS resolution

nslookup example.com

Replace the domain in the command with the website domain that's failing, or the node server's domain from your configuration. A timeout, no records, and an unexpected address point to different causes. nslookup only shows the result from the DNS path used for that query; it may not match mihomo's final result. With TUN DNS hijacking enabled, the client may intercept the query.

• Logs show a DNS resolution error: First check that the DNS upstream is reachable. With encrypted DNS, its server domain also needs to resolve during bootstrap, and the route for that traffic must work.
• Logs show repeated dialing or resolution loops: Check whether DNS requests needed to resolve the node's entry point are being sent through the same proxy before it has connected.
• Only the browser has problems: Check the browser's Secure DNS or custom DNS settings. Temporarily switch back to system DNS for comparison, then revisit the same URL.
• A Fake-IP address is returned: If the configuration uses Fake-IP mode, seeing an address in the common 198.18.0.0/16 range doesn't automatically mean DNS is broken. Check the address mapping and traffic-capture path next.

In mihomo, nameserver and proxy-server-nameserver serve different purposes; the latter resolves proxy node domains. If a subscription or override manages the configuration, back it up and check the effective configuration before editing the relevant field. Pasting in a random block of DNS settings can change the DNS mode, routing, and rule matching all at once.

6. The node itself: check the connection to its entry point and the protocol handshake

Once you've completed the local checks, investigate the remote node. Keep the node fixed and test it once on your usual network and once on a mobile hotspot. Then keep the network fixed and try a node with a different entry point. Two nodes with different names may share the same server, so compare server addresses rather than relying on region labels.

Read the logs by failure stage

For nodes that use a TCP entry point, you can check whether the actual server port is reachable in Windows PowerShell. This is an example of the command format; the domain is reserved for examples, so the result doesn't reflect the status of a real node:

Test-NetConnection -ComputerName node.example.com -Port 443

Replace these with the actual address and port from your configuration, and only test services you're authorized to use. A TcpTestSucceeded value of True means only that the TCP connection was established; it doesn't confirm that the password, TLS, WebSocket path, or full proxy protocol is correct. Nodes using UDP transports such as Hysteria2 or TUIC can't be evaluated with a TCP probe.

If TCP is reachable but the protocol handshake fails, first get a fresh configuration from your provider and verify the server name, credentials, and transport settings. For certificate errors, fix the system time, certificate chain, or server name configuration. Don't treat skipping certificate verification as a permanent solution.

7. Verify recovery: record the results, then restore your usual setup

Once the node works again, switch back to your normal rule mode and re-enable the system proxy or TUN—whichever traffic-capture method you actually need. Test a direct-access site, a site that requires a proxy, and a commonly used app. Check the connection log to confirm the outbound policy. If a site works in Global mode, that only confirms that the proxy route worked for that request; verify rule-based routing separately.

1. Record the environment: Operating system, FlClash version, core version, and the date and time the issue occurred. Use the version numbers shown in the client.
2. Record the comparison: Whether the result differs between your usual Wi-Fi and a hotspot, whether the same node works on another device, and whether other entry points work.
3. Record the route: Whether you used the system proxy or TUN, the actual listening port, the outbound mode, and the policy group matched by the request.
4. Save the error: Include only the log lines needed to reproduce the issue. Redact credentials and subscription links, and remove unrelated browsing records.

If every node fails on just one network, focus on that network's DNS and outbound restrictions. If one node fails across different networks and devices, send its entry-point details and relevant logs to your provider for investigation. Isolate the failing layer before changing settings to preserve a clear cause-and-effect trail. For more on traffic capture and routing, see the protocol guide.