Merge Multiple Clash Profiles and Overrides: Step-by-Step Setup for 2026

1. Vocabulary: Profile, Runtime Config, Provider, Override

People use the word “profile” to mean three different things. In most desktop GUIs, a profile is a saved file or bundle the client loads—sometimes a single config.yaml, sometimes a generated cache plus external fragments. The mihomo core, meanwhile, consumes a flattened configuration: whatever the GUI stitched together after downloads, includes, and patches. When this article talks about YAML merge, we mean producing that flattened result without duplicate keys, duplicate proxy names, or contradictory top-level sections.

A proxy-provider (subscription provider) is the structured way to say “fetch nodes from URL X on interval Y and materialize them as proxies.” It is the scalable alternative to copy-pasting hundreds of proxies: lines from two different vendors. An override, in the sense most readers intend, is a smaller YAML fragment—or a GUI-managed patch—that runs after the provider payload is parsed: prepend rules, tweak DNS, pin a tun setting, or rename a policy group without editing the remote subscription text itself.

Keeping those definitions straight matters because the fix for a subscription conflict is rarely “download harder.” It is almost always “change how the merge happens”: isolate providers, namespace names, order rules deterministically, and push local-only differences into overrides instead of into the upstream snippet you cannot control.

2. Why Naive Merging Breaks (and What “Conflict” Really Means)

The most common failure mode is concatenating two full profiles end-to-end. YAML maps cannot have duplicate keys at the same indentation level; the second dns: or tun: block wins unpredictably depending on the parser path, and you lose the first block without noticing. Even when the file still parses, you might inherit two different mixed-port values, two fake-ip filters, or two rules: lists where only one executes as you expect.

Another frequent clash is proxy name collision. Many providers ship nodes labeled “香港 01” or “SS-美国”. If both subscriptions expand into the same flat list, the later duplicate renames or overwrites the earlier one, and your proxy-groups references silently point at the wrong backend. The symptom in the UI looks like random latency spikes or “I picked Tokyo but the IP says Los Angeles.” The underlying issue is not latency; it is namespace.

Finally, merging two rule sets without a strategy produces logical conflicts: both profiles might send Netflix to different groups, or one might MATCH everything to DIRECT near the top while the other assumed a catch-all proxy. The engine is doing exactly what you told it; the merged instructions are simply incompatible. Overrides exist precisely to park your local ordering decisions above provider noise.

rule-providers add another twist: two merged bundles might both fetch large remote rule sets that overlap on popular domains. If you import both without deduplicating or ordering, the first matching line wins and the second provider’s intent never runs. Treat external rules like any other dependency—pin versions, note the download URL in comments, and keep a short “local exceptions” block you fully understand ahead of bulky third-party lists.

3. Pattern A: One YAML, Multiple proxy-providers

The maintainable backbone for Clash multi-subscription merge is a single authoritative base file you own, containing one proxy-providers: map with multiple entries—typically one entry per subscription URL. Each entry points at its own cache path so downloads do not stomp on each other, and each entry can carry its own interval, health-check, and override tweaks permitted by your core build.

Your proxy-groups: section then references members using the provider-qualified names your implementation expects (for example, provider_key.proxy_name in many mihomo-class builds). That single level of indirection is what lets two different vendors both ship “美国 A” without collision, because the provider key disambiguates them.

Below is a minimal illustration only—adapt keys to your client’s schema and verify against the exact core you run:

proxy-providers:
  vendor_a:
    type: http
    url: "https://example.com/sub-a"
    path: ./providers/a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
  vendor_b:
    type: http
    url: "https://example.net/sub-b"
    path: ./providers/b.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "PROXY"
    type: select
    use:
      - vendor_a
      - vendor_b

After you adopt this structure, “adding a third airport” stops being a merge crisis and becomes “append another provider stanza + extend use: lists.” That is the operational win most users are really asking for when they type Clash 多订阅合并-style queries into a translator.

4. Pattern B: Namespaces, Prefixes, and Policy Groups

If your GUI or template still materializes plain proxies: arrays from each subscription, introduce mechanical discipline before you wire rules. Rename groups in the UI if it offers batch prefixing, or split feeds into separate provider keys as shown above. The goal is that no two live proxies share the same final identifier in the merged runtime view.

