NetGuard's SOCKS Mode Covers TCP, Not Every Protocol

NetGuard occupies Android's VPN interface in order to filter traffic, and it can hand supported connections to a SOCKS endpoint. Those two facts are often read as “the phone is on a VPN”, which is a conclusion the mechanism does not support. The filter sees packets; the proxy sees only the connections that were actually handed to it. Between those two statements sits the whole question of coverage.

The upstream FAQ documents both the single-service limitation and the SOCKS option. The existence of the option is not evidence that every permitted packet uses it, and that gap is where coverage questions come from.

Two forwarding paths inside one app

The TCP side of the implementation contains SOCKS connection handling, so a permitted TCP connection can be negotiated with the proxy and carried through it. The UDP side has a separate socket path, and its send and receive handling does not depend on that TCP negotiation. A datagram that the filter allows can therefore reach the ordinary network without ever passing through the proxy. Nothing about that is a defect in the app; it is simply what the two paths implement.

The distinction has a consequence people misstate in both directions. Calling every UDP packet a leak ignores the blocking rules, because a denied datagram never leaves. Calling the whole arrangement a VPN ignores the allowed direct path, because some traffic does leave unproxied. What you have is a filtered device with partial proxying, and the honest description is a matrix rather than a label.

Advertising UDP is not implementing it

A SOCKS server that claims UDP support does not add the matching client-side handling to the app on your phone. The protocol's theoretical features and the behaviour of the installed build are different subjects, and only the second one describes your traffic.

Check the version and configuration you actually run, then test a harmless datagram flow and observe whether it appears at the proxy. Anything else is inference from a feature list, and feature lists describe intentions rather than code paths.

DNS is a third path, not a detail

Name resolution adds its own branch to the matrix. A local DNS forwarder, an ordinary UDP lookup, a destination hostname resolved by the proxy itself and an encrypted resolver in the browser are four distinct arrangements. They differ in who sees the query and in which network path carries it, and mixing them produces a test that proves nothing about the others.

Decide deliberately which one you want. If the requirement is that names resolve through the tunnel, a browser setting alone will not deliver it, and a proxy that resolves hostnames itself changes the answer only for connections it actually handles.

The proxy transport is not automatically private

Plain SOCKS is not an encrypted phone-to-proxy link. If the endpoint is reached through another protected path, name that path and its failure policy, because a fallback to the open network turns a private arrangement into a public one without warning. The proxy's own authentication matters too: an open listener on a shared device is a service nobody is accounting for.

Cross-profile arrangements deserve the same scrutiny. A work-profile VPN protects only the traffic that uses its path, and the coexistence of a personal-profile firewall with a work tunnel does not prove that the firewall's onward connection reaches that tunnel. Verify reachability and authentication rather than assuming the two profiles cooperate.

Audit coverage with a matrix instead of a page load

For an authorized evaluation, pick harmless examples that represent each class you care about: required TCP, allowed UDP, and DNS in both address families. For each one, record whether it was proxied, blocked or sent directly. That single table is the deliverable, and it is far more useful than a screenshot of a page that loaded.

If the requirement is that all selected application traffic must traverse a remote tunnel, choose an implementation with explicitly supported combined filtering and tunnelling. A TCP-only proxy composition remains useful for narrower tasks, provided the other traffic is handled on purpose rather than forgotten.