How to Route Apps by Process in Clash Meta: PROCESS-NAME Rules Step by Step (2026)

Search intent: who actually needs process-level rules?

If your only goal is “Chrome uses the proxy while everything else is direct,” a crisp stack of DOMAIN-SUFFIX lines plus a conservative MATCH often works because Chromium respects the operating system proxy table when you tell it to. The moment you meet binaries that ship their own TLS stacks, hard-code resolution, or refuse to read WinINET settings, domain rules still decide where packets go after they already reached Clash—but those packets may never reach Clash at all unless you capture them with TUN or an equivalent system dataplane. PROCESS-NAME shines when the traffic is visible to the core and you want the decision to depend on which program originated it: send steam.exe or Battle.net.exe through a low-latency group, keep OneDrive.exe on DIRECT, and stop fighting a downloader that pretends your corporate HTTP proxy does not exist.

Another common scenario is mixed workloads on one laptop: a developer runs IDEs and containers locally while a single browser profile consumes overseas SaaS. You might already split by domain for the SaaS hosts, yet a second browser or an Electron app duplicates part of that graph with different SNIs. Process rules reduce ambiguity: the policy line names the binary, not just the hostname. That is not a silver bullet—child processes and sandboxed renderers still matter—but it is a readable layer many power users prefer once Clash Meta is already steering the default route through TUN.

Mental model: rules still run top to bottom

Nothing in Mihomo repeals the basics: the rule section is an ordered list, first match wins, and sloppy ordering creates ghosts that look like “DNS bugs” or “random resets.” PROCESS-NAME is another predicate in that list, alongside DOMAIN, IP-CIDR, and friends. If a broad GEOIP or MATCH line sits above your process lines, you will never observe the behavior you think you wrote. Treat process rules as a precision layer inserted after cheap local bypasses (RFC1918, captive portal checks, mDNS) but before lazy catch-alls. When in doubt, open the client UI, click a live flow, and read which rule index fired—boredom beats superstition.

Prerequisites: TUN, permissions, and a Meta-class core

PROCESS-NAME matching depends on the dataplane attaching process metadata to connections your core classifies. On desktop clients this almost always means you have enabled TUN mode (or another capture path your GUI documents as supplying process names). System-proxy-only setups may still show some process information depending on the OS hook, but the reliable story for 2026 home labs is: install the client correctly, elevate where the vendor requires it on Windows (Service Mode / administrator expectations per product generation), approve the Network Extension or helper prompts on macOS, then confirm in the log that flows list a process field instead of a blank.

If you are new to TUN installation, follow the Clash Verge Rev TUN mode guide before you tune process rules—otherwise you will tune YAML while packets never traverse the tunnel. Windows readers should also skim the Windows setup guide for mixed ports and service prerequisites; macOS readers dealing with stubborn system-proxy behavior should read macOS system proxy troubleshooting to separate Keychain issues from routing issues.

In the global section of your profile, Mihomo exposes find-process-mode: strict (typical default—the core decides when matching is feasible), always (force process resolution where the platform supports it), or off (disable, common on routers). If logs never show process metadata despite working TUN, confirm this knob is not off before you rip apart rule providers.

# Global snippet (illustrative)
find-process-mode: strict

YAML syntax for PROCESS-NAME (and when to prefer PROCESS-PATH)

The shape is intentionally plain: a rule type token, a comma, the process identifier, another comma, then a policy target (built-in action or proxy group name). Example skeletons:

# Illustrative — replace group names with yours
PROCESS-NAME,chrome.exe,Browser-Proxy
PROCESS-NAME,msedge.exe,Browser-Proxy
PROCESS-NAME,Steam.exe,Game-LowLatency
PROCESS-NAME,qbittorrent.exe,DIRECT

On many builds you can also target a fuller path with PROCESS-PATH when two different installations share the same executable name and you truly need disambiguation—think multiple portable browsers. Paths are sharper but brittle across upgrades that relocate Program Files subtrees, so default to PROCESS-NAME until you prove a collision. Always mirror the spelling your OS lists: Windows images usually ship chrome.exe in lowercase, while some games ship mixed-case names that still matter when the matcher is case-sensitive on a given platform build.

Windows: executable names, services, and UWP edge cases

Most Win32 programs expose a simple image name such as firefox.exe or Code.exe. That is what you type into PROCESS-NAME in many profiles. Universal Windows Platform apps are messier: traffic might originate from svchost.exe wrappers or host processes unless the vendor documents a dedicated broker. If you see everything lumped under generic hosts, domain rules plus loopback tooling may remain the more honest lever—our UWP loopback article explains why some Microsoft Store apps resist simplistic splits.

Games and anti-cheat stacks sometimes spawn launchers that exit after handing work to a child. Watch the actual process tied to the socket in your client log rather than assuming the launcher name persists. Download managers often fork a worker: your rule may need to target the worker executable, not only the GUI shell. When a single vendor uses multiple binaries (update service, renderer, crash reporter), decide whether you want all of them on the same outbound or only the gameplay binary—policy is a product decision, not something YAML guesses for you.

macOS: app bundles, helpers, and permission prompts

