Who actually needs a relay chain?
A single outbound node is enough when your only question is “which country shows up on the far side.” A relay answers a different question: “which path do packets take through two controlled hops before they touch the destination?” Common motivations in 2026 home labs include: using a stable, low-latency front server close to you while choosing a different exit region for unlocking or latency to specific SaaS edges; separating trust boundaries so one provider never sees both your home metadata pattern and the final destination in one tidy flow; or following a subscription layout where certain nodes are only reachable through another hop. None of this replaces legal or contractual obligations—policy is yours—but technically, relay is how Clash Meta expresses that intent in YAML without bolting an external tunnel manager in front of the core.
If you are still fighting basic split routing—for example, domestic CDNs accidentally steered overseas—finish aligning GEOIP/GEOSITE rule order and DNS/FakeIP first. Chains amplify confusion when the core never selects the group you think it does. Stability before topology.
Mental model: relay is just another proxy group
In Mihomo, a relay is declared under proxy-groups with type: relay. The group composes existing leaf proxies (or other groups, depending on your profile complexity) into a chain. Traffic sent to that group is forwarded through the listed proxies in order: the first name is the first hop from the perspective of your core, the second name is the next hop, and so on. That ordering is the piece people invert when they expect the “exit” to appear first in the list. Memorize the operational rule: list hops from client-side to internet-side, matching how you would narrate the path aloud.
Relay chains do not suspend the rest of your profile physics. Policy selection still happens in the rules section: if a broad MATCH line fires before your domain-specific lines, your painstaking relay group may never run. Likewise, DNS answers that disagree with rule predicates still produce “wrong outbound” symptoms that look like a broken chain but are ordinary ordering or resolver issues. Keep the mental stack: capture path (TUN or system proxy) → DNS truth → rule match → group internals (relay health).
Copy-ready YAML: proxies plus a relay group
The following skeleton is pedagogical. Replace server placeholders with your subscription’s real proxy names as they appear in the proxies section, and rename groups to fit your style. The only structural requirement is that every name referenced in proxies: under the relay already exists as a defined proxy or a compatible group per your core version.
# Leaf proxies (examples — use your real server blocks)
proxies:
- name: ENTRY-NODE
type: ss
server: entry.example.com
port: 8388
cipher: aes-256-gcm
password: "REPLACE_ME"
- name: EXIT-NODE
type: vmess
server: exit.example.net
port: 443
uuid: 00000000-0000-0000-0000-000000000000
alterId: 0
tls: true
servername: exit.example.net
proxy-groups:
- name: RELAY-ENTRY-EXIT
type: relay
proxies:
- ENTRY-NODE
- EXIT-NODE
- name: PROXY
type: select
proxies:
- RELAY-ENTRY-EXIT
- ENTRY-NODE
- EXIT-NODE
- DIRECT
Notes that save hours: keep relay chains in a select or url-test umbrella if you want manual switching; if you reference the relay only from rules, you can skip the umbrella and point rules straight at RELAY-ENTRY-EXIT. Avoid circular definitions—your relay members should be leaf nodes or groups that do not eventually include the relay itself. If your provider ships identically named nodes after every refresh, pin stable names in a local override file rather than chasing subscription churn inside the chain.
Hop order: ENTRY-NODE then EXIT-NODE means the core connects to the entry first and tunnels toward the exit. Swap them only when you truly intend the opposite path.
Wire the chain into rules
Relay debugging begins with a boring question: did any rule send your flow to the relay group? Paste your chain name exactly as declared—YAML is unforgiving about typos—and place targeted lines above lazy catch-alls. A typical pattern for overseas SaaS is a stack of DOMAIN-SUFFIX / GEOSITE lines pointing at RELAY-ENTRY-EXIT, followed by domestic or private bypasses, then GEOIP and MATCH. If you import community rule providers, remember remote files can reorder during updates; keep a short local tail you control for chains and high-intent domains. For a deeper pass on list-based routing, re-read the GEOIP/GEOSITE guide—the same ordering discipline applies; relay does not get a free pass to the front of the list.
# Illustrative tail — adapt to your profile
rules:
- DOMAIN-SUFFIX,service.example,RELAY-ENTRY-EXIT
- GEOIP,CN,DIRECT
- MATCH,PROXYWhen symptoms look like “only some tabs use the chain,” suspect Sniffer and HTTPS/QUIC host recovery before you rip the relay apart. Meta’s Sniffer can change which hostname the rule engine sees; if you already tuned Sniffer for other guides, apply the same discipline here. Mixed wire-format clients (HTTP/3-heavy sites) can shift SNI visibility—your chain is fine while the matcher is looking at the wrong string.
DNS: why chains still depend on resolver alignment
Relay groups forward IP traffic; they do not automatically rewrite how the operating system or the core resolves names. If your DNS stack answers with an unexpected IP class—say, a domestic anycast address for a global SaaS—your GEOIP lines may classify the flow before a domain rule would have matched, or you may hit a no-resolve pitfall when combining IP-CIDR with stale caches. Before you assume hop two is flaky, confirm the query path: FakeIP versus redir-host, whether DoH/DoT to an overseas resolver is actually in use, and that the core’s DNS section matches what the DNS leak article recommends for your platform. A chain that “works in curl but not in the browser” is often two different resolver stories, not two different relay implementations.
For domain-typed rules, ensure the name seen by the rule engine is the same name you think you wrote. With FakeIP, the mapping table must stay coherent across reloads; with Sniffer-assisted HTTPS flows, the recovered host should align with your DOMAIN rules. When in doubt, log at info level, pick one failing site, and read which rule index matched—boredom beats guessing which hop failed.
UDP, full cone, and per-hop capabilities
Two-hop paths multiply assumptions. Some protocols need UDP end-to-end; others degrade gracefully. If either hop blocks or mishandles UDP, VoIP, certain games, or QUIC-heavy sites may fail while plain TCP browsing looks fine. Test with intention: toggle one hop at a time by temporarily pointing a test rule at ENTRY-NODE only, then at EXIT-NODE only, then at the relay. If UDP works on single hops but not in chain, you may be hitting a limitation of chaining that protocol through those providers—document the finding instead of fighting the YAML syntax.
NAT behavior and “full cone” discussions show up often in gaming forums; relay does not invent UDP magic. If the exit must expose a predictable mapping for a peer-to-peer session, both hops must preserve the semantics your application expects. When uncertain, prefer TCP-first sites for verification, then introduce UDP-heavy tests after TCP is stable.
Troubleshooting order that actually finishes
Use a fixed sequence so you do not thrash: (1) Confirm the profile loads—fix YAML indentation and unknown proxy names first. (2) Confirm a rule sends test traffic to the relay group—watch the connection panel or logs for the selected policy. (3) Validate DNS answers and rule matches for that flow—ensure the domain rule fires where intended. (4) Isolate hops—single-hop selectors for the same destination to compare error codes and latency. (5) Revisit UDP-specific cases last, with controlled apps rather than a dozen variables at once.
1Parse and load
Reload the profile and read the core log for parser errors. A relay referencing a renamed subscription node fails closed; the error message is usually explicit. Keep a minimal reproducible profile snippet while debugging.
2Prove policy selection
Hit a canary domain you tied to RELAY-ENTRY-EXIT and verify the UI shows that group. If it shows DIRECT or a different selector, your rules—not your relay—are the bug.
3Align DNS with rule types
For IP-based rules, ensure resolution mode matches (no-resolve pitfalls). For domain rules, ensure the hostname seen by the engine matches your lines. Cross-check with the DNS article when FakeIP behaves “almost right.”
4Bisect hops
Route the same test to entry-only and exit-only policies. If entry-only works but the relay fails, inspect ordering and names; if exit-only fails, fix exit health before chaining.
5UDP and application matrix
After TCP stability, test one UDP-aware client. Document provider quirks—you will thank yourself next month when subscriptions refresh.
Security note: relay chains change path properties, not laws of physics; they are not a substitute for endpoint security or trustworthy operators.
TUN and system proxy interactions
If you run TUN, the dataplane already captures most applications consistently; relay groups behave the same as any other outbound once rules match. If you run system-proxy-only mode, ensure the apps you test actually honor those settings—some binaries ignore them and will never hit your relay even when the YAML is perfect. For TUN setup details, follow your client’s vendor guide end to end before you optimize hop count.
Open source, downloads, and trust
Mihomo and Meta-class cores publish sources and release notes; reading the diff helps when a minor release tweaks group behavior. For installers, use the official Clash download page; treat GitHub as transparency for builds and issues, not the only place to fetch binaries.
Summary
Relay chains in Clash Meta let you stack two (or more) proxies by declaring type: relay under proxy-groups and listing hops in client-to-internet order. Wire the resulting group into rules above broad catch-alls, keep DNS aligned with how your rules classify flows, and validate policy selection before you blame a distant hop. Treat UDP as a second-phase test after TCP paths behave, and bisect entry versus exit when symptoms split cleanly. Done calmly, relay is less exotic than it sounds—it is structured forwarding with a clear checklist.
When logs agree with your intent, you spend less time rearranging nodes and more time using the services you actually routed through them.