How SocketFlip works
What it can and cannot reset
SocketFlip resets TCP connections only. When a VPN starts or stops, Android closes the covered app's open TCP sockets; it does not do this for UDP.
- Reset: anything that talks to its server over TCP, which is most app APIs, chat and notification links, game servers and ordinary web traffic.
- Not reset: voice and video calls (WhatsApp, Signal, Meet and similar), most online game voice chat, and traffic using QUIC / HTTP/3, all of which run over UDP. A call in progress simply carries on.
If you tap and nothing seems to happen, the app you chose is probably talking UDP, or reconnected so quickly you did not notice.
How it works
SocketFlip uses Android's VPN API, but not to carry traffic:
- The tunnel covers only the apps you tick. It has the address
10.111.222.1and routes exactly one other address,10.111.222.2, which nothing uses. All of the app's real traffic still goes out over Wi-Fi or mobile data as normal. There is no server at the other end and nothing leaves the phone. - Whenever a VPN covering an app starts or stops, Android closes that app's open sockets. That is the clean disconnect.
- Each tap makes exactly one state change (tunnel up, or tunnel down), so each tap is exactly one disconnect. Bringing a tunnel up and straight back down hits the app twice, and a reconnect that lands between the two can get stuck.
Things that do not work, for the record:
- Airplane mode takes the whole Wi-Fi link down, which is slow to come back.
- A per-app firewall block only stalls the connection silently. A short stall is never noticed, so nothing reconnects.
Taps closer together than the cooldown (10 seconds unless you change it in Settings) are ignored: a second disconnect while the app is still reconnecting can leave it stuck on its reconnect screen. A ring around the button shows the time left.
While the tunnel is up the status bar shows a VPN key. That is expected; the next tap takes it down again (and is also a reconnect).