macOS surfaces Unix process names that may differ from the pretty name in Finder. Chromium-based browsers might appear as you expect, yet auxiliary helpers can show up with distinct names during updates or GPU work. Use Activity Monitor or the connection inspector in your GUI to copy the identifier you see beside live flows. After OS upgrades, Apple may tighten privacy prompts; if the helper lacks permission to report metadata, you will see gaps that look like broken rules but are really visibility issues.

Because macOS developers love nested frameworks inside .app bundles, resist the urge to paste full bundle paths everywhere unless you maintain automation that rewrites profiles on every patch Tuesday equivalent. A hybrid approach—PROCESS-NAME for the stable binary, PROCESS-PATH only for collisions—keeps diffs small and reviewable in Git.

Step-by-step profile workflow

1Stabilize TUN and confirm process visibility

Reload a trivial site in a browser while the connections pane is open. You should see process labels populated. If the field is empty for every flow, stop editing rules and fix installation, SIP-related prompts, or VPN conflicts first.

2Inventory the binaries you care about

Export a short table: executable name, whether it should be proxied, and the target group. Keep the list short; long lists rot when apps auto-update and rename helpers.

3Insert PROCESS-NAME lines in the correct region

Place them after LAN and domestic bypass lines you trust, and before wide GEOIP or MATCH entries. Comment the section so future you remembers the intent (“Games 2026Q2” beats “misc”).

4Reload and test one app at a time

Change one executable per reload so regressions are bisectable. Capture a screenshot or log snippet when it works—future troubleshooting will reference it.

Example blocks: browser-only proxy with everything else direct

The following block is pedagogical, not a universal truth for every subscription. It assumes you already defined groups Browser-Proxy and REJECT (or your provider’s equivalents) and that you want domestic traffic patterns untouched except for named browsers:

# Local and RFC1918 bypasses should precede this section in real profiles
PROCESS-NAME,chrome.exe,Browser-Proxy
PROCESS-NAME,msedge.exe,Browser-Proxy
PROCESS-NAME,firefox.exe,Browser-Proxy
PROCESS-NAME,Safari,Browser-Proxy
# Optional: keep a torrent client explicitly direct to avoid surprise uploads via remote exit
PROCESS-NAME,qbittorrent.exe,DIRECT
# ... then your broader GEOIP / MATCH logic

Notice the tension: Safari on macOS may appear exactly as Safari in some logs; other builds or locales can differ. Never trust this page’s spelling more than you trust your own client log. Swap Browser-Proxy for a group that includes auto fallback if your goal is resilience rather than minimalism.

DNS alignment so domain and process rules agree

Process rules do not remove the need for coherent DNS policy. If FakeIP answers disagree with what the OS resolver cached, you can still match the wrong outbound even when the process name is correct. When symptoms look like “random misses,” read Meta core DNS leak prevention before you duplicate PROCESS-NAME lines in frustration. The triage order remains: capture path, DNS alignment, rule order, then node health.

Pitfalls that waste weekends

• Case sensitivity and spelling: Chrome.exe versus chrome.exe can bite depending on platform conventions—copy from logs, do not memorize from old forum posts.
• Child processes: the renderer might differ from the main binary; watch the actual row in the connection table.
• Order traps: an early MATCH sends everything somewhere you did not intend—process lines below it are dead code.
• Overfitting: fifty PROCESS-NAME lines without comments becomes a maintenance nightmare after two client updates.
• Security assumptions: trusting a process name is not the same as authenticating software; malware can rename itself—process rules are convenience, not endpoint security.

Verification and logging habits

After each profile reload, run three checks: open a proxied app and confirm the first matching rule in the UI; open a deliberately direct app and confirm it never borrows the browser group; start a short download and confirm the downloader policy matches your ethics (some users want torrent clients always DIRECT to avoid sending unrelated traffic through a stranger’s VPS). Export logs sparingly and redact subscription URLs before pasting them into tickets—your privacy matters more than a screenshot’s impressiveness.

How process rules complement domain lists and rule providers

Community rule providers excel at tracking CDN churn for large SaaS footprints; they are poor at encoding your personal “only this IDE” story. Pair remote lists with a tiny local tail that contains both DOMAIN-SUFFIX overrides you care about and PROCESS-NAME precision for apps that ignore proxies. When upstream lists reorder themselves during a midnight refresh, your local tail should remain stable because you control the file. That separation—remote bulk, local intent—is how advanced profiles stay debuggable for months instead of hours.

Open source, downloads, and trust

Mihomo and Meta-class cores publish sources and changelogs so you can diff behavior across versions—useful when a release note mentions matcher tweaks. For installers, prefer the official Clash download page; treat GitHub as engineering transparency, not the only distribution channel.

Summary

PROCESS-NAME rules in Clash Meta let you steer traffic by executable once TUN (or an equivalent capture path) makes flows visible. On Windows, prefer accurate .exe spellings from logs; on macOS, expect bundle-related helpers and permission prompts. Keep YAML ordered with bypasses first and catch-alls last, align DNS with FakeIP and DoH guidance, and verify each app individually. Compared with toggling global modes every time one stubborn program misbehaves, a short process section is dull—and dull is what you want from network policy.

When your client stays readable and logs agree with intuition, you spend less time guessing and more time using the apps you actually care about.

→ Download Clash for free and experience the difference