Why Per-App Routing Matters on Android
Android applications do not share a single networking stack the way a desktop browser might under a simple system proxy. Games use custom sockets, messengers spawn background sync jobs, and OEM skins ship preloaded utilities that assume a normal carrier path. When you flip on a full-tunnel VPN profile, everything—payments, maps, push notification channels—must survive the same detour. That is often unnecessary and sometimes harmful: latency-sensitive domestic services may degrade, captive portals on public Wi‑Fi become harder to clear, and enterprise apps that pin certificates can refuse to start because they no longer see the network they were tested against.
Per-app routing narrows the blast radius. Instead of asking “should all traffic leave through this node,” you ask “which UID should the kernel associate with the tunnel.” Clash Meta for Android implements this idea through an access-control or per-app screen (exact labels vary by build, but the underlying concept is consistent): you choose whether the tunnel applies globally, only to selected packages, or globally with explicit exceptions. That is the practical answer to “I only want my browser and one game on the proxy” without re-writing your entire subscription file.
Nothing here encourages bypassing lawful blocks, violating terms of service, or interfering with workplace device policies. If your employer or school forbids split tunneling or personal VPN clients, the compliant path is to follow that policy—not to hunt for a checkbox that happens to evade MDM. The following instructions assume you are allowed to run Clash on the device and network in question.
App Lists vs. GEOIP Rules: Two Different Layers
New users frequently conflate two unrelated mechanisms. Subscription bundles sometimes advertise rules such as “bypass mainland China” or “domestic direct.” Those strings live inside config.yaml: they tell the kernel how to classify destinations by IP geography or domain lists. Per-app controls, by contrast, decide whether an application’s traffic is eligible to enter the Clash tunnel at all. You can have excellent GEOIP rules and still route a domestic banking app through an overseas exit if you accidentally leave per-app mode set to “everything proxied.” Conversely, a perfect per-app whitelist will not magically fix bad DNS or missing DOMAIN rules for a specific site—that is still the job of your rule section and policy groups.
Think of it as two sliders. The GEOIP slider answers “for traffic that reaches Clash, should destinations in country X go DIRECT?” The per-app slider answers “should this Android package even hand its sockets to Clash?” You will get the least surprising behavior when both are aligned: domestic-critical apps bypass the tunnel at the OS layer and your subscription sends Chinese CDNs and payment domains to DIRECT inside the kernel. For a refresher on keeping those kernel-side rules maintainable, read Clash rule routing best practices; this article focuses on the Android-side half of the story.
If you skip understanding that separation, you end up debugging the wrong layer—tweaking GEOIP when the banking app never entered the tunnel, or editing app lists when the real issue is a missing DOMAIN-SUFFIX line for a CDN. Write down which symptom you see (slow domestic site versus overseas site not loading) before touching settings.
Proxy-Only List vs. Bypass List: Which Mode to Pick
Most builds expose two complementary modes. One mode sends only checked applications through the VPN interface; everything else stays on the default Android route (commonly described as “proxy only selected apps” or a whitelist). The other mode sends all eligible apps through the tunnel except the ones you check, which bypass (a blacklist-style “these go direct”). Neither is universally “better”; they optimize for different mental models.
| Mode | What it does | Best when |
|---|---|---|
| Proxy only selected (whitelist) | Only listed apps use Clash; others never enter the tunnel. | You want the smallest possible footprint—browser, chat, game—while everything else behaves like stock Android. |
| Bypass selected (blacklist) | All apps use Clash except those you explicitly exclude. | You mostly need a global tunnel but must carve out banking, NFC wallets, or corporate apps that break inside VPN. |
The Chinese UI labels “仅代理” and “绕过” map cleanly onto those two ideas: the former is “only proxy these,” the latter is “bypass these (let them go direct).” Mixing them up produces the classic failure mode where users think they enabled a whitelist but actually excluded their browser from the tunnel, then wonder why nothing routes. After toggling modes, reopen the target app once so it rebinds sockets with the new UID policy.
Some distributions also expose quick presets for system components—webviews, download manager, or tethering helpers. Treat those as advanced: enabling the wrong system UID can starve background updates or break OEM features. Start with user-installed apps you recognize, then expand deliberately.
Step-by-Step: Enabling Per-App Control in Clash Meta
Exact menu paths differ by release, but the workflow is stable enough to document as a checklist. Begin from a known-good profile: import your subscription, confirm nodes load, and verify ordinary browsing works in full-tunnel mode before you fragment traffic. Split debugging is painful when the baseline profile already fails.
- Install and grant VPN permission. Android treats Clash like any other VPN service. Approve the connection request dialog. Without that approval, no per-app nuance matters because the tunnel never comes up.
- Enable the core tunnel mode you intend to keep. If you rely on transparent capture, turn on TUN (or the client’s equivalent) so traffic can be steered consistently. For prerequisites and stack choices, see Clash TUN mode deep dive.
- Open Access Control / Per-App / App Filter. Locate the screen that lists installed packages. Toggle from “all apps” to either proxy-only or bypass mode, matching the strategy you picked earlier.
- Select applications. Use the search box to find by display name. When in doubt, confirm the package id in the details pane—more on that in the next section.
- Apply and restart the VPN session. Fully stop and start the profile; some builds only recompute UID rules on reconnect.
- Validate with two test apps. Keep one app that should be direct (for example a domestic map client) and one that should be proxied (your browser). Verify IP check sites only inside the proxied app.
If your build supports import/export of package lists, keep a dated backup before bulk edits. Accidentally clearing the list after weeks of tuning is surprisingly common when syncing profiles across devices.
Finding Package Names and Verifying Selection
Android identifies apps by package name, not by the icon label you see in the launcher. A browser might ship multiple packages for stable, beta, and lite variants. Selecting the wrong one is harmless but ineffective—the app you actually open still uses a different UID. Reliable ways to read package ids include: the system “App info” screen (often shows the id at the bottom on recent Android versions), Play Store URLs (the id parameter after id=), and lightweight inspector utilities from reputable developers. Enterprise builds sometimes rename packages; trust what the OS reports, not a blog comment from three years ago.
Dual-app or work-profile clones appear as separate entries with distinct UIDs. If you use a sandboxed copy of a messenger, you must tick that clone explicitly. Similarly, webviews spawned inside another shell may still inherit the parent unless the inner app uses its own package; when something “half works,” check whether the traffic originates from a browser process or an embedded component.
For power users maintaining documentation, paste package ids into notes alongside the user-facing name. Future you will thank present you when the icon rebrands but the id stays constant. If you are still deciding which Clash flavor to standardize on, choosing the right Clash client compares maintenance cadence and diagnostics—important when per-app bugs appear only on certain builds.
Example package id format (illustrative)com.android.chrome # Google Chrome stable
org.mozilla.firefox # Firefox
com.tencent.mm # WeChat (example domestic super-app)Keeping Domestic and Banking Apps on DIRECT Paths
Users in mainland China—or anyone who relies heavily on region-locked payment rails—should treat domestic finance and identity apps with extra care. Many of these programs use certificate pinning, multi-factor handshakes tied to the carrier network, or NFC interfaces that assume a non-VPN default route. Putting them through an overseas exit, even briefly, can trigger risk controls unrelated to Clash quality. The pragmatic pattern is: keep those packages on bypass at the per-app layer, then let GEOIP rules handle anything that still reaches the kernel for ordinary browsing.
Super-apps that bundle mini-programs may route child flows through servers you did not anticipate. If a mini-app fails while the main timeline works, capture whether the failure correlates with VPN on/off before you chase remote server issues. Sometimes the fix is simply excluding the parent package entirely during that task.
Educational institutions and employers increasingly ship hardened clients that detect split tunnels. Respect those constraints; no routing article overrides contractual obligations. When in doubt, consult the FAQ’s connectivity notes for DNS and policy interactions that resemble VPN conflicts even though the symptoms look like “app broken.”
When to Add TUN or Subscription Rules on Top
Per-app control solves UID coverage, not DNS leakage or rule granularity. If you need fake-ip consistency, DNS fallback chains, or fine-grained DOMAIN policies, you still configure those in YAML. A typical layered setup looks like: minimal per-app whitelist for everyday phone use, plus a sane rule section that sends Chinese traffic DIRECT and foreign CDNs to the appropriate policy group. That combination is how you avoid the feeling that “domestic sites are slow” while only overseas tabs use the tunnel—because the kernel never steers Alipay traffic through Singapore in the first place.
Hotspot tethering deserves a mention. Sharing your phone’s connection downstream changes which machine owns the packets. Per-app lists on the phone do not magically classify laptop traffic unless that traffic originates from apps on the phone itself. For laptop coverage you usually want a desktop client or a router-level solution—not another round of ticking boxes on Android alone.
Battery and idle behavior also interact with splits. Aggressive OEM power savers may kill the VPN service unless you exempt Clash from battery optimization. That is orthogonal to per-app lists but shows up as “split tunnel randomly reverts when screen off.” Stabilize the tunnel lifetime first, then tune apps.
Troubleshooting Common Split-Tunnel Surprises
Symptom: overseas sites fail even though the browser is on the whitelist. First confirm the tunnel is up (notification icon, in-app status). Then verify you selected the browser package you truly launch—not a stub that redirects to another engine. Finally inspect DNS: split tunnels still need working resolver settings inside Clash; misconfigured DNS can look like “only this app fails” when it is actually failing for all apps but you tested narrowly.
Symptom: domestic apps still feel routed. Check whether you are in bypass mode but forgot to tick them, or whether the app uses a companion service package you did not exclude. Also remember that some analytics SDKs phone home to global endpoints; GEOIP DIRECT does not make that traffic “domestic,” it only marks the destination. That can feel like leakage even when the policy is doing what you asked.
Symptom: instant messaging works in Wi‑Fi but not on mobile data. Carriers sometimes deploy IPv6-only APNs; ensure your profile handles IPv6 consistently with your TUN stack choice. Toggle airplane mode once to flush stale radio state after big setting changes.
Wrap-Up: Split Tunnels You Can Reason About
Per-app routing on Clash Meta for Android is less about secret options and more about disciplined layering: decide which UIDs may enter the tunnel, keep domestic-critical packages on DIRECT at both the OS and rule levels, and reserve YAML complexity for destinations—not for guessing which icon should have been checked. When those layers agree, you get the experience users actually search for: a handful of apps riding the path you trust, the rest of the phone behaving like ordinary Android, and fewer mysterious conflicts with banking or carrier services.
Compared with all-in VPN apps that treat split tunneling as an afterthought, a Meta-class core plus explicit access control tends to age better as your app mix changes—because you can edit lists without throwing away the entire subscription. Pair that with a client that surfaces logs and updates kernels promptly, and routine maintenance stops feeling like superstition.
→ Download Clash for free and experience the difference—whether you need Android, desktop, or a consistent stack across devices, start from a client that makes per-app policies and rule editing something you can verify, not guess.