TUN is necessary when an app ignores the system proxy, UDP must be captured, or more system traffic needs rule-based handling. Apps such as browsers that follow the system proxy generally need no additional capture. Once you confirm the system proxy cannot cover the target traffic, enable TUN, DNS hijacking, and automatic routing according to the client documentation, then retest immediately.
First determine whether the target traffic needs TUN
If the target app already follows the system proxy, do not enable TUN first. Continue only when the request never appears in the connection list.
Can the target app configure an HTTP/SOCKS proxy?
Does the app's request never appear in the connection list?
Do you need to handle UDP, games, voice, or command-line tools?
Does the current system allow creating a TUN or VPN interface?
Once confirmed, enable it this way
- First confirm that the standard system proxy cannot meet the need(See System Proxy FAQ)
- Back up the configuration and record the original proxy settings before enabling TUN(See TUN device guide)
- Enable TUN, DNS hijacking, and automatic routing according to the client documentation
- After enabling it, use the connection list to confirm that the target request enters Clash
TUN is not a speed-optimization switch
TUN can conflict with other VPN software, enterprise security tools, or virtual adapters
On mobile devices, TUN usually appears as system VPN permission