Max/LorenEteval_Furious
1
0
Fork 0
mirror of https://github.com/LorenEteval/Furious.git synced 2026-09-28 09:58:10 +03:00
Code Issues Packages Projects Releases Wiki Activity
Page: TUN Mode
Pages
External Core Home Install From PyPI Plugin Development Quick Start Release Artifacts Routing Server Profiles and Sharing Subscription Management TUN Mode Troubleshooting and Diagnostics
Clone
22
TUN Mode
Loren Eteval edited this page 2026-09-19 14:39:58 +08:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

TUN Mode

TUN mode routes system traffic through the active Furious connection. Depending on the selected profile, Furious either lets the proxy core provide its own TUN interface or starts its application-managed Tun2socks service. It is independent from System Proxy, which only configures applications that honor the operating system's proxy settings.

If you have not made a normal proxy connection yet, begin with Quick Start. TUN adds interface, route, DNS, and privilege requirements to that working connection.

Supported platforms

Platform Release architectures Permission model
Windows 7 AMD64 Furious must run as Administrator.
Windows 10 or later AMD64 and ARM64 Furious must run as Administrator.
macOS Intel and Apple silicon Furious must run as Superuser.
Linux AMD64 and ARM64 Application Tun2socks requests privileges; native core TUN may require the whole application to run as root.

Important

TUN mode is disabled in the Flatpak build.

How TUN mode works

Turn on Settings > General > TUN Mode to request TUN for future connections. Changing this setting does not alter a running core in place; accept the reconnection prompt to apply it now, or reconnect later. Turn it off and reconnect to return to proxy-only operation, except for an explicit TUN configuration described below.

Furious selects one TUN owner for the active profile:

Profile TUN implementation
Xray-core Xray native TUN when Use Xray-core TUN is enabled or the configuration already contains a TUN inbound; otherwise application Tun2socks.
Hysteria 2 Hysteria 2 native TUN when Use Hysteria2 TUN is enabled or the configuration already contains a tun block; otherwise application Tun2socks.
Hysteria 1 Application Tun2socks.
External Core Application Tun2socks only when that profile enables Use Application Tun2socks. Its TUN Remote Address supplies the upstream address used for route-loop prevention. See External Core.

The native Xray-core and Hysteria 2 choices are under Settings > Plugin Settings. Their native-TUN settings are configured there as well. These native options default to enabled on Windows and macOS and disabled on Linux.

Note

A TUN inbound/block already embedded in an Xray-core or Hysteria 2 configuration remains part of that configuration even when the global TUN Mode switch is off. Remove the explicit TUN configuration if the core should not start it.

Requirements

Windows

  1. Download the official Wintun package.
  2. Copy the wintun.dll matching the Furious build next to Furious.exe:
    • AMD64 build: wintun\bin\amd64\wintun.dll
    • ARM64 build: wintun\bin\arm64\wintun.dll
  3. Open Settings > General and select Restart The Application As Administrator.
  4. After the elevated instance opens, enable TUN Mode and connect.

Furious loads Wintun only from the application directory or C:\Windows\System32. A DLL built for the wrong CPU architecture cannot be loaded and may crash the TUN backend.

The Windows 7 release is AMD64-only. Its automatic primary-interface-name lookup uses a PowerShell command unavailable on Windows 7; if detection fails, set Primary Adapter Interface Name in Customize Tun2socks Settings....

macOS

Open Settings > General and select Restart The Application As Superuser, then enable TUN Mode and connect. This preserves the packaged application launch path and is preferred over starting Furious-GUI manually with sudo.

Application Tun2socks currently uses en0 as its underlying network interface. Systems whose active uplink is not en0 may not work with this backend; use a supported native-core TUN path where possible.

Linux

Application Tun2socks requires bash, ip from iproute2, and pkexec from a PolicyKit implementation. Furious may run as a normal user; approve the privilege prompt shown during connection setup.

Native Hysteria 2 TUN cannot use that helper and requires Furious itself to run as root. Native Xray-core TUN likewise needs whatever TUN and route permissions Xray requires on the host. The Linux defaults therefore use application Tun2socks unless a native option is enabled explicitly.

Routing and loop prevention

Application Tun2socks sends the active proxy server's IP addresses through the original physical gateway before installing its TUN route. If the server address is a hostname, Furious resolves it first. This bypass keeps the core's own connection from returning to the TUN interface.

Warning

When application Tun2socks is used, core routing rules that send traffic directly can feed that traffic back into the system TUN interface and create a loop. Use Global routing unless every direct path is known to bypass the TUN interface.

