Ten Common Questions When First Using Clash: Nodes, Modes, and Ports Explained

Ten practical answers for your first week with Clash, covering nodes, modes, port 7890, system proxy issues, DNS, TUN, and subscription updates.

1. Where do Clash nodes come from?

Bottom line: The Clash client reads configuration, applies traffic rules, and creates proxy connections; it does not generate nodes itself. Nodes usually come from a subscription URL provided by a service provider, or can be entered manually in a YAML configuration.

A usable configuration usually includes proxy nodes, proxy groups, rules, and DNS settings. With only a node list and no proxy groups, the interface may show servers but offer no “Auto” or “Fallback” selection. With rules but no nodes, proxy rules have no usable exit.

Subscription URLs versus ordinary web links

  • Subscription URLs are usually generated by a service provider. Paste them into the client’s configuration import field.
  • A subscription URL may return Clash YAML or a Base64 node list. The latter requires client support for that format or conversion by a trusted service.
  • A link opening in a browser does not mean Clash can parse it. A login page, plan page, or HTML error page is not valid configuration content.
  • Subscription URLs often contain identity parameters. Treat them like account credentials and do not post them in screenshots, forums, or public code repositories.

After importing, select the newly added configuration in the configuration list. In a common Clash Verge Rev 2.x interface, the path is usually “Subscriptions” → “New” → paste the URL → “Save,” then return to the subscription list and click the configuration. Different clients may call this section Profiles, Configurations, or Configuration Files, but the process is the same: add, update, and select.

2. Why does a successful subscription import still not work?

Bottom line: “Import successful” only means the client received the configuration. It does not mean a node is selected or that system traffic has been handed to Clash. Beginners most often miss these last two steps.

Check these four items one by one

  1. Configuration is active: The current item in the configuration list should be selected, not merely present in the history.
  2. A proxy group has a selection: Open the “Proxies” page and confirm that the main proxy group is not empty. Select a working node or an automatic testing group.
  3. Running mode is not Direct: During troubleshooting, start with Rule mode and avoid accidentally selecting Direct mode.
  4. Traffic entry is enabled: Ordinary browsers usually require the system proxy. Apps that ignore system proxy settings may require TUN.

You can also check the runtime log. If no new log appears while visiting a website, the request has not entered Clash; check the system proxy, the browser’s independent proxy, TUN, or port settings. If the log contains the request but shows timeout, connection refused, or DNS errors, then inspect the node, network, and DNS.

3. Which should you use: Rule, Global, or Direct mode?

Bottom line: Use Rule mode for daily work. Global mode is useful for temporarily checking whether traffic rules are the problem. Direct mode pauses proxy forwarding, but traffic usually still passes through the Clash core.

Mode How it works Suitable for Common misconception
Rule mode Matches rules from top to bottom and decides whether to direct, proxy, or reject Daily browsing, software updates, and local services together Outdated rules may send some domains to the wrong policy
Global mode Sends most requests through the selected proxy policy Determining whether rules are causing the problem It does not mean all operating-system traffic automatically enters Clash
Direct mode Requests access targets directly through the local network Temporarily disabling the proxy exit and comparing network behavior The system proxy may still be enabled

The key principle of Rule mode is “top to bottom, first match wins.” For example, after a domain matches a DOMAIN-SUFFIX rule, the later MATCH rule will not process it. The common final MATCH rule is a fallback for connections that matched nothing earlier.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy

If a website works in Global mode but not in Rule mode, the node itself is usually fine. Focus on the rule match result. Open the connection record and check whether the target domain used DIRECT, a proxy group, or REJECT, then update the configuration or adjust the relevant rule.

4. What is port 7890, and must it stay at the default?

Bottom line: 7890 is a common local proxy port in many Clash configurations, but it is not a fixed value required by every client. It may be configured as a mixed-port or used only for HTTP proxying. Check the current client runtime settings and YAML configuration for the actual value.

Configuration item Common port Purpose
mixed-port 7890 Accepts HTTP and SOCKS5 proxy requests on one port
port 7890 HTTP proxy entry point
socks-port 7891 SOCKS5 proxy entry point
external-controller 9090 Control interface for the GUI to read status and switch policies

9090 is not the proxy port for a browser. Setting the browser proxy to 127.0.0.1:9090 will usually result in a connection failure. With a mixed port, the proxy address is generally 127.0.0.1:7890. If the client shows another port, use the currently active value shown in its interface.

What to do when a port is already in use

