Caged connections end on the phone. Apps outside a caged Android UID keep their normal network route. NetCage uses Android’s app-based VPN routing to send selected apps and any shared-UID siblings into an on-device tunnel, then answers supported TCP and UDP attempts with a refusal instead of forwarding them.
No. The tunnel has no remote server, and NetCage does not forward caged traffic. It builds a local TCP reset or ICMP port-unreachable response when it can address one safely; other packets are discarded. NetCage can still connect for features you choose, including accounts, backup, support, telemetry, announcements, custom icons and Cage Packs, and it can ask Google Play for updates.
Packages in the active cage plan establish the caged Android UIDs. Android applies the package allow-list at the VPN boundary, so apps sharing a selected package’s UID enter the tunnel too. NetCage refuses to establish the tunnel if the list ends up empty. Release the last active package for a UID and Android gives that UID its normal route back. Apps outside caged UIDs and NetCage itself keep the phone’s normal network route.
To address a refusal, NetCage reads the IP and transport-header fields needed for the reply in memory. It does not read the payload, resolve a hostname, keep DNS, URL or traffic logs, or forward the packet. Apps outside a caged Android UID never enter this code path.
Reboot recovery needs Auto-start on boot to be enabled, the master cage to be on, and an active saved rule or schedule. NetCage can then restore the plan from its device-protected snapshot before the phone is first unlocked and re-arm saved deadlines. Android’s separate Always-on VPN setting can also start the service, but phone-maker background controls may still delay or stop it.
Apps outside caged Android UIDs bypass NetCage’s tunnel, so NetCage does not process their traffic. Even so, the active VPN service and refusal work use some device resources, and a caged app may retry a failed connection. Battery and performance vary by phone and app; NetCage does not promise an exact zero cost.
No. The supported engine uses Android’s VPN slot. The alternative root engine is off by default and labelled experimental: its command construction is unit tested, but it has never run on rooted hardware. The VPN engine remains the supported default and fallback.
NetCage reports the engine’s current state. It records cage, release and tunnel changes in its local event log. Android requires a foreground-service notification while the VPN is active. With notification permission, it appears in the notification drawer. Without that permission, the active service remains visible in Android’s active-apps task manager. If foreground promotion fails, NetCage does not establish the tunnel.
Android gives one app the VPN slot at a time. Starting another VPN replaces NetCage; NetCage closes its tunnel and reports the revoked state instead of fighting for the slot. A phone maker can also stop the background service. Do not rely on NetCage where a missed block could cause harm. Check the reported state. Then use the public documentation for setup and recovery steps.