For the built-in Bypass Mainland China option, Xray-core without native TUN and Hysteria 1 offer to switch to Global and reconnect. Custom routing rules are not inspected automatically.

This blanket restriction does not apply to a native core TUN configured to manage its own routing. Furious adds the resolved Hysteria 2 server addresses to its native TUN exclusions; managed Xray-core TUN uses Xray’s automatic routing and outbound-interface settings. If required native-TUN preparation fails, the connection fails rather than silently switching to application Tun2socks. Check the first preparation error in the log.

See Routing for backend routing support, named Xray routing profiles, and the distinction between routing, TUN, and System Proxy.

Platform behavior

For application Tun2socks, Furious performs the following host setup:

Platform Interface and routes DNS
Windows Creates the Wintun adapter named Furious, installs the TUN default route, and adds upstream-server bypass routes through the physical gateway. Configures the TUN adapter DNS; by default it also points the primary adapter at 127.0.0.1 during the connection and flushes the DNS cache.
macOS Starts utun777, assigns its gateway, installs the system route ranges, and adds upstream-server bypass routes. Saves each network service's DNS configuration, applies the TUN DNS, and restores the saved values on normal cleanup.
Linux Creates utun777, assigns 10.10.10.10/24, adds a metric-5 default route, and adds upstream-server bypass routes through the detected interface. Does not change host DNS settings.

Native Xray-core and Hysteria 2 TUN use their own interface, address, route, and DNS settings instead of Customize Tun2socks Settings....

Custom Tun2socks settings

Open Settings > Connection and Interface > Customize Tun2socks Settings.... These settings affect only application Tun2socks, not native Xray-core or Hysteria 2 TUN.

Leave the basic fields empty unless automatic detection fails:

  • Primary Adapter Interface Name overrides Windows interface-name detection. This is the usual Windows 7 workaround.
  • Primary Adapter Interface IP and Default Primary Gateway IP must be provided together to override gateway detection. Prefer automatic detection on Linux, where the route commands require an interface name rather than the IP-oriented field shown by this shared editor.
  • Tun2socks Adapter Interface DNS overrides the default TUN DNS on Windows and macOS.
  • Bypass Tun2socks Adapter Interface IP accepts comma-separated literal IPv4 or IPv6 addresses. When set, these replace automatic upstream-address resolution for bypass routes.
  • Disable Primary Adapter Interface DNS applies only to Windows and mitigates DNS leaks while connected.

The memory section exposes bounded TCP send/receive buffer sizes and receive-buffer auto-tuning. No separate tun2socks memory-optimization procedure is required.

Verifying TUN mode

For a strict test, select Do Not Change System Proxy in Settings or use a client that ignores proxy settings. Then connect and run:

curl --noproxy "*" https://icanhazip.com

The result should be the proxy server's public exit address. Also check the Log page: application Tun2socks has a separate log category, while native TUN messages appear in the core log.

Cleanup and troubleshooting

Connection startup is staged. If the core, native TUN preparation, Tun2socks, DNS, or route setup fails, Furious stops and disposes the runtimes acquired by that attempt. Normal disconnect, reconnect, and application shutdown also request route, DNS, interface, and process cleanup.

Cleanup is best effort. A forced termination, power loss, failed platform command, or privilege loss can leave host state behind.

  • No Wintun adapter on Windows: verify that wintun.dll is beside Furious.exe, matches the release architecture, and that Furious is elevated.
  • More than one default route: automatic gateway detection requires one unambiguous default gateway. Supply the Windows gateway/interface values manually, or disable competing adapters temporarily.
  • Windows static DNS: the default DNS-leak mitigation restores the primary adapter to DHCP DNS on cleanup, not to a previous static DNS value. Disable that option if the adapter must retain static DNS, or restore the static setting afterward.
  • Linux privilege prompt fails: verify that pkexec, PolicyKit, bash, and ip are available.
  • Linux leaves utun777 after an interrupted or unprivileged cleanup: disconnect cleanly when possible. After confirming that utun777 is the stale interface created by this Furious connection and no active connection uses it, remove it with sudo ip tuntap del mode tun dev utun777 before reconnecting.
  • External Core reports a missing TUN remote address: enable application Tun2socks only after setting the profile's actual upstream hostname or IP; the executable path and local proxy listeners are not remote addresses.

If setup still fails, open the Log page and inspect Application and either Tun2socks or Core messages for the first failed stage.

See also