The Problem: One App on the Proxy, Everything Else Direct

A huge slice of “how do I set Clash for just one program?” questions are really about per-app proxy on Windows. You are not trying to outsmart DNS for every possible hostname a game or downloader might touch. You are trying to say, in plain language: if the packet came from game.exe, send it through my Clash Meta (mihomo) stack; if it came from anything else, keep it on DIRECT unless a broader rule says otherwise. That is exactly the idea behind the PROCESS-NAME rule type, which matches traffic based on the originating process.

This guide stays on Windows and a Meta core because that is the combination people search for when they type “mihomo PROCESS-NAME” or “Clash 按进程分流” into a translator. The syntax is not magical, but the surrounding setup is easy to get wrong. If you are new to the ecosystem, pair this article with the baseline install flow in our Clash for Windows walkthrough so you are not fighting both policy and packaging at once.

Why Clash Meta, and Why TUN Usually Enters the Story

Clash “Meta” refers to the modern rule engine and extensions implemented by the mihomo project (often labeled “Clash Meta” in GUIs). The PROCESS-NAME rule type is part of that extended surface area; older stock Clash Premium docs may not list it, which is one reason your subscription’s generic profile never mentions it. On the desktop, the core can only classify by process when the operating system gives it enough context. On Windows, that typically means you should plan around TUN mode — a transparent path where traffic is lifted into Clash’s pipeline in a way that preserves process identity for matching.

A pure “system proxy” or manual SOCKS assignment can still be useful, but it does not change the fact that for many apps the reliable story is: turn on TUN, then layer PROCESS-NAME lines at the top of your rules section. The architectural picture — virtual adapter, route table behavior, and DNS — is all covered in depth in the Clash TUN mode guide; here we will only restate the minimum: without TUN (or a client-specific equivalent that your GUI documents), do not be surprised if process rules fire inconsistently. Our gaming and UDP TUN article is also a good companion if your target is a real-time game where voice, anti-cheat, and patchers each spawn their own executables.

How PROCESS-NAME Lines Fit the Rule List

Clash evaluates rules from top to bottom and stops at the first match. That sounds obvious until a subscription file inserts a GEOIP,CN,DIRECT line or a catch-all DOMAIN-SUFFIX high in the file. If a broad line wins first, your painstaking PROCESS-NAME work below it will never run. The practical habit is: place process rules near the top of the rules array, directly under any truly global exceptions you still trust (for example, LAN bypasses), and well above “route entire countries” shortcuts. The broader philosophy — strategy groups, MATCH fallbacks, and not letting GeoIP steamroll a precise hostname — is laid out in the Clash rules deep dive; keep that mental model in mind when merging community rule sets.

A minimal skeleton looks like this (names are placeholders; your real proxy-groups and node labels must line up with what the GUI already shows):

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT
  - name: GAME_ONLY
    type: select
    proxies:
      - NODE-A
      - DIRECT

rules:
  - PROCESS-NAME,MyGame.exe,GAME_ONLY
  - PROCESS-NAME,MyGame_Launcher.exe,GAME_ONLY
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,SELECT

Each PROCESS-NAME line has three fields separated by commas: the keyword, the Windows image name (most often something.exe in all lower case is accepted; match the real name the OS reports), and the policy — a proxy group, DIRECT, or REJECT depending on your profile. The example sends two executables to GAME_ONLY while the rest of the world falls through to the usual GEOIP and MATCH lines. Tweak the group to be a single stable node if you are debugging jittery multiplayer sessions.

Finding the Right Executable Name on Windows

Open Task Manager, switch to the Details tab, and look at the “Name” column. That is the string you will usually mirror in the rule. Some titles ship with a launcher (launcher.exe) that spawns a differently named main binary — you may need a line for each process that opens sockets. Download managers and “helper” services (update agents, crash reporters) are repeat offenders: they are separate executables, so a single PROCESS-NAME line will not cover them unless you add more lines or accept that the helper’s traffic follows your default rules instead.

Store apps, packaged runtimes, and some anti-cheat shells run from paths under WindowsApps or temporary directories, but the image name in Task Manager is still the handle you use in YAML. If you are unsure which binary owns a specific connection, use your Clash client’s connection or log view if it shows process names, or use Resource Monitor’s network tab with the same discipline: trust the process column, not the window title. When in doubt, add another line rather than overfitting one fuzzy pattern.

Two Common Policy Shapes (and a Misunderstanding to Avoid)

Pattern A — “Only the foreign game or client uses the proxy”: Put the game executables on a group that points at your exit nodes, and keep GEOIP and MATCH on DIRECT or a conservative “general” group with domestic defaults. This matches the mental model of “I bought a node for that one program.”

