1 Why TUN matters for process-based rules
Per-app routing sounds simple on paper: write PROCESS-NAME, point it at a proxy-group, and the game uses one exit while the browser uses another. In practice the rule engine can only classify what it can see. Applications that respect a local HTTP or SOCKS port still funnel through user-space hooks; many games, updaters, and daemons do not. When you enable TUN mode, the Mihomo core installs a virtual interface and participates in routing decisions earlier, which is the same layer that makes broad captures possible for tools discussed in our TUN setup walkthrough.
TUN answers “whose packet is this?” far more often than a lone system-proxy toggle does. It does not, by itself, answer “which executable name should appear in my log.” That second question is exactly what find-process-mode controls: whether Clash attempts process resolution for eligible connections, how aggressively it tries, and whether PROCESS-NAME remains a dependable filter or degrades into guesswork. If you skip TUN and expect process rules to behave, you are correlating incomplete observations with strict YAML—a recipe for support tickets.
Keep mode: rule unless you have a deliberate reason not to: global shortcuts bypass the ordered graph where PROCESS-NAME lives. Pair TUN with consistent DNS policy; if hostname fields look wrong while you debug, the Sniffer guide remains relevant because TLS,SNI, and FakeIP issues can obscure the very flows you are trying to attribute to a binary.
2 find-process-mode: strict, always, and off
Official Meta-class documentation describes find-process-mode as the switch that decides whether Clash should match running processes at all. The three supported literals are strict, always, and off. In plain language, strict is the default compromise: the core performs process matching when it decides the workload is warranted instead of hammering every socket. always forces the behavior so that eligible flows consistently attempt a lookup—useful when you live inside PROCESS-NAME rules and still see misses, but potentially expensive on constrained hardware. off disables the mechanism entirely; that is appropriate for headless routers that never rely on executable conditions, but it is the wrong choice on a desktop where you bought Mihomo specifically for per-app splits.
None of these keywords magically invent a process name when the operating system withholds it. If WFP, cgroups, namespaces, or anti-cheat sandboxes hide the owner, your log might show empty or generic attribution no matter how aggressive the mode is. Treat find-process-mode as a performance and coverage dial, not a bypass for OS security boundaries. When upstream releases adjust heuristics between minor versions, re-test after every upgrade instead of assuming identical behavior forever.
strict. Move to always only if your workload depends on reliable PROCESS-NAME hits and logs still show frequent fallback to broader rules. Drop to off only when you confirm you do not use process rules and want to silence lookup overhead entirely.
3 YAML placement and a paste-ready fragment
Like other global tuning keys, find-process-mode belongs beside mode:, log-level:, and ipv6:—top level in the merged profile your client feeds to the core, not nested under tun unless your GUI maps it there visually and re-exports it correctly. If you maintain templates in Git, keep this key close to the other behavioral toggles so diffs stay readable when you flip experimental settings.
mode: rule
ipv6: true
log-level: info
find-process-mode: strict
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
strict-route: true
rules:
- PROCESS-NAME,chrome.exe,Browser
- PROCESS-NAME,firefox.exe,Browser
- DOMAIN-SUFFIX,google.com,Proxy
- MATCH,DIRECT
Replace executable names with values you verified locally; casing must mirror what the OS reports. The sample pairs Mihomo TUN blocks with PROCESS-NAME lines ahead of domain catch-alls. If you park a massive RULE-SET above the executable clauses, domains inside that set will win first and you will mistakenly blame find-process-mode. This ordering pitfall is why readers bounce between our Windows process-name tutorial and Meta docs: both emphasize “first match wins.”
4 Linux: capabilities, systemd, and lookup backends
Desktop Linux remains the friendliest environment for transparent proxy experiments, yet it is also the easiest place to run Mihomo under a service account that lacks the privileges needed to correlate packets with /proc entries or netlink attributes. When you wrap the binary in systemd, confirm the unit grants whatever capability set your distribution documents for packet capture—many guides suggest CAP_NET_ADMIN plus CAP_NET_BIND_SERVICE, but security policies differ across Fedora, Arch, and Debian derivatives.
Containers and network namespaces split the world further: the process name you see on the host may not match the PID namespace where the socket was born. If you deploy on Proxmox LXC or Docker without host networking, expect PROCESS-NAME mappings to disagree with bare-metal reality. Either flatten namespaces for the proxy path or accept that YAML must describe the guest environment, not the names you memorized from the hypervisor shell.
Newer Mihomo builds have experimented with alternate lookup backends (for example, switching between netlink-oriented paths and procfs-style fallbacks) to make Android and odd Linux kernels less painful. When your release notes mention find-process-backend or similar knobs, read them before cargo-culting defaults from last year’s gist—those switches interact directly with the same TUN stack you rely on for autodetect routes documented alongside systemd-oriented installs.
/proc inspection or lock down ambient capabilities can silently break process discovery. If the log floods “process not found” lines right after you tightened a unit file, compare against a known-good service definition before chasing unrelated DNS bugs.
5 Windows: WFP helpers, drivers, and elevation
On Windows, Mihomo’s TUN story usually involves a signed helper and optional elevation. User Account Control prompts are not theater: without the expected privilege level, the driver may load partially while process attribution for fast-path sockets regresses to the very symptoms users describe as “my PROCESS-NAME line never hits.” Accept the official installer flow, keep Defender exceptions aligned with our Defender plus TUN notes, and avoid mixing multiple VPN-class adapters that fight for the same routing table.
Games with kernel anti-cheat frequently spawn child services whose executable names differ from the shortcut on your desktop. That is not a YAML typo; it is the observable process boundary enforced by the vendor. Combine find-process-mode tuning with Task Manager verification the same way you would when building the starter set of rules in the Windows-only routing walkthrough.
Corporate split tunnels add another wrinkle. When a vendor VPN and Mihomo both try to register filters, you may see intermittent success: some launches attribute correctly, others do not, depending on startup order. There is no universal XML recipe; document what works on your fleet and resist shipping a blind profile to every teammate without a validation checklist.
6 When PROCESS-NAME appears “wrong” but YAML is valid
Misleading matches usually trace to architecture, not spelling. Browser sandboxes, GPU helpers, crash reporters, and even auto-updaters can open legitimate HTTPS sessions while the foreground tab belongs to another binary family. If your log shows SomeHelper.exe instead of the AAA title you targeted, the kernel is telling the truth about who owns the socket—you simply aimed the rule at the marketing name instead of the worker process.
The same lesson applies to interpreters. A Python script and a packaged Electron bundle may both say python.exe or node.exe depending on how the vendor ships bits. Process-based rules cannot distinguish two unrelated scripts sharing one runtime executable; you need complementary DOMAIN or IP rules when collisions occur. Treat find-process-mode as part of a layered policy, not the entire brain.
If a DOMAIN rule above your PROCESS-NAME line matches first, no amount of “stricter” process lookup will change the outcome—reorder the list before you chase ghosts in the kernel.
7 Performance, latency, and noisy logs
Setting always can inflate CPU on busy hosts because every eligible flow pays for an extra lookup even when you never reference executable conditions in YAML. On an overpowered workstation the cost is invisible; on a Mi-Fi router or an ARM NAS it may be the difference between stable throughput and watchdog restarts. Watch debug logs sparingly: repeating “process not found” spam often indicates an environment issue, not a missing comma in your config.
Conversely, staying on strict while importing giant remote rule sets can hide the fact that expensive providers refresh more often than you think. Combine this topic with subscription hygiene from the interval and lazy primer so you are not debugging process attribution during the same hour a massive geosite bundle reloads and masks the signal you need.
off when the device never evaluates PROCESS-NAME conditions. Accidentally shipping a desktop profile with always to an OpenWrt-class CPU can overload the poor thing within minutes.
8 Verification workflow you can repeat after every upgrade
- Snapshot the basics: confirm
find-process-mode,tun.enable, andmode: rulein the exported file you actually run. - Pick a canary application with an unmistakable executable name; avoid browsers at first because they spawn many children.
- Reload cleanly and watch connection rows while generating traffic—look at which rule type fires, not only the outbound node.
- Toggle modes deliberately: if
strictmisses, tryalwaystemporarily, observe CPU, then document the lowest setting that still satisfies your policy. - Regression-test systemd or scheduled restarts so your service unit still elevates capabilities after OS updates.
9 Frequently asked questions
What does find-process-mode strict mean in Mihomo?
Strict is the default path: the core decides when to perform process matching instead of forcing lookups everywhere. It is the balanced setting for laptops and desktops that occasionally rely on PROCESS-NAME without turning every flow into an interrogation.
When should I use find-process-mode always?
Switch to always when you have confirmed ordering is correct yet the log still skips executable rules you depend on. Roll back if CPU or log volume spikes—especially on routers or NAS hardware.
Does PROCESS-NAME work without TUN?
Sometimes, for cooperative apps behind a local proxy port, but anything that ignores user hooks needs TUN capture for consistent attribution. Treat bare system-proxy setups as best-effort.
Why does my PROCESS-NAME rule match the wrong program?
Launchers, sandboxes, and shared runtimes reuse executable names across unrelated workloads. Verify the real worker binary and complement process rules with domain or IP coverage when collisions happen.
10 Wrap-up
find-process-mode is the missing manual page for anyone who enabled TUN mode, wrote crisp PROCESS-NAME lines, and still wondered why the dashboard attributed traffic oddly. Lock in strict as your baseline, graduate to always only when evidence demands it, and reserve off for appliances that will never evaluate executable rules. Pair those choices with sane rule order, realistic expectations about launchers, and OS privileges that match how you start Mihomo on Linux or Windows.
Lightweight forks and copy-paste kernels rarely ship a polished UI around these knobs—toggling YAML blindly without live connection context is how people conclude Meta is “buggy” when the issue was simply a DOMAIN rule winning first or a systemd unit missing capabilities. A maintained desktop client with honest config export, readable logs, and one-click TUN setup avoids that wall of abstraction: you see which executable registered, which line matched, and whether bumping find-process-mode changed the story. Compared with juggling brittle shell scripts every reboot, that visibility is worth a lot. If you want the same transparency without stitching half a dozen tools together, the builds we highlight on the download hub skew toward exactly this workflow—especially when you are juggling per-app Clash policy for games, IDEs, and browsers on one machine.
