Organize and switch multiple subscriptions

Get the premise straight first: ten cards can sit in the profile list, but only the active one is running at any moment. Switching profiles is not as light as switching nodes — it swaps the whole thing: nodes, proxy groups, rules, the DNS section. Once that lands, the cost of each of the two approaches below is easy to work out.

Route A: flip the cards by hand

The direct option, and it touches no YAML. Provider A during the working day, provider B in the evening for video, one click on the card. This suits the case where the two profiles already have clearly separate purposes, especially when one of them carries a rule set somebody else wrote that you would rather not disturb.

• Switching rebuilds connections. Downloads in flight break, video stalls, messaging apps on long-lived connections reconnect. Do not do it mid-transfer.
• The two profiles rarely share the same rules. A site that goes through the proxy under A but is sent direct by a rule under B feels like a site that works some days and not others, when really the configuration moved underneath it.
• After switching back, the node selected inside a manual group may not be the one you left there. Group selections are usually remembered per profile.

Route B: merge them with proxy-providers

Turn the idea around: stop treating a subscription as a configuration and treat it as a source of nodes. That is exactly what proxy-providers is for. Each subscription is registered as a provider, the client fetches and caches each one separately, and the nodes flow into proxy groups you wrote yourself. Only nodes come across — the rules and groups stay yours, and nothing from any provider's rule set follows the nodes in.

proxy-providers:
  vendor-a:
    type: http
    url: "https://a.example.com/link?token=AAA"
    path: ./providers/vendor-a.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  vendor-b:
    type: http
    url: "https://b.example.com/link?token=BBB"
    path: ./providers/vendor-b.yaml
    interval: 86400
    filter: "HK|SG|JP"
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
proxy-groups:
  - name: PROXY
    type: select
    use:
      - vendor-a
      - vendor-b

url is that provider's subscription link, the same string you would otherwise paste into the profiles page. path is the local cache file, and the two must not share a filename or they overwrite each other — the symptom is a node count that keeps changing. interval is in seconds, so 86400 is a day. health-check is this set's own latency probe, separate from the global test button. Groups pull providers in through use, which can sit alongside proxies, so hand-written fixed nodes still list next to them. Swap type for url-test if you want the fastest picked automatically.

Merged names collide

• Several providers ship a node called HK 01, and in one combined list there is no telling whose is whose. The cheapest fix is a filter on each provider, a regular expression matched against node names that keeps only the part you actually want — take just the Japan routes from provider B, for instance.
• A wrong filter shows up as that provider contributing nothing at all, and the group losing half its entries. After editing one, check the group still has contents before you go testing latency.
• Recent mihomo builds can rewrite names at the provider level and stamp a common prefix on a source. Which core version a given client embeds varies, so if you are unsure it is supported, use filter to drop the duplicates instead — the practical result is much the same.

What merging costs you

• Traffic and expiry numbers disappear. Those figures come from the subscription response, and once merged your configuration is not itself a subscription, so remaining allowance has to be checked in each provider's own dashboard.
• One dead provider drags on everything. If a provider cannot be fetched, or its whole batch of nodes times out, every health-check round waits on those timeouts and a url-test group visibly slows down. Comment out anything that stays broken.
• Faults get harder to place. Name providers so you recognise them, or the log will not tell you which one is failing.
• The configuration is now yours to maintain. New rules and new groups the provider adds later will never reach you.

Be kind to your future self

Names are worth more than they look. Do not leave a stack of cards all called Subscription — write something you can read at a glance, such as the provider initials plus the expiry month, so scanning the list tells you what is about to lapse. Delete the ones you no longer pay for instead of keeping them around: the client will keep hitting them on schedule, keep failing, and pile up red lines you will have to dig through the next time you are debugging something else. Keep trial subscriptions separate and clear them out when the trial ends.