TUN Mode vs System Proxy: How Traffic Interception Actually Works

What Clash actually is: client, core, and configuration

Starting with Clash is easier once three separate pieces are kept apart: the client, the core, and the configuration. Many beginner guides use these words as if they meant the same thing, which makes a simple setup sound much more mysterious than it is.

A Clash client is the application you open and operate. It provides the interface for importing profiles, selecting proxy groups, enabling the system proxy, viewing logs, and changing settings. Examples include Clash Verge Rev on Windows and macOS, Clash for Android on mobile devices, ClashX on macOS, and Mihomo-compatible clients on several platforms. The client is the visible part, but it is not necessarily the component that performs every routing decision.

The core is the engine that reads the configuration and handles traffic. Modern clients commonly use the Mihomo core, formerly known in the ecosystem as Clash Meta. The core understands fields such as proxies, proxy-groups, rules, DNS settings, and optional TUN settings. Two clients can look completely different while using the same core and a similar configuration format.

The configuration is the instruction set. It tells the core which proxy servers exist, how groups should behave, whether a domain should go direct or through a proxy, which DNS mode to use, and which local ports to open. A subscription usually supplies a remotely generated configuration or node list. It does not automatically mean that every application on your device is now proxied.

Choosing a client: match the platform and the job

There is no universally best Clash client. The practical choice depends on your operating system, whether you need TUN mode, how much configuration you want to expose, and whether you prefer a simple interface or detailed controls. A beginner should first choose a maintained client for the correct platform, then learn the common concepts that remain similar across applications.

For a first desktop setup, a client with a clear Profiles, Proxies, Logs, and Settings area is usually more useful than one with dozens of advanced switches hidden behind unfamiliar labels. On Android, the most important distinction is whether the application uses the system VPN service. A VPN-based mode can capture traffic from apps that ignore the Android proxy setting, but it also creates a stronger interaction with battery management and other VPN applications.

Do not select a client solely because a search result displays a recent-looking version number. A legitimate project can have forks, renamed builds, archived releases, and unofficial repackaging. Look for a project page that clearly identifies the maintained repository or release channel, describes supported platforms, publishes release notes, and uses a consistent application name. Avoid download pages that promise a “premium unlocked” build, disable security warnings, or require a separate downloader before the client can be installed.

Subscriptions and providers: what the link contains

A proxy subscription is normally a URL that returns configuration data from a provider. Depending on the provider and the selected format, the response may contain proxy definitions, proxy groups, routing rules, DNS settings, traffic information, or a converted profile designed for a particular client. The URL itself is not a proxy server. It is an address used to retrieve a profile, often with an account token embedded in the path.

A provider may publish one subscription link for several clients, or separate links for Clash, Mihomo, sing-box, or other formats. If the provider offers a format selector, choose the Clash or Mihomo-compatible option rather than copying a generic browser URL into a field that expects raw YAML. Some clients can convert formats locally, but conversion is not guaranteed to preserve every advanced feature.

There are four values worth checking after an import:

• Node count: confirms that the response contained usable proxy entries, although a large count does not prove that the nodes work.
• Group structure: shows whether the profile includes a manual selection group, an automatic latency group, a fallback group, or only individual proxies.
• Traffic and expiry information: some providers expose remaining data and expiration dates through response headers or profile metadata; others do not.
• Last update result: a successful HTTP download is not the same as a valid configuration. The client should also parse the content and display the expected proxies and groups.

Subscription links should be treated like passwords. Anyone who obtains the complete URL may be able to download your profile or consume the account quota, depending on how the provider authenticates requests. Do not paste the link into public issue trackers, screenshots, chat rooms, browser extensions, or online conversion tools. If a link has been exposed, use the provider dashboard to reset or regenerate it when that option exists.

proxies:
  - name: Example Node
    type: ss
    server: example.invalid
    port: 443
    cipher: aes-128-gcm
    password: redacted

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Example Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

The sample above is only a structure illustration. Real credentials, server names, ports, encryption parameters, and transport options must come from the provider. Do not invent values by copying a random example from another guide. A profile can parse correctly while still failing at the connection stage if even one protocol-specific field is wrong.

A safe first setup: import, test, and enable one layer at a time

The most reliable beginner workflow is deliberately conservative. Import the profile first, test a proxy from inside the client, then connect an application through the local port, and only afterward enable system-wide capture. Changing several layers at once makes it difficult to tell whether a failure comes from the subscription, the selected node, DNS, the local listener, or the operating system.

1. Install the correct build: choose the package for your operating system and CPU architecture. On ordinary Windows laptops, x64 is common; on newer ARM devices, use an ARM64 build when the project provides one. Keep the installer and application names consistent with the release page.
2. Open the client and inspect the core status: confirm that the Mihomo or compatible core is installed, selected, and running. If the interface reports that the core is missing, fix that before importing a subscription.
3. Add the subscription: open Profiles or Subscriptions, paste the provider URL into the subscription field, and trigger an update. Do not paste it into a rule editor or a general browser address bar by mistake.
4. Activate the profile: after parsing succeeds, select the imported profile as the active configuration. Confirm that the Proxies page contains the expected groups and that the Logs page does not show a YAML parsing error.
5. Choose a known group and node: start with a manual select group if one exists. Pick one node rather than enabling automatic selection immediately. This gives you a stable reference while testing.
6. Test the local listener: note the HTTP, SOCKS, or mixed port shown in Settings. A common HTTP port is 7890, but the actual value varies. The control-panel port, often 9090, is for API communication and is not the port that browsers use for proxy traffic.
7. Test one application: configure a browser or command-line tool to use the local HTTP or SOCKS port, or use the client's built-in system-proxy toggle. Confirm that a test request succeeds before enabling TUN mode.
8. Enable broader capture only if needed: use TUN mode when applications do not honor system proxy settings or when you require app-wide routing. Approve the operating-system permission, then test DNS and local network access again.

