Choose a traffic capture method, then check your proxy rules

  • Browsers and everyday web traffic: Start with the system proxy and confirm the application uses your operating system’s proxy settings.
  • curl, Git, and developer tools: Configure the proxy port explicitly first. Consider TUN if a tool doesn’t support proxies or you need system-wide traffic capture.
  • Games, voice chat, and UDP apps: Consider TUN first, and verify that the outbound protocol, proxy node, and network path support UDP.
  • Using a corporate VPN, containers, or virtual machines: Check your routes and DNS first. Avoid stacking multiple traffic capture tools without checking for conflicts.

Clash Meta generally refers to the mihomo core ecosystem. The client interface imports subscriptions, manages configuration, and controls settings; the core receives connections, matches rules, and establishes outbound connections. System proxy and TUN are two different ways traffic enters the core—not separate subscriptions or proxy nodes.

System proxy: applications connect to a local port

The system proxy toggle usually adds a local proxy address to the operating system settings, such as 127.0.0.1:7890. Applications that honor this setting send requests to that port. Make sure the port matches the client’s active configuration; 7890 is an example, not a universal default.

mixed-port: 7890
allow-lan: false
mode: rule

This configuration lets mihomo accept HTTP and SOCKS proxy requests on a mixed port, but it does not enable the system proxy in the operating system. The client’s “System Proxy” button handles that separately. The system proxy interface usually expects an HTTP proxy port; that doesn’t mean every program on the system will automatically use SOCKS.

Why browsers usually work

On common desktop systems, Chrome and Edge usually read the system proxy settings. Firefox may use its own network settings. Check Settings → General → Network Settings → Settings and make sure “Use system proxy settings” is selected. Browser extensions can also override proxy settings, so check their proxy permissions when troubleshooting.

Why command-line tools often connect directly

Each command-line program handles network access differently, so don’t assume it reads the desktop proxy settings. Test with an explicit proxy option first to distinguish “the tool isn’t using the proxy” from “the node can’t connect”:

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

To use a proxy in the current shell session, set the environment variables below. HTTPS requests still pass through an HTTP proxy using a CONNECT tunnel, so https_proxy can also use an http:// URL.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# Clear the current session settings after testing
unset http_proxy https_proxy

These commands work in common POSIX shells, not in PowerShell. Not all programs honor these environment variables; some developer tools require separate proxy settings. For a SOCKS test that resolves the destination hostname through the proxy, use curl --proxy socks5h://127.0.0.1:7890. The h means the proxy resolves the destination hostname.

TUN: capture IP traffic through a virtual network interface

TUN creates a layer 3 virtual network interface in the operating system, then uses routing rules to send eligible IP traffic to mihomo. Applications can create TCP or UDP connections as usual without needing to understand the HTTP proxy protocol. The core then decides whether to connect directly, block the traffic, or send it through a proxy node.

TUN generally captures more traffic than the system proxy, but it isn’t a universal “capture every app” switch. Route exclusions, other VPNs, network namespaces, virtual machine networking, and operating system permissions can all affect what it actually captures.

Minimal configuration example

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  • enable: Requests that TUN be enabled. Creating the interface also depends on permissions and the runtime environment.
  • stack: mixed: Selects a mixed network stack, which typically uses the system stack for TCP and gVisor for UDP. This is not a proxy node protocol.
  • auto-route: Automatically configures the required routes. Don’t blindly leave the default behavior enabled if it conflicts with another VPN.
  • auto-detect-interface: Helps identify the outbound interface. With multiple network adapters or a VPN, verify which interface is actually selected.
  • dns-hijack: Sends matching traditional DNS requests to the core’s DNS module. It doesn’t decrypt DoH or DoT traffic inside apps.

Windows usually requires administrator privileges or a service component installed by the client. Linux typically needs the appropriate network permissions and a TUN device. macOS uses the authorization mechanism provided by the client. Menu labels vary between clients, so confirm that service mode or the required permissions are set up before enabling TUN. A switch in the On position doesn’t prove the virtual interface and routes were created.

How TUN and system proxy handle browsers, command-line tools, and UDP

Traffic type System proxy TUN mode
Browser HTTP / HTTPS Captured when the app uses system settings Captured when covered by routing rules
Command-line tools such as curl and Git Often requires a proxy option, environment variable, or tool-specific setting Usually no need to configure a proxy port in each tool
Games and voice chat over UDP Usually not covered by a standard HTTP system proxy Can capture traffic, but the outbound path must support UDP
Local network and printers Depends on the proxy bypass list Depends on route exclusions and direct-connection rules
Containers and virtual machines Usually requires configuration in each environment Depends on the virtual network topology and forwarding path

Capturing UDP traffic doesn’t mean the node can forward it

