Why Process Rules Exist Alongside Domain Rules

Most Clash Meta (Mihomo) tutorials start with DOMAIN and DOMAIN-SUFFIX because hostnames are easy to reason about and easy to ship inside remote rule-set files. That works well for browsers and APIs with stable TLS SNI. It is weaker when several unrelated programs share the same CDN, when a game uses raw IP and QUIC, or when you simply want “everything from game.exe” to follow one policy while “everything from excel.exe” follows another. On Windows, the PROCESS-NAME rule type exists so the core can classify the flow by the originating executable before—or together with—domain logic. That matches a clear user intent: not global VPN, but selective routing for a short list of binaries.

Process rules do not replace the rest of your profile; they complement it. You still need sane defaults for everything else, and you still need to understand rule order, MATCH, and rule-provider hygiene so one stray line does not shadow your entire stack. Think of PROCESS-NAME as a narrow “who” dimension layered on top of “where” (domains) and “what IP” (CIDR). If you are new to Clash on desktop, skim how to choose a Clash client first—GUI exporters differ on how they surface advanced rule types, but the underlying YAML vocabulary stays the same.

Crucially, the kernel must see enough context to attach a connection to a process. On Windows, that usually means you are already in the TUN capture path so the Meta core can observe Win32 traffic the way the OS presents it. Relying on a manual system proxy alone often leaves you with domain-only visibility; the executable dimension may never populate. If your goal is executable-level split routing, treat TUN as part of the baseline, not an optional flourish.

ℹ Compliance: Use process-based routing only on machines you administer and where policy allows traffic steering. These techniques configure transport; they do not grant permission to bypass workplace rules, licensing, or regional restrictions you are required to follow.

Prerequisites on Windows: Meta Core, Privilege, and TUN

Clash Meta builds on Mihomo-class features; verify you are actually running a Meta core before hunting for PROCESS-NAME in logs. If you migrated from an older Clash branch, revisit the Meta upgrade guide so your config.yaml keywords match the engine you ship. On Windows, installing a maintained GUI (for example Clash Verge family builds) reduces friction with driver installation and restart prompts.

TUN mode typically requires elevation at least once so the Wintun-style adapter can attach. Follow your client’s installer flow—our Clash Verge Rev on Windows 11 walkthrough walks through subscription import and TUN toggles for first-time users. After the adapter is up, confirm DNS hijack settings align with your dns: stanza; misaligned DNS is the fastest way to think “rule broken” when the real issue is resolver bypass. For the full DNS stack, the Clash Meta DNS guide covers nameserver, fallback, and fake-ip-filter in one place.

If you run workloads in WSL2 or Docker Desktop, remember those are separate network namespaces from Win32. Process rules for chrome.exe do not magically describe Linux curl; for Linux-side traffic you still point environment variables or bridges at the host proxy as described in WSL2 → Windows Clash routing and Docker mixed-port guides.

PROCESS-NAME and PROCESS-PATH Syntax in Mihomo

PROCESS-NAME matches the executable file name (for example chrome.exe or Game.exe). Matching is case-insensitive on Windows in typical builds, but you should still write names exactly as Task Manager shows them to avoid confusion when sharing configs. Some profiles also use PROCESS-PATH when multiple copies of the same filename exist on disk; the full path disambiguates C:\Games\A\launcher.exe from C:\Games\B\launcher.exe. Check your exact core version’s documentation for the precise token name—Meta-class cores evolve quickly, and GUI exporters may hide the raw keyword until you enable “advanced YAML.”

A minimal line looks like:

rules — process name to a policy group (illustrative) 
rules:
  - PROCESS-NAME,chrome.exe,PROXY-GROUP-CHROME
  - PROCESS-NAME,SomeGame.exe,DIRECT
  - MATCH,PROXY

Replace PROXY-GROUP-CHROME with your real group name (the same string you use in proxy-groups:). Keep the comma-separated form consistent with the rest of your file; a single typo in the group name makes the rule silently drop to a lower line or fail validation depending on the client.

Rule Order: Where to Place Process Lines

Clash evaluates rules: from top to bottom. The first match wins. If a broad GEOIP or MATCH sits above your process lines, you will never see the executable rule fire. The discipline is identical to the ordering examples in rules best practices: put specific catches before general ones, and keep a final MATCH that reflects your intended default. If you load remote rule-providers, remember they expand inline—verify the merged order in the client’s “effective config” view, not only your local hand-written block.

When mixing domain rules with process rules, ask which dimension should win for overlapping traffic. Often you want domestic domains to stay DIRECT regardless of app, but a particular game executable forced to DIRECT even when it hits foreign IPs—place those process lines where they cannot be preempted by an accidental GEOIP,CN,DIRECT if that is not what you intend. Document the intent in comments (English comments only) so future edits do not shuffle the order blindly.