Policy groups should reflect intent, not vendor identity. A practical stack is: per-vendor url-test or fallback containers (so one bad node does not poison the whole airport), then a user-facing select group that lists those containers plus a DIRECT escape hatch. Readers migrating from older templates may find our url-test and failover tutorial helpful when rebinding those groups after a merge.

When two vendors expose wildly different node quality, resist the temptation to dump every raw proxy into one giant selector. Humans do not enjoy scrolling eighty similarly named lines, and automation (health checks, lazy loading) behaves better when intermediates narrow the set first.

5. Pattern C: Overrides Without Forking the Whole Subscription

Overrides are how you keep upstream subscriptions pristine while still enforcing house rules. Typical uses include: prepending a short list of DOMAIN rules for internal APIs, pinning a nameserver-policy entry for your provider hostname, disabling tun on one machine, or forcing a specific interface-name on laptops with messy multi-homing.

GUI clients differ in how they expose this—some call it “Merge”, “Patch”, or “覆写” depending on localization—but the design pattern is stable: base config (providers + shared scaffolding) plus local overlay (rules/DNS/tun tweaks). Store overlays in version control if you edit by hand; treat provider caches as disposable artifacts that rebuild from the network.

Be explicit about ordering. Overrides that prepend rules should document why they must sit above provider-supplied lists—usually because they carve out LAN segments, captive portals, or subscription endpoints that must not recurse through a local mixed-port loop. If refresh issues appear right after you merged feeds, revisit direct-path exemptions before you assume the remote server is down; the Windows-focused walkthrough linked in the introduction covers the mixed-port loop class of bugs.

6. Pattern D: Separate Profiles vs One Merged File

Not every scenario belongs in a single mega-profile. If your workplace bans tun adapters but home tolerates them, maintaining two saved profile slots—each pointing at the same provider URLs but different override layers—often beats one file with commented blocks you forget to toggle. The mental model is “shared providers, divergent overlays,” not “duplicate everything twice.”

Travel or testing laptops benefit from the same split: a lean profile with aggressive DIRECT rules for captive Wi-Fi, and a full profile for normal use. Synchronize the pieces you care about (provider keys, health-check URLs) through a private git repo or dotfile manager so you are not hand-editing divergent YAML on three devices.

Users coming from legacy Windows clients may recognize this workflow from migration guides such as replacing older Clash for Windows setups—the destination is always a core that understands modern provider maps and patch ordering, even if the filenames changed.

7. Merge Checklist Before You Hit Apply

Walk this list once; it catches most post-merge surprises. First, confirm there is exactly one authoritative dns: tree and that fake-ip filters align with your rule strategy—double DNS sections are a classic silent loser. Second, validate listener ports (mixed-port, redir-port, etc.) for collisions with other local proxies or dev tools.

Third, enumerate proxy names as the core sees them after provider expansion. If your GUI shows duplicates, fix namespaces before tuning latency. Fourth, trace the first five and last five lines of your rules: list; overrides belong where their priority is obvious, not buried mid-file after a forgotten MATCH.

Fifth, trigger a controlled subscription refresh while logging is verbose enough to record failures. If you maintain headless Linux installs, our Debian 12 mihomo setup article illustrates how systemd services and paths interact with provider caches—useful when debugging merge issues outside a GUI.

8. Closing Thoughts

Merging multiple Clash subscriptions is less about secret syntax and more about ownership boundaries: providers fetch remote nodes, your base YAML declares structure, and overrides carry intent that must survive the next upstream refresh. Once those layers are separated, subscription conflict issues shrink from “mystery YAML” to a short set of checks—names, ordering, DNS, listeners—that you can verify in minutes.

Compared with juggling single-use snippets in random editors, a disciplined mihomo profile with explicit proxy-providers and small overlays tends to stay stable across OS updates and client UI changes, which is why power users converge on this pattern even when a one-click import still exists. A maintained desktop client that wraps the same core gives you the guardrails—health checks, logs, tun toggles—without sacrificing transparency.

When you are ready to standardize on a current build and stop fighting merge artifacts, grab the installer from our hub and wire providers once: Download Clash for free and experience the difference.