Docs Config Tun

Tun

TUN mode creates a virtual network interface that takes over all system traffic, without needing per-app proxy support — currently the most recommended way to set up a system-wide proxy. This covers the top-level tun field's settings.

tun can also be configured under listeners, but that's an advanced use case; regular users should use the top-level tun field covered on this page.

Example Config

config.yaml YAML

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  device: utun0
  mtu: 9000
  strict-route: true

Core Fields

enableRequired

Enables TUN mode.

stackDefault: gvisor

The network stack — choose system/gvisor/mixed. If you don't run into compatibility issues, mixed is recommended: it uses the system stack for TCP (more stable, lower overhead) and gvisor for UDP, which usually gives the best experience. If your system firewall is enabled, the system/mixed stacks require manually allowing the core process.

deviceOptional

Sets the TUN interface name; on macOS this must start with utun.

auto-routeOptional

Automatically sets up global routing to direct system traffic into the TUN interface — almost always needed.

auto-redirectLinux only

Automatically configures iptables/nftables to redirect TCP connections; requires auto-route to be enabled, mainly used in router setups.

auto-detect-interfaceOptional

Automatically selects the outbound network interface; if your device has multiple active interfaces (e.g. both Wi-Fi and Ethernet connected), it's better to specify the interface manually rather than rely on auto-detection.

dns-hijackOptional

Redirects matched DNS requests to the core's built-in DNS module; the default syntax without a protocol is equivalent to udp://. macOS/Windows can't automatically hijack DNS requests sent to a LAN address; Android can't hijack them automatically either if "Private DNS" is enabled.

strict-routeOptional

Applies stricter routing rules on top of auto-route to prevent address leaks — also a prerequisite for DNS hijacking to work properly on Android. On Windows this may cause apps like VirtualBox to misbehave in some scenarios.

mtu / gso / gso-max-sizeOptional

mtu is the maximum transmission unit and usually doesn't need to be changed; gso (Linux only) enables Generic Segmentation Offload for better performance, and gso-max-size sets the maximum data block length.

Routing Range & Filtering

Field	Description
`route-address` / `route-exclude-address`	When `auto-route` is enabled, routes custom ranges instead of the default route / excludes custom ranges — usually doesn't need to be configured
`route-address-set` / `route-exclude-address-set`	Adds destination IP CIDRs from a specified rule set to the firewall for routing/exclusion; Linux + nftables only, requires `auto-route`+`auto-redirect`
`include-interface` / `exclude-interface`	Restricts which network interfaces get routed — mutually exclusive, can't be configured together
`include-uid` / `exclude-uid`(and the range variants)	Restricts/excludes traffic routed through TUN by Linux user UID; Linux only, requires `auto-route`
`include-android-user`	Restricts which Android users get routed (owner 0 / work profile 10 / clone apps 999); Android only
`include-package` / `exclude-package`	Restricts/excludes traffic routed through TUN by Android app package name
`endpoint-independent-nat`	Enables endpoint-independent NAT; may slightly reduce performance — not recommended unless you actually need it
`udp-timeout`	The UDP NAT expiration time, in seconds, defaulting to 300 (5 minutes)

There's also a set of "legacy" fields (like inet4-route-address) that will eventually be removed — new configs should use the newer field names above instead.