When the log shows address already in use, bind failed, or a port conflict, first exit other proxy tools and restart Clash. If the conflict remains, open “Settings” → “Parameters” or “Settings” → “Port Settings” and change the mixed port to an unused port such as 7892 or 7893, then enable the system proxy again. If a browser proxy was configured manually, update its port as well.

After changing the port, do not check only the toggle state. Confirm in the log that the local listener has started, or check the client home page for the actual HTTP, SOCKS, and Mixed entry ports. Automatic system proxy settings usually follow the new port; manual settings do not update automatically.

5. Why do websites remain inaccessible when the system proxy is enabled?

Bottom line: First determine whether the request entered Clash, then identify where it stalled. An illuminated system proxy switch is only the starting point. An unavailable node, a rule routing traffic directly, DNS failure, or browser settings overriding the system can all cause the connection to fail.

A five-minute troubleshooting flow

  1. Open the client log or connections page and clear the current filter.
  2. Visit a target website in the browser and check whether its domain appears.
  3. If there is no log, disable any separate proxy extension installed in the browser and confirm that the proxy address is 127.0.0.1 with the same port as the client.
  4. If there is a log but the request matched DIRECT, temporarily switch to Global mode for comparison. If Global works, inspect the rules.
  5. If the log shows timeout, switch to a node with normal latency and test whether the local network can access an ordinary website.
  6. If the log shows DNS error, no such host, or a resolution timeout, check the DNS configuration instead of repeatedly changing ports.

Windows users should also check whether another application has rewritten the system proxy. A common path is “Settings” → “Network & Internet” → “Proxy.” When Clash manages the system proxy automatically, the manual proxy address generally points to the local loopback address. Before exiting the client, disable the system proxy so the operating system does not continue sending requests to port 7890 after the listener has stopped.

On macOS, open “System Settings” → “Network” → the current network → “Details” → “Proxies” to check the status. Usually, there is no need to manually enable multiple protocols while letting the client take over again; duplicate settings can create port mismatches. Prefer the client’s “Set as System Proxy” function for unified management.

6. What node latency is normal? Does a lower number always mean higher speed?

Bottom line: Latency measures the round-trip time for a test request; it is not the same as download speed. For daily browsing, 50–150 ms usually feels responsive, 150–300 ms remains usable, and sustained latency above 500 ms or repeated timeouts is a reason to try another node.

These figures are not fixed quality thresholds. Location, carrier, Wi-Fi signal, and the test address can all significantly affect the result. The same node may show 92 ms for one test URL and 180 ms for another; evening congestion may raise 110 ms to 260 ms. Test two or three times and judge the result together with actual browsing, video playback, and file downloads.

Common reasons for low latency but slow speed

  • The route from the node to the test address is short, but the route to the actual target is congested.
  • Server bandwidth is limited: the connection starts quickly, but sustained transfer speed is low.
  • Local Wi-Fi packet loss makes latency look normal occasionally while reducing stability.
  • The proxy group is showing a cached result from an earlier test, while the node’s current condition has changed.
  • UDP, video segments, or large file transfers use different paths from ordinary HTTP latency tests.

Automatic selection groups usually choose a low-latency node through periodic URL tests, while fallback groups focus more on whether the current node is available. The former suits everyday selection; the latter helps maintain connection continuity. Do not set the test interval too short. Checking every 300–600 seconds is generally enough; testing every few seconds creates unnecessary requests.

7. What is the difference between the system proxy and TUN mode?

Bottom line: The system proxy depends on applications reading the operating system’s proxy settings. TUN mode uses a virtual network interface to capture more IP traffic. Browsers and most desktop software can use the system proxy, while games, command-line programs, some store apps, and software with custom network stacks may require TUN.

Item System proxy TUN mode
How traffic is captured Applications read HTTP or SOCKS proxy settings A virtual network interface receives system network traffic
Permission requirements Usually works with standard user permissions Generally requires administrator privileges or service mode
Suitable applications Browsers and software that follows the system proxy Programs that ignore the system proxy and some UDP applications
Troubleshooting complexity Lower Requires checking routes, DNS, the virtual interface, and the firewall

When using Clash for the first time, get the system proxy working reliably before considering TUN. For a client using Mihomo 1.19.x configuration semantics, common TUN settings include enable, stack, auto-route, auto-detect-interface, and DNS hijacking. A graphical client usually installs a background service through “Settings” → “System Settings” → “Service Mode,” then enables TUN under “Settings” → “Network” or on the home page.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed is a common compatibility-focused choice. If a particular system has connection problems, test system or gVisor according to the client’s documentation. Do not overwrite the entire TUN and DNS sections without understanding the existing configuration, because the subscription may already provide suitable parameters.

