What “custom split routing” means in plain English
Most people install a Clash-family client because they want a single knob that makes “the internet” feel faster or more reliable. Under the hood, however, the client is constantly answering a boring but important question: for this connection, which outbound path wins? A split routing profile tries to answer that question intelligently—send some traffic through your proxy group, send other traffic direct to your ISP, and maybe park a few domains in a dedicated policy group so you can debug them without destabilizing everything else.
Clash-style cores (including modern Mihomo, still widely labeled Clash Meta in GUIs) implement that decision with two cooperating ideas: policy groups that describe what you can choose, and an ordered rules list that decides which group applies to each flow. Custom rules are simply the lines you add to that ordered list to express your intent. Nothing in that sentence requires you to be a networking professor; it does require patience and a respect for ordering, which we will reinforce until it becomes muscle memory.
If you are still choosing which client exposes these controls in a way you enjoy using, start from the Clash official home page so you do not fight the UI while you are still learning the vocabulary.
Before you write rules: understand policy groups
Beginners often open a config file, scroll to rules:, paste ten lines copied from a forum, and then wonder why nothing changed—or why everything changed at once. The most common missing step is understanding that every routing line ends with a policy target, and that target must already exist as a proxy group, a built-in policy like DIRECT or REJECT, or a subscription-backed selector.
Think of a policy group as a named bucket of behavior. A select-type group might let you pick between two airport nodes. A url-test group might automatically pick the lowest-latency node. A relay chain might pin traffic through a specific sequence. None of that is strictly required reading on day one, but you must internalize this fact: rules do not magically proxy traffic by themselves; they only point at groups you defined earlier. If your rule says PROXY-GROUP,MyGroup yet MyGroup is misspelled, the parser may fail, or worse, you may silently route into a group that is not what you think it is.
When you are learning, keep your topology boring: one group for domestic direct traffic, one group for the tunnel, and maybe one small experimental group for a handful of domains you are testing. Complexity is easy to add later; debugging a forty-group graph on a tired weekday evening is not.
The rules: section is a priority list, not a bag of tricks
The rules: block is an ordered list. The core walks from top to bottom, evaluates each line against the current flow, and stops at the first match. That single mechanic explains more “ghost bugs” than any exotic protocol setting. If a broad rule sits above your careful exception, your exception never runs. If you place a catch-all MATCH line too early, everything below it is dead text.
This ordering discipline is why experienced users treat their rule stack like source code: small commits, clear comments if their toolchain preserves them, and a quick mental model of which region of the file handles which responsibility. Beginners should adopt the same habit on day one, because it prevents the classic failure mode where you keep appending lines to the bottom of a thousand-line file that already ends with MATCH,Final.
A practical reading strategy is to segment the list mentally into four bands: local and LAN bypass, block rules if you use them, split exceptions for specific domains or IP ranges, and broad geo or category rules, followed by a conservative final policy. You do not need every band on the first afternoon, but you should never lose sight of the fact that the list is executed top-down, not “by best intention.”
Rule types you will actually use in your first month
Clash exposes many matchers, but beginners routinely lean on a compact subset that covers real browsing and most APIs. You do not need to memorize the entire dictionary before you ship a useful profile; you need to recognize the shapes so you can read existing configs and copy responsibly.
DOMAIN matches an exact hostname. It is precise and fast when you truly mean one host, but it does nothing for sibling subdomains unless you add more lines. DOMAIN-SUFFIX matches a suffix, which is the workhorse pattern for “everything under this registrable chunk.” DOMAIN-KEYWORD performs a substring match; it is convenient but easy to overfit, so treat it like a power tool with the guard removed.
On the IP side, IP-CIDR expresses a CIDR block. It is ideal for known prefixes that should never wander through a tunnel, or for lab subnets you want to carve out. GEOIP matches a country or region code against geolocation data, which is invaluable for broad “domestic versus foreign” splits when your lists cannot enumerate every cloud IP. Finally, MATCH is the unconditional terminator that picks up everything earlier rules did not catch. If you remember only one advanced keyword today, remember MATCH belongs at the bottom, not sprinkled through the middle like seasoning.
Three ordering recipes that keep beginners out of trouble
Recipe one is LAN and link-local first. Your printer, router admin page, and mDNS chatter should not ride a tunnel because you pasted a huge foreign list above them. Put explicit bypasses early, including private ranges you genuinely use, before you do anything glamorous.
Recipe two is precision before breadth. If you care about a dozen SaaS domains for work, list them with DOMAIN or DOMAIN-SUFFIX before you rely on a blunt GEOIP line that might classify their resolved addresses in surprising ways. This ordering mirrors how humans reason: handle named exceptions first, then fall back to geography or heuristics.
Recipe three is reject noise early if you maintain blocklists. Blocking advertisements, trackers, or malware domains at the policy layer can save bandwidth and reduce log spam, but only if you actually intend those policies. If you do not, skip this band entirely; a half-maintained reject section is worse than none because it becomes the first suspect every time a legitimate site breaks.
The ,no-resolve suffix and why DNS suddenly matters
Many newcomers first meet ,no-resolve when they copy a snippet and notice their latency changes, not because the keyword is magic, but because it changes when the rule is allowed to participate relative to DNS. In simple terms, some IP-based rules can be evaluated before a domain is resolved, and attaching ,no-resolve prevents the matcher from stalling the connection while it waits for an address it does not strictly need yet.
The underlying lesson is bigger than one flag: routing and DNS are coupled. If your DNS pipeline sends queries somewhere unexpected, your domain rules may never see the names you think they see, especially in fake-ip modes where internal representations differ from the public DNS answers you get from dig on a vanilla laptop. When a rule “should” match yet traffic still exits the wrong group, suspect DNS alignment before you rewrite half your list.
For a first profile, keep DNS conservative and documented: know which nameserver entries you set, know whether fake-ip is enabled, and know which domains you exempt from fake-ip if your client supports fine-grained exceptions. Once that mental map exists, returning to ,no-resolve tweaks will feel like tuning rather than mysticism.
A deliberately small YAML-shaped starter pattern
Exact keys vary slightly between clients and versions, so treat the following as pseudocode shaped like YAML, not a drop-in for every GUI export. The pedagogical point is the relationship between groups and rules, not the prettiness of the indentation.
# proxy/proxies sections omitted for brevity
proxy-groups:
- name: "Tunnel"
type: "select"
proxies: ["Node-A", "Node-B", "DIRECT"]
- name: "Domestic"
type: "select"
proxies: ["DIRECT"]
rules:
- "DOMAIN-SUFFIX,local,DIRECT"
- "IP-CIDR,10.0.0.0/8,DIRECT"
- "IP-CIDR,192.168.0.0/16,DIRECT"
- "DOMAIN-SUFFIX,corp.example,Tunnel"
- "GEOIP,CN,Domestic"
- "MATCH,Tunnel"
Read that stack slowly: local names and RFC1918 space exit immediately, a work domain rides the tunnel, domestic IPs classified as CN go direct, and everything else falls into the tunnel through MATCH. Your real life might invert the last line if you prefer a domestic-default posture; the structure stays the same even when the politics of the endpoints change.
Notice how short the example is. A beginner win is a short file you can reread in two minutes. If you need hundreds of lines on day three, consider graduating pieces into rule providers or remote RULE-SET entries once you understand ordering, which is covered at a deeper level in the Clash rule providers advanced tutorial on this blog.
GEOIP is helpful and also honest about its limits
GEOIP,US,Tunnel reads nicely in tutorials, but production reality includes stale databases, anycast networks, and CDNs that do not neatly map to the country you assume from a brand name. Use GEOIP as a coarse sieve, not as a precision scalpel, unless you actively maintain the database and understand the refresh cadence your client uses.
When domestic CDNs front foreign services, you may see outcomes that feel “wrong” until you remember that routing classifies addresses and names you actually observe, not the nationality printed on a marketing slide. Combine GEOIP with a modest set of explicit domain rules for the products you rely on daily; that hybrid is how most stable profiles are built in the real world.
If you operate multiple regions, duplicate the pattern thoughtfully: separate explicit lists per region, then GEOIP bands that match your legal and operational reality. The engine will not judge your business constraints, but your future self will judge unreadable YAML, so favor explicit naming over cute abbreviations.
How to test rules without angering your entire household
Testing routing is a skill adjacent to writing rules. Start with three canaries: one domain you insist goes direct, one domain you insist uses the tunnel, and one DNS-sensitive host such as a captive portal check URL. After each edit, verify those three before you declare victory. If the trio behaves, most consumer browsing behaves, because the long tail is surprisingly correlated with a small set of patterns.
Use your client’s built-in connection table or log view when available; it is slower than guessing, but guessing scales linearly with insomnia. Where possible, prefer tools that show the matched rule or group, not only the final egress IP, because “wrong IP” symptoms often trace back to an earlier mis-ordered line rather than a dead node.
When something regresses, revert the last change. Git users can treat profiles like code; GUI users can export snapshots before edits. The worst debugging sessions come from five simultaneous untested tweaks, not from one conservative line you can bisect in minutes.
GUIs versus text: two surfaces, one engine
Many excellent clients hide YAML behind toggles, tables, and drag-and-drop ordering. That is healthy for beginners as long as you occasionally export the effective profile and skim the generated rules: section. Exports teach you what the GUI actually asked the core to do, which prevents the drift where the UI shows one story and the file on disk tells another.
When you are ready to install or switch clients without turning downloads into a treasure hunt, use the Clash download page on this site as the primary entry for bundles that match the documentation tone here. Upstream repositories remain useful for reading source and filing issues, but they should not be your first stop when you simply need a trustworthy installer path.
Common pitfalls that look like “Clash is broken”
Mis-typed group names produce errors or silent misrouting depending on validation settings. Duplicate mutually exclusive rules create confusion because only the first match wins; the second line is not a vote. Over-broad DOMAIN-KEYWORD rules catch unintended hosts and are surprisingly difficult to unwind weeks later because you forgot why the keyword seemed clever at two in the morning.
Another frequent trap is chasing latency numbers while ignoring policy. A fast node with a bad rule stack still feels sluggish because TLS handshakes repeat, DNS takes scenic routes, or QUIC falls back in ways your rules unintentionally encourage. Fix policy first, then optimize nodes.
Finally, remember that not every application honors system proxy settings. If you need IP-layer coverage, you may eventually explore TUN mode, which is a different article with different privileges and platform caveats. Rules still matter in TUN; only the class of traffic you can see changes.
Where to go after your first working stack
Once you trust your short rule list, you can grow in two directions. Vertically, deepen DNS knowledge and learn how fake-ip interacts with the domains you personally use. Horizontally, adopt remote lists through providers so your main file stays readable. Both directions reward the same discipline: small ordered layers with clear ownership, not a single megabyte of pasted community rules nobody on your team understands.
If you want a structured doc hub in addition to blog posts, skim the Clash documentation hub for client-specific notes that complement the engine-level concepts here.
Closing thoughts
Writing custom split rules is less about memorizing every matcher and more about respecting a simple contract: groups define possible outcomes; rules pick outcomes in strict priority order; DNS reality decides what names and addresses your matchers actually see. When those three truths line up, Clash-class clients feel calm—predictable routes, readable logs, and incremental edits that do not require a social-media thread to justify.
Compared with treating every connection as a nail for the same all-proxy hammer, a thoughtful rule stack saves battery on laptops, reduces unnecessary round trips for domestic CDNs, and makes oddball SaaS tools debuggable because you gave them an explicit line instead of hoping geography guesses your intent. That stability is worth the hour you spend learning vocabulary upfront.