Feature Request: Root Mode Support

[akellavk]

Feature Request: Root Mode Support

Overview

Add optional root mode functionality to Exclave as an alternative to VPN-based transparent proxying, similar to implementations in v2rayNG and other proxy clients.

Motivation

While VPN mode works well for most scenarios, root mode offers a critical advantage: invisibility to VPN-detecting applications.

Primary Problem: VPN Detection

Many applications actively detect and block VPN usage:

• Banking and financial apps refuse to work when VPN is detected (security policies)
• Streaming services (Netflix, Disney+, etc.) block content when VPN interface is present
• Gaming apps kick users or impose restrictions when VPN is active
• Regional apps (government services, local payment systems) reject VPN connections
• Corporate apps may conflict with personal VPN usage

Root mode solves this: Traffic is routed via iptables without creating a VPN interface, making proxy usage invisible to apps checking ConnectivityManager, NetworkCapabilities.NET_CAPABILITY_NOT_VPN, or network interface lists.

Secondary Benefits

VPN Conflict Resolution

• Use Exclave alongside corporate/work VPN simultaneously
• Android's "one active VPN" limitation is bypassed
• Run multiple proxy clients if needed

Performance

• Lower overhead: direct iptables routing vs VPN tunnel encapsulation
• Reduced battery consumption: no VPN interface processing
• Better throughput for high-bandwidth scenarios

Use Cases

• Banking/finance apps that block VPN but you need proxy for other traffic
• Streaming services while maintaining proxy for blocked websites
• Gaming without VPN detection penalties
• Work VPN + personal proxy simultaneous operation
• Regional apps that refuse VPN but you need censorship circumvention for browsers

Proposed Implementation

Core Functionality

1. iptables-based routing: Use iptables rules to redirect traffic to local proxy instead of VPN tun interface
2. App exclusion: Granular per-app routing control (similar to current VPN per-app proxy)
3. DNS handling: Root mode DNS redirection via iptables NAT rules
4. IPv4/IPv6 support: Handle both protocol families

User Interface

• Add "Use root mode" toggle in settings (disabled by default)
• Display warning dialog explaining requirements and implications
• Root permission request on first activation
• Status indicator showing active mode (VPN vs Root)

Safety Features

• Automatic iptables cleanup on service stop/crash
• Backup of existing iptables rules before modification
• Fallback to VPN mode if root access is lost
• Clear error messages if root is unavailable

Technical Considerations

Requirements

• Rooted Android device (Magisk, KernelSU, or other root solution)
• iptables binary availability
• Busybox (optional, for enhanced compatibility)

Challenges

• Legacy codebase: I understand Exclave has inherited legacy code from SagerNet, which may complicate implementation
• Maintenance burden: Root mode requires additional testing across devices and Android versions
• User support: More complex troubleshooting for root-related issues

Suggested Approach

• Keep root mode as optional experimental feature initially
• Document clearly that it requires user understanding of risks
• Leverage existing implementations from other open-source projects (v2rayNG)
• Maintain VPN mode as primary/recommended method

Community Interest

This feature would benefit:

• Banking/financial app users who cannot use current VPN mode
• Streaming service users blocked by VPN detection
• Gamers facing VPN penalties or connection issues
• Users requiring simultaneous VPN + proxy setup (work + personal)
• Users in regions where apps actively block VPN usage

---

Additional Notes

I understand the README mentions that "feature requests are likely not accepted" due to the legacy codebase. However, given that:

• Exclave already supports advanced features like proxy chains and complex routing
• Root mode is a highly requested feature in proxy clients
• Reference implementations exist in similar projects
• It would differentiate Exclave from competitors

I believe this feature could significantly expand Exclave's user base among power users while maintaining the current VPN mode as the default stable option.

---

Willing to Contribute

• I am willing to test beta implementations
• I can provide logcat/debugging assistance

[dyhkwong]

For TPROXY, the key point is the Golang code is running as the native code via JNI rather than a running in separate process.

[dyhkwong]

TPROXY need to set and get sockopt, which requires root, but JNI code can't directly access root. You mostly need to use libsu to run a daemon with root privilege in a separate process, use IPC to communicate with the daemon and pass the connection file descriptor to the daemon and let the daemon set and get sockopt for you.
For egress traffic, you mostly needs to pass the connection file descriptor to the daemon and let the daemon set SO_MARK for you, or use Linux GID/UID function to prevent the egress traffic from going into TPROXY again.

[dyhkwong]

Also it does not make sense for us to operate like v2rayNG to use tun2socks or tproxy-to-socks. We have removed the necessity for the technology like tun <-> socks egress <-> socks ingress <-> proxy egress many years ago and use tun <-> proxy egress instead. We should not go back to the tun2socks era and using tun2socks will make us lose many functions that requires Java-only APIs.

[dyhkwong]

It should also be mentioned that some functions relies on Java API, such as system DNS (local resolver), Wi-Fi SSID routing rule and network type routing rule, connection package name UID routing rule and network change listener. In root mode, they either needs to be rewritten (using C++ API, or Linux-style API and let the daemon take charge of them, if possible) or need to be removed.