Policy Groups, url-test, and Executable Pinning

Process rules do not replace policy groups; they point at them. A typical pattern is PROCESS-NAME,game.exe,GAME-PICK where GAME-PICK is a url-test or fallback group that selects a low-latency node. For the mechanics of latency tests and automatic selection, read policy groups and url-test—the same group objects power both domain-based and process-based steering.

If you only need “this executable uses a proxy” without auto-selection, a simple select group still works. The key is keeping the executable rule readable: one line per critical app, then fall back to the rest of your profile. Avoid duplicating fifteen copies of the same node list; reuse groups instead.

Finding the Real Executable Name and Path

Task Manager’s “Details” tab shows image names. Resource Monitor and Process Explorer go further, revealing full paths and parent-child relationships—useful when a launcher spawns a worker with a different name. Anti-cheat suites sometimes inject into another process; if traffic originates from a helper you did not expect, your process rule must target the binary that actually opens the socket, not the splash screen you clicked.

Microsoft Store and UWP apps often run under opaque host paths. If you see traffic attributed to svchost.exe or a generic container, executable-level rules may be too coarse—consider domain rules or a different deployment model. Traditional Win32 installers usually yield stable .exe names in predictable folders, which is where process routing shines.

Games, Launchers, and UDP Footnotes

Steam and other game stores often split traffic between a launcher (steam.exe) and the actual title (SomeGame.exe). If only the game executable should bypass the proxy, add both names explicitly or accept that launcher traffic follows whatever broader domain rules you already have. For UDP-heavy titles, TUN and firewall expectations differ from a pure HTTP browser profile; pair this article with Steam, UDP, and TUN split routing so you are not debugging process rules while the real issue is UDP forwarding or a mismatch between TUN and system proxy.

DNS Alignment and Reading Connection Logs

When fake-ip is enabled, applications may resolve differently than you expect. If a process rule appears to “do nothing,” open the connection log and confirm whether the flow is even reaching your core’s DNS layer. Reading timeout and TLS lines in logs teaches how to separate DNS failures from proxy handshake failures—apply the same discipline here: verify IP, protocol, and policy group before you rewrite the rule file again.

On Android, per-app routing is a first-class UI concept; on Windows Meta, you are composing YAML. If you compare platforms, see Clash Meta for Android per-app proxy for contrast—the intent is similar, but the implementation differs because mobile VPN APIs expose app UIDs directly.

Limits: UWP, Services, and Shared Host Processes

Not every Windows process is a clean single-purpose binary. System services, update agents, and antivirus shells may multiplex traffic inside shared executables. If multiple unrelated flows share one image name, you cannot distinguish them with PROCESS-NAME alone—fall back to domain rules, IP rules, or accept that some traffic must remain in the default policy. This is a feature of the OS, not a failure of Clash.

Browser extensions and PWAs can also blur lines: the network activity may appear under the browser’s executable even when the site is unrelated. That is still usually what you want if your goal is “everything in Chrome uses this proxy group.”

⚠ Security: Binding TUN and broad capture increases responsibility—keep your Clash management API bound to localhost, use a strong secret, and avoid exposing external-controller to untrusted networks. See the Web UI and external-controller guide for safe defaults.

Troubleshooting When a Rule Never Fires

Work through this checklist before rewriting the rule:

  1. TUN active? Confirm the tunnel adapter is up and the client is not silently falling back to system proxy.
  2. Correct executable? Re-check Task Manager during the exact action that should match.
  3. Rule order? Move the process line above broad GEOIP or MATCH entries that might steal the flow.
  4. IPv4 vs IPv6? If you split stacks, ensure your policy covers the family the app uses.
  5. DNS path? Align DNS hijack with dns: settings; fake-ip surprises mimic routing bugs.

If the process line fires but latency is wrong, the issue is usually upstream—pick a better node or tune your url-test group, not the process keyword itself.

Wrap-Up

Clash Meta on Windows gives you executable-level steering through PROCESS-NAME (and sometimes path-based variants) when the TUN stack can attribute traffic to a real .exe. Pair those lines with the same careful rule order you use everywhere else, bind them to meaningful policy groups, and validate with logs—not guesses. Domain rules and rule-set files remain essential for shared CDNs and system traffic that lacks a friendly binary name; process rules fill the gap for games and desktop tools where the executable is the clearest signal.

Compared with turning on a full-tunnel VPN for the whole machine, a Meta profile that combines process-based routing with selective DNS and stable groups is easier to reason about and faster to debug—especially when you already know how to read rules and routing best practices and TUN behavior.

→ Download Clash for free and experience the difference—pick a Meta-class client with honest TUN diagnostics, then add one or two PROCESS-NAME lines and prove in the log panel that each executable lands where you intended.