Pattern B — “Everything uses the proxy except a few trusted locals”: That is the inverse: most traffic hits SELECT or PROXY in MATCH, and you carve out PROCESS-NAME,workvpn.exe,DIRECT (hypothetically) to exempt a specific binary. PROCESS-NAME is symmetric; it does not only mean “force proxy” — it means “force policy,” and that policy can be DIRECT when the rest of the file would have sent the flow elsewhere.

A frequent misunderstanding is confusing PROCESS-NAME with selective TUN for only one app. TUN, by default, is a wide capture mechanism. What you are doing with process rules is policy selection after the traffic is already visible. If your GUI has a per-app TUN or filter UI, treat it as an optional enhancement, not a substitute for correct YAML order. The English-language configuration documentation on this site also lists the standard rule types so you can double-check field order against your core version.

A Practical Step-by-Step Checklist (Windows, Meta / mihomo)

1. Update the client and core. Process matching improvements land in mihomo over time. Running a stale portable zip is a recipe for “works on one machine” bugs.
2. Back up the profile. Before editing, save a copy of the YAML your GUI is using. A revert file saves hours when a bracket slips.
3. Enable TUN through your client’s safe path. Approve the driver or helper prompts once, then reboot if the vendor asks; Windows’ privilege model is not negotiable here.
4. Create or pick a purpose-built proxy group (for example GAME_ONLY or APP_EXIT) with the nodes you are willing to test. A manual select is easier to reason about than a jittery url-test when you are isolating a single app.
5. Add PROCESS-NAME lines for each relevant executable at the top of the rules list, above regional shortcuts, unless you truly intend those shortcuts to take precedence for everyone.
6. Keep bypasses you still need — for example, IP-CIDR,192.168.0.0/16,DIRECT for LAN printers — but order them intentionally; never assume subscription authors placed them correctly for your per-app experiment.
7. Apply and reload the profile. Use the client’s “reload” or “update config” path so the engine actually reads the new lines.
8. Test with a narrow expectation. Launch only the target app, generate traffic (lobby, login, or a known CDN hit), and watch whether the connection row shows the outbound you named. If not, the rule did not match — revisit executable names and position.

Pitfalls That Look Like “PROCESS-NAME Is Broken”

Wrong or partial executable names are the top cause. A single character mismatch, or a rule that targets the launcher but not the actual game process, will send your traffic to whatever broader rule matches first — which often feels like “Clash is ignoring the game” when it is just matching something else. Add lines incrementally, one binary at a time, and reload between tests.

Over-broad GEOIP or DOMAIN-SUFFIX lines above your process lines are the second cause. This is the same ordering lesson as our domain-focused routing guides, only the symptom is a game stuck on the wrong side of the Great Wall metaphor: the wrong rule won early. Temporarily move PROCESS-NAME to the very top (below only what you are certain must be universal) to prove the mechanism, then reintroduce other rules with clear intent.

UDP and voice stacks may still need the broader TUN, DNS, and node stability guidance from the gaming UDP article. Process names tell you who opened the socket; they do not fix a node that drops UDP or a fake-ip misalignment by themselves.

Child processes, sandboxes, and WSL add noise. A browser that spawns a helper, or a WSL2 distribution that does not use the Windows image name you expect, will not honor a rule written for a different executable. In those cases, you either add more PROCESS-NAME lines, fall back to domain-based routing for that workload, or accept that the workload is a poor fit for process-only steering.

When Domain Rules Stay the Better Tool

Process rules shine when a single binary misbehaves under global policy or when a title fans out to too many hostnames to enumerate. They are a weaker bet when the same executable talks to both domestic and foreign endpoints in ways you want to treat differently, because the matcher does not look at SNI or IP — only process identity. In that case, a hybrid is normal: a couple of DOMAIN-SUFFIX lines for known API hosts, and PROCESS-NAME as a safety net for the rest of the binary’s bursty traffic. The features overview summarizes what the engine can express so you are not overloading one matcher with a job it was never designed for.

Why This Niche Is Worth Documenting for Windows and Meta

Search traffic around per-app proxy and Clash Meta is crowded with generic TUN walkthroughs and with domain cookbooks that assume you want the entire machine on an exit node. The PROCESS-NAME path is different: it is the closest YAML-native expression of “just this .exe” on a desktop, and on Windows the practical pairing is a modern Meta build plus TUN plus ruthless rule order. Get those three right, and the feature stops feeling like folklore and starts behaving like a switch you can hand to a friend who only cares about one game or one stubborn updater.

Compared to ad hoc patchwork — toggling system proxy, juggling browser-only tricks, or banishing one program to a virtual machine — a maintained Clash stack gives you a single place to read logs, a single set of health checks, and a path to keep policy under version control. The ecosystem moves quickly; locking yourself to a single trusted distribution channel for the client, then layering precise rules on top, is how you keep that advantage without turning your evenings into a YAML archaeology project.

→ Download Clash for free and experience the difference when you are ready to run a current Meta-class client and stop duct-taping per-app workarounds to last year’s build.