The link you have provided is not setting up SOCKS but a transparent proxy i.e. it takes TCP/UDP traffic and SOCKSify it before sending through
shadowsocks tunnel. But you need to make your traffic SOCKS-aware before directing towards SOCKS proxy. Either configure individual apps (which have built-in support for SOCKS) or enforce proxy system-wide transparently (what you are trying to do).
LIMITATIONS OF SOCKS PROXY:
It looks like AFWall+ is able to create a NAT forwarding policy
iptables at back end and it can execute your script on network changes. Enforcing global proxy is (at least partially) possible with proxifier apps like ProxyDroid (which is
iptables-based) and SocksDroid (which is VPN/routing based). I have no affiliation with either.
If manually workig from CLI, you can use a transparent TCP/UDP-to-proxy redirector like
redsocks in combination with
shadowsocks provides its own similar tool (
ss-redir), so does Tor.
I didn't tick any app so I assume that means all app go through custom script, right?
No. The problem with the
iptables approach is that SOCKS5 is a layer 5 protocol in OSI model. So it cannot carry whole traffic from all apps. Most of the traffic generated by apps is TCP which works fine with SOCKS and is easy to setup. But some games, VoIP apps and above all the traditional DNS generate UDP traffic which is not supported by many SOCKS5 proxies. E.g.
tor both don't,
shadowsocks however does have UDP associate features. But it doesn't work with simple
REDIRECT (probably because
SO_ORIGINAL_DST is not available for UDP sockets, I don't know the details). You can possibly redirect traffic only towards a fixed socket (IP:PORT) e.g. a DNS server or game server.
TPROXY is the alternative here, but the trouble is that it works only with
PREROUTING chain i.e. the traffic coming from outside, not that generated on device. So you have to do extra setup to route your on-device traffic without NATing towards a local proxy server (usually default gateway) where you'll set up
Complicated? That's why VPN is preferred. Even if you need to use a proxy to circumvent firewalls, VPN tunneling through proxy spares you from the traffic redirection complexities. VPN operates at lower level in network stack (L2/L3 in OSI), so it flawlessly carries all IP traffic including ICMP echos (
ping) etc. which can no way be sent through SOCKS. Another plus point is that VPN can be tunneled through transparent proxies - like
stunnel - or SOCKS proxies which are meant to forward only single port - like
If not forwarding single port (tunneling), SOCKS5 must be an application level proxy i.e. it should be able to forward arbitrary ports from different apps like SSH dynamic port forwarding does.
tun2socks is another SOCKSification method which collects TCP/UDP traffic on a
tun interface (same like a VPN, no NAT involved) and forwards it through a SOCKS proxy. It recently added UDP associate support. Previously used UDP Gateway method also worked quite fine but it requires running a separate daemon (
udpgw) along with proxy server.
tun2socks is a non-root solution because apps - like
SocksDroid and many other firewalls, sniffers etc. - using this method rely on Android's VPN facilities.
... and fool Google apps into thinking they are not connected via a VPN (Google apps implement additional security measures when connecting via
With both above methods (VPN through tunnel and Tun-to-SOCKS) it's not necessary to use Android's VPNService API (if that's causing problems for you). On a rooted device you can get a static
tun2socks binary and run that through CLI. That's far less hassle than setting up proxy through
iptables. In former case, though, you need a VPN server obviously.
SOCKSIFY WHOLE DEVICE:
As you don't want to go with VPN/routing based solution, here is the simple
redsocks binary for your device architecture (or try this one for
aarch64 or this one for
Create configuration file:
// general configuration
redirector = iptables;
// for TCP
local_ip = "127.0.0.1"; local_port = "12345";
ip = "192.168.1.1"; port = "1088"; type = socks5;
// for UDP, assuming your SOCKS5 proxy supports UDP associate
local_ip = "127.0.0.1"; local_port = "12345";
ip = "192.168.1.1"; port = "1088";
dest_ip = "18.104.22.168"; dest_port = "53"; /* set whatever DNS server */
* See redsocks.conf.example for details and more options.
IPTABLES="/system/bin/iptables -w5 -t nat"
# create new chain
$IPTABLES -N PROXY
$IPTABLES -I OUTPUT -j PROXY
# exclude local traffic, see: http://manpages.org/ss-redir
$IPTABLES -A PROXY -d 127.0.0.0/8 -j RETURN
$IPTABLES -A PROXY -d 192.168.0.0/16 -j RETURN
# socksify whole TCP traffic
$IPTABLES -A PROXY -p tcp -j DNAT --to 127.0.0.1:12345
# socksify only DNS UDP traffic
$IPTABLES -A PROXY -p udp --dport 53 -j DNAT --to 127.0.0.1:12345
echo "Ctrl^C to exit."
trap "$IPTABLES -D OUTPUT -j PROXY; $IPTABLES -F PROXY; $IPTABLES -X PROXY" EXIT
# run socksifier
redsocks -c /path/to/redsocks.conf
You can add custom
iptables script to AFWall+.
redsocks can be run as
init service with non-root UID, dropped capabilities and restricted SELinux context. See How to run an executable on boot?