This section matters even with a perfect VPNHide setup. Kernel and framework hooks can alter local Android responses, but remote servers still see the actual address, ASN, latency, and transport availability.
Project-verified: the network layer includes GEO_IP, IP consensus across Russian and non-Russian services, DNS comparison, CdnPullingChecker, STUN, Telegram and WhatsApp call transport, underlying-network probes, RTT triangulation, ICMP spoofing, and domain reachability. Some results are diagnostic, but disagreement between independent channels can contribute to a final DETECTED verdict.
Key indicators include:
This is the cleanest non-root arrangement. The VPN or proxy runs on the router, while the phone connects to an ordinary Wi-Fi network. Android has no local VpnService or TUN artifacts. RKNHardering can therefore observe only the external network path, which must be made internally consistent.
Community-reported: the RKNHardering-defense project provides router-oriented configurations and separately warns that a router-level TUN alone does not solve CDN pulling. Its ready-made materials include Sub-Store and S-UI. Treat them as routing examples, not as proof that the current application version will pass.
In practice, verify three things: HTTP(S), DNS, and UDP must leave through the same expected path; IPv6 must either be configured the same way or intentionally disabled for the specific laboratory profile; and the phone must not retain a fallback mobile path that can unexpectedly become the underlying network.
Android officially supports allow and disallow lists through VpnService.Builder.addAllowedApplication() and addDisallowedApplication(). In sing-box for Android, this can be configured through Settings → Profile Override → Per-app Proxy. Route-rule documentation: sing-box route rule.
The basic idea in current sing-box syntax looks like this:
{
"route": {
"rules": [
{
"package_name": ["com.notcvnt.rknhardering"],
"action": "route",
"outbound": "direct"
}
]
}
}
This is not a complete ready-to-use configuration: the direct tag, DNS rules, and schema version must match your installation. Before replacing a working profile, validate the configuration with the client’s built-in checker and keep a backup copy.
Limitation: the current TUN_ACTIVE_PROBE deliberately detects a state in which a TUN interface exists while vpnActive is false for RKNHardering. Per-app bypass can therefore remove the foreign IP while simultaneously confirming that the package was explicitly excluded. For a clean non-root result, it is generally paired with an external gateway rather than a local VpnService.
Do not leave HTTP direct while DNS goes through the VPN, or the reverse. RKNHardering compares resolution behavior with network results. For an excluded application, use the underlying network’s DNS or a separate resolver that exits through the same outbound. Do not set a system HTTP proxy merely to route DNS: that creates a separate SYSTEM_PROXY signal.
In sing-box configurations, the DNS rule should be separate from the traffic rule, but both should lead to the same intended path. A large community example is available in SUB-STORE.md; do not copy it wholesale without checking your own tags, rule sets, and trusted packages.
A TCP-only proxy can look clean over HTTP while UDP and STUN leave directly. Choose the correction according to the intended behavior:
unsupported, no signal, or a review state;Do not treat GPS spoofing as the primary strategy. The check uses MCC/MNC, SIM, cellular and Wi-Fi context, and server-side data; inconsistent spoofing creates more contradictions. A sound configuration should explain the observed location–egress pair. Home-routed roaming can be legitimate, and the code retains a distinct HOME_ROUTED_ROAMING context.
Root does not replace the steps above. It can hide the local fact that a VPN exists only after the network path has already been made consistent.
A practical sequence is:
When RKNHardering is meant to go direct, kernel or framework hiding is needed precisely because the local TUN still exists. When RKNHardering is meant to remain inside the tunnel, account for an architectural limitation of upstream VPNHide: replacing the active VPN network with the physical network is most coherent under split tunneling. The project explicitly identifies server-side signals as outside the scope of local hiding. See VPNHide detection vectors.
For localhost, the best option is not to expose an API at all. When another application needs it, VPNHide portshide or a VPNHide Next kernel-level block should apply to the RKNHardering UID. A password on the Clash API is useful for security, but it does not conceal the open port or the protocol itself; RKNHardering scans loopback and known REST endpoints.
Mihomo/Clash external-controller and sing-box/Xray APIs should not listen on 0.0.0.0 without a specific need. For a laboratory phone, safer choices are:
9090, 9091, 9097, or 19090 as the only protection: changing the port does not prevent a full scan.Official Mihomo documentation: general configuration. Official sing-box documentation: configuration.
First capture a network baseline without root-only commands:
adb shell dumpsys connectivity
adb shell ip addr
adb shell ip route
adb shell ip rule
adb shell settings get global http_proxy
adb shell pm list users
On Android, SELinux may restrict parts of /proc; permission denied means insufficient privileges, not that a route or socket is absent. Do not switch SELinux to permissive merely for diagnostics: that weakens security and creates a direct ROOT_SELINUX signal.
After a change, restart the application:
adb shell am force-stop com.notcvnt.rknhardering
adb shell monkey -p com.notcvnt.rknhardering 1
Run at least two checks on the same network. Then repeat separately after switching between Wi-Fi and mobile data: a change in the network epoch should explain changed results rather than being mistaken for a “random success.”
Even with the correct public IP, hosting or proxy databases, a datacenter ASN, RTT, CDN behavior, and a server fingerprint may remain. Even behind an external router, RKNHardering can legitimately observe a foreign exit. Conversely, local hiding does not fix split DNS or an IPv6 leak.