For a direct local-port test, replace the port with the value shown in your client:

curl -x http://127.0.0.1:7890 https://example.com -I

A returned HTTP header confirms that the local HTTP listener accepted the request, but it does not prove that every domain, application, or rule is configured correctly. If the command reports “connection refused,” check whether the core is running, whether the port is correct, and whether another process already occupies that port. If the request reaches the listener but fails upstream, inspect the selected node and the core logs.

Rules, DNS, and TUN: the three settings beginners meet next

Clash usually operates in rule mode, where each request is matched against a list from top to bottom. The first matching rule determines the outbound action. A rule might send a domain to a named proxy group, send local addresses directly, reject a connection, or fall through to a final rule. The final MATCH rule is especially important because it catches traffic that did not match anything above it.

• DOMAIN,example.com,Proxy matches one exact domain.
• DOMAIN-SUFFIX,example.com,Proxy also covers subdomains such as www.example.com.
• GEOIP,LAN,DIRECT commonly keeps local-network destinations direct.
• MATCH,Proxy sends all remaining traffic to the selected proxy group.

Rule order matters. If a broad rule appears before a specific exception, the exception may never be reached. For example, placing a general domain suffix rule above a more specific direct rule can cause the specific domain to use the wrong path. When a result looks unexpected, open the connection or log view and identify the matched rule instead of repeatedly changing nodes.

DNS adds another layer. The client may resolve a domain locally, forward the question through a configured resolver, or use fake-IP behavior that returns synthetic addresses and maps them back to domain names inside the core. Each mode has trade-offs involving compatibility, privacy, local-network discovery, and application behavior. A DNS problem can look like a dead proxy: the node is reachable, but the requested hostname never resolves.

Start with the profile's DNS settings rather than copying a large DNS block from a different configuration. Keep local devices, printers, and internal hostnames in a direct or fake-IP exclusion list when required by your network. If a banking application, captive portal, game, or local device stops working after changing DNS mode, test with the original profile before adding random resolvers.

TUN mode is different from system proxy. System proxy asks applications to send requests to Clash's local port; applications that ignore the operating-system proxy setting can bypass it. TUN mode creates a virtual network interface and routes packets through the core at a lower network layer, allowing it to capture many applications that do not support HTTP or SOCKS proxies. That broader coverage can also introduce more permission requirements, DNS interactions, VPN conflicts, and battery use on mobile devices.

Common beginner mistakes and a sensible troubleshooting order

The most common mistake is assuming that a successful subscription download means the service is ready. The URL may be reachable while the account is expired, the returned profile may be empty, or the client may have imported the profile without making it active. Check subscription status, node count, active profile, selected group, and core logs in that order.

The second mistake is testing with every feature enabled. TUN mode, custom DNS, automatic node selection, system proxy, and several rule providers can all be useful, but enabling them simultaneously removes your baseline. Disable the optional layers, test one local port with one node, and then add features one by one.

Another frequent error is confusing a control API port with a traffic port. The external controller address and secret allow a dashboard or management tool to communicate with the core. They do not make an application use the proxy. For application traffic, use the configured HTTP, SOCKS, or mixed port.

• No nodes appear: update the subscription, check the provider format, inspect the response error, and confirm the link has not expired.
• Nodes appear but all time out: verify the system clock, local internet access, subscription status, selected protocol settings, and whether the provider requires a specific transport.
• The browser works but a terminal does not: configure http_proxy and https_proxy, or pass a proxy option directly to the command. The browser's system proxy setting does not automatically configure every CLI tool.
• The terminal works but one application does not: determine whether that application supports HTTP, SOCKS5, system proxy, or only TUN-style capture. Check for its own proxy setting and restart it after changing the system proxy.
• TUN breaks local devices: inspect the TUN stack, route exclusions, DNS mode, and LAN bypass settings. Printers, routers, and private address ranges often need direct handling.
• Only some nodes fail: treat this as a node or provider quality issue first. If at least one node works, do not immediately reinstall the client or rewrite the entire configuration.

A maintainable routine for everyday use

Once the basic setup works, keep it predictable. Update the subscription only when necessary, read the update result, and confirm that the active profile has not silently changed. If the provider offers several profiles, name them by purpose rather than leaving several entries with identical labels. A clear name such as “Main desktop — rule profile” is easier to diagnose than a list of anonymous URLs.

Keep a small record of the local ports, the active mode, and whether TUN is enabled. This is particularly useful after a client update or a system restart. If the system proxy suddenly stops applying, compare the current port with the value stored in the operating-system settings. A client may be listening on 7890 while the browser is still configured for an old port.

Review logs without treating every warning as a fatal error. A rejected connection to a private address, a failed probe for one dead node, and a YAML parsing failure have very different meanings. Focus first on entries related to the request you are testing, then check the matched rule, DNS result, outbound group, and node response.

Finally, keep security and privacy expectations realistic. Clash routes traffic according to its configuration; it does not turn an untrusted provider into a trusted one. The provider may see connection metadata or operate the remote servers used for transport. Use subscription links carefully, avoid sharing credentials, and do not install builds whose origin cannot be established. A simple, understandable configuration with a verified client is a better starting point than a huge profile filled with settings that cannot be explained.