Games and voice chat commonly use UDP. Browsers also use QUIC for HTTP/3, typically over UDP port 443. TUN can capture this traffic, but the node protocol, client-side node configuration, server support, and network provider must all allow it. Standard HTTP proxies generally can’t forward this UDP traffic directly; SOCKS clients with UDP support provide a separate, explicitly configured proxy route.

So “web browsing works, but the game doesn’t” doesn’t necessarily mean TUN is broken. Find the game’s destination, protocol, and final policy in the connection log, then check whether the node supports UDP. A node latency test usually reports the result for a single test destination; it doesn’t prove that game traffic over UDP can get through.

How DNS, fake IP, and rule matching work together

Both system proxy and TUN need to handle domain names, but they get that information differently. HTTP CONNECT and SOCKS domain requests can pass the destination hostname directly to the proxy. TUN initially receives IP packets. To match domain-based rules reliably, the core needs to associate domains with IPs using DNS mappings, sniffing, or similar methods—it can’t reliably infer a website’s name from its IP address alone.

In fake-IP mode, the core can return a synthetic address in the 198.18.0.1/16 range to the app and keep a mapping to the real domain. When the connection reaches the core, rules can then match against the domain. This range isn’t a proxy node’s exit address, and a reserved address in a DNS response doesn’t by itself mean DNS resolution failed.

Three common edge cases

  1. Encrypted DNS built into an app: When a browser looks up DNS over HTTPS, a standard port 53 hijack can’t read the query. For troubleshooting, temporarily use system DNS consistently and compare the results.
  2. Stale DNS cache: After switching modes, an app may still use a previously cached real or synthetic IP address. Restart the app under test, clear the system DNS cache if needed, then open a new connection.
  3. Local network names: Router admin pages, NAS devices, and corporate intranet domains may require a specific internal DNS server or a fake-IP filter for the relevant domains. Adding a direct-connection rule alone may not fix DNS resolution.

On Windows, run ipconfig /flushdns to clear the system DNS cache. This won’t automatically clear every app’s internal cache. If browser and command-line results differ, check their DNS settings and connection logs separately. Don’t change DNS, nodes, and rules all at once.

Verify traffic capture in four steps

1. Keep the rules and node fixed

Stay in Rule mode and manually select an available node. Pause automatic policy group switching during the test so a node change doesn’t affect the results. Note the client’s active port, such as 7890, and confirm that the policy group names in your subscription match those referenced by the rules.

2. Test the system proxy by itself

Turn off TUN and enable the system proxy. Open a new browser connection, then run the explicit curl --proxy command shown earlier. In the connection panel, check whether the test request appears, which rule it matched, and which policy was used. If the browser works but there’s no connection log for a regular curl request, the command-line tool probably isn’t using the proxy.

3. Test TUN by itself

Turn off the system proxy, clear proxy environment variables set in the test terminal, and enable TUN. If you previously configured ALL_PROXY, all_proxy, or a tool-specific proxy, check those too. Then run a command without proxy options so a successful explicit proxy test doesn’t get mistaken for a successful TUN test:

curl --connect-timeout 10 -I https://example.com

On Windows, use route print; on Linux, use ip route and ip rule; on macOS, use netstat -rn to inspect routes. Automatic routing differs by platform, so you won’t necessarily see the same default route everywhere. The key is that the virtual interface exists and the target traffic reaches the core as expected.

4. Check the rule and exit route

First confirm in the connection log that the request reached the core, then check the final policy. If a rule specifies a proxy, compare your exit IP using a trusted IP lookup service. If the rule specifies a direct connection, an unchanged exit IP is expected. A single webpage, a status bar icon, or a node latency reading can’t by itself prove the entire route is working correctly.

Choosing a mode and restoring connectivity

Can I enable system proxy and TUN at the same time?

Yes, but for troubleshooting, use only one traffic capture method at a time. With both enabled, some apps may connect to the local proxy port while others use TUN, making it harder to trace where connections enter. With a normal configuration, this doesn’t mean the same request must pass through two remote proxies. Watch for loops caused by another VPN, incorrect outbound routes, or DNS settings.

NAS or corporate VPN stops working after enabling TUN

Turn off TUN first and confirm the original network works again. Then check your local network subnets, corporate VPN routes, and internal DNS. A DIRECT proxy rule determines how the core routes traffic out; a route exclusion determines whether traffic enters TUN. These operate at different layers. Choose a fix based on your network topology—don’t send every private IP range through a proxy node indiscriminately.

Internet access still fails after closing the client

  1. Check whether the system proxy still points to 127.0.0.1:7890, where nothing is listening. Turn off any leftover manual proxy setting if needed.
  2. Use the client to shut down TUN normally. Confirm that the virtual interface and automatic routes have been removed before exiting the app.
  3. Check your VPN, network interfaces, and DNS settings, and restore the state you recorded before testing. Don’t clear all system routes.

Before making further changes, see the rules, DNS, and TUN sections in the full documentation. Keep a recoverable copy of your current configuration and change one section at a time to pinpoint the layer where the problem occurs.