8. Why does the browser work while games, terminals, or store apps bypass the proxy?

Bottom line: These programs may not read the system proxy, or they may use UDP, their own DNS, QUIC, or another networking method. If the browser works, the node and basic proxy entry are probably fine. Next, check whether the program’s traffic enters Clash.

Command-line tools often have their own proxy variables. To use a local HTTP proxy only for the current terminal session, set HTTP_PROXY and HTTPS_PROXY according to the tool’s support. Programs that support SOCKS5 can use 127.0.0.1:7890 or the SOCKS port shown by the client. Variable names and proxy protocols must match the program’s documentation; do not assume every tool reads system settings.

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890

Games and some store apps often use UDP, which a standard HTTP system proxy cannot carry directly. After confirming that the node supports the required transport, enable TUN and inspect the target IP, protocol, and matched policy in the connection list. If there are still no records after enabling TUN, check the virtual interface, route exclusions, and whether the application uses another network interface.

Also remember that Global mode only controls how connections that have already entered Clash choose an exit. It does not force every application into the core. Switching from Rule mode to Global mode cannot replace the system proxy or TUN. These are two different layers: the traffic entry determines “whether traffic enters Clash,” while the proxy mode determines “where it goes afterward.”

9. How should you handle subscription update failures, 404 errors, and timeouts?

Bottom line: A 404 is usually related to the URL or account status. A timeout is more likely caused by the network path, server response, or proxy update setting. Handle the error by type, and do not immediately delete a configuration that still works.

When you see 404, 401, or 403

  • 404: The subscription path does not exist, the URL has changed, or the server returned a generic error page. Copy the latest URL again from the service provider’s control panel.
  • 401: The identity parameter is invalid or missing. Sign in again to obtain a subscription URL.
  • 403: The server rejected the request, possibly because of account status, request frequency, or the access source.

When you see timeout or connection reset

First use a browser to test whether the subscription domain can establish a connection, but never publish the complete subscription URL. If the current network cannot access the subscription server directly, look for settings such as “Update through proxy” or “Use proxy for subscription updates.” If the server permits retrieval only through a direct connection, disable that option. Do not rapidly retry both methods, as this may trigger server-side rate limits.

The automatic update interval should not be too short. Node information does not change every minute; 1440 minutes is a common setting, while 360 minutes can be used when faster synchronization is needed. A five-minute interval creates unnecessary requests and may repeatedly overwrite the state during temporary network fluctuations. When an update fails, keep the last successful configuration and retry manually.

If the configuration suddenly becomes empty after an update, switch back to the previous local copy and check whether the response was an HTML login page, an error JSON response, or an incompatible format. When the client reports a YAML parse error, inspect the indicated line. Indentation, spaces after colons, duplicate keys, and unclosed quotes can all cause parsing failures.

10. What is the safest setup for the first week, and how can you recover from problems?

Bottom line: Keep the configuration simple. Start with Rule mode, one main proxy group, and the system proxy. Enable automatic testing, TUN, custom DNS, or scripts only after the browser works reliably. Verify real access after adding each feature.

A basic setup suitable for beginners

  • Clearly select the current configuration and keep a recent working local copy.
  • Use Rule mode and manually select a tested node in the main proxy group.
  • Let the client manage the mixed port automatically, for example 7890.
  • Manage the system proxy through the client instead of adding another browser extension.
  • Set the automatic update interval to 360–1440 minutes.
  • Use the information log level for daily work and switch temporarily to debug only when troubleshooting.
  • Enable TUN, script overrides, and custom DNS one at a time when there is a clear need.

Use this recovery order after changing too much

  1. Disable TUN, scripts, and manual overrides, keeping only the original subscription configuration.
  2. Switch back to Rule mode and select a node that has passed a connectivity test.
  3. Check the local mixed port and confirm that no other process is using it.
  4. Turn the system proxy off and on again so the operating system refreshes the proxy address.
  5. Visit the target site in a browser while watching the connection log.
  6. After basic access returns, add custom settings back one by one and record the effect of each change.

If every website becomes inaccessible after Clash is fully exited, the system proxy is probably still enabled. Restart the client and disable the system proxy, or open the operating system’s network settings and remove the manual proxy. If ordinary mainland China websites also become slower after enabling Clash, check whether the rules send every request to a proxy group or whether Global mode was selected accidentally.

You do not need to understand every configuration option during the first week. Start with four layers: the subscription provides the configuration, nodes provide connection exits, the system proxy or TUN brings traffic into Clash, and rules select the exit. Most “enabled but not working” problems can be located by checking these layers in order.

Download Clash Client Choose an installer for your system