5G Proxy Client
Routes device traffic through a remote SOCKS5 proxy via TUN. No root, TCP/UDP.
新版本 1.6.7
- Fix: a DNS query carried over TCP (remote DNS enabled, with the query itself sent through the tunnel) was never released. The connection record and its buffer stayed allocated, and the session counter only ever went up. After 512 of them the client would refuse every new TCP connection — DNS and ping still worked, everything else was dead, and restarting the tunnel brought it back. The session now releases itself as soon as the answer has been written back, and a regression test asserts the se
Android SOCKS5 TUN tunnel client — routes the device's entire network traffic through a remote SOCKS5 server using a TUN virtual interface. No root required.
Features:
- User-space TCP state machine forwarded via SOCKS5 CONNECT
- UDP / DNS / QUIC relay via SOCKS5 UDP ASSOCIATE (UDP-in-UDP or UDP-in-TCP 0x04)
- Remote DNS (fakedns) with fake IPv4 (198.18.0.0/15) and fake IPv6
- IPv4 + IPv6 dual-stack support
- Per-App routing modes: Global, Allowlist, or Exclusion
- Auto-reconnect with exponential backoff on connection drop
- Live traffic statistics (up/down bytes & session count) in persistent notification
- Custom primary & secondary DNS servers
- Start tunnel on boot
- Quick Settings tile for one-tap tunnel toggle
- Multiple profile management with JSON export/import via clipboard
- Native C (epoll) engine + JNI + Kotlin UI
Privacy notes:
- While the tunnel is up, the proxy server's hostname is re-resolved outside the tunnel (needed to follow DDNS / IP changes without tearing the TUN interface down). That lookup is sent to the DNS servers of the network the tunnel actually runs over. The custom DNS servers above are used only as a fallback when that resolver gives no answer, and the fallback is written to the log.
- With Remote DNS enabled, DNS queries from apps are relayed to the proxy exit instead of being answered locally.
Open source (MIT), reproducible builds.
Features:
- User-space TCP state machine forwarded via SOCKS5 CONNECT
- UDP / DNS / QUIC relay via SOCKS5 UDP ASSOCIATE (UDP-in-UDP or UDP-in-TCP 0x04)
- Remote DNS (fakedns) with fake IPv4 (198.18.0.0/15) and fake IPv6
- IPv4 + IPv6 dual-stack support
- Per-App routing modes: Global, Allowlist, or Exclusion
- Auto-reconnect with exponential backoff on connection drop
- Live traffic statistics (up/down bytes & session count) in persistent notification
- Custom primary & secondary DNS servers
- Start tunnel on boot
- Quick Settings tile for one-tap tunnel toggle
- Multiple profile management with JSON export/import via clipboard
- Native C (epoll) engine + JNI + Kotlin UI
Privacy notes:
- While the tunnel is up, the proxy server's hostname is re-resolved outside the tunnel (needed to follow DDNS / IP changes without tearing the TUN interface down). That lookup is sent to the DNS servers of the network the tunnel actually runs over. The custom DNS servers above are used only as a fallback when that resolver gives no answer, and the fallback is written to the log.
- With Remote DNS enabled, DNS queries from apps are relayed to the proxy exit instead of being answered locally.
Open source (MIT), reproducible builds.
捐赠
版本
尽管下面提供了 APK 安装包的下载选项，但你应该注意，以这种方式安装将不会收到更新通知，这是一种不太安全的下载方式。 我们建议你安装使用 F-Droid 客户端。
下载 F-Droid-
arm64-v8aarmeabi-v7ax86_64该版本需要 Android 8.0 及以上版本。
此包由原始开发者构建并签名，并保证对应于此源代码 tarball。
-
arm64-v8aarmeabi-v7ax86_64该版本需要 Android 8.0 及以上版本。
此包由原始开发者构建并签名，并保证对应于此源代码 tarball。
-
arm64-v8aarmeabi-v7ax86_64该版本需要 Android 8.0 及以上版本。
此包由原始开发者构建并签名，并保证对应于此源代码 tarball。
新版本 1.6.6
- Fix: IPv6 link-local detection (fe80::/10) now compares the numeric value of the first hextet instead of a textual prefix, so an address such as fe8::1 is no longer misread as link-local and dropped — it is really 0fe8::, which is outside fe80::/10 (over-filtering reported in the F-Droid 1.6.5 review; the existing test had asserted the buggy behaviour)
- Fix: when Wi-Fi and mobile data are both up with different DNS servers, re-resolution after a network change only ever worked for the first o
- Fix: when Wi-Fi and mobile data are both up with different DNS servers, re-resolution after a network change only ever worked for the first o
新版本 1.6.5
- Fix: after a network change, the DNS servers used to re-resolve the proxy server's hostname were the tunnel's own advertised servers (8.8.8.8 / 1.1.1.1 by default), not the DNS of the network the tunnel actually runs over. The intended "fall back to the local network's DHCP DNS" step had never taken effect, because it read the active network — which, for a VPN app, is its own VPN network. The underlying network's resolver is now tried first, so the hostname is not handed to a third-party resol