HenryChiao/MIHOMO_YAMLS: a daily-rebuilt Mihomo config repository

What MIHOMO_YAMLS actually solves for Mihomo users

Mihomo, the core formerly known as Clash Meta, reads a single YAML file that defines proxies, proxy groups and routing rules. Writing that file from scratch means knowing the rule-provider syntax, choosing which rule sets to pull, and keeping the whole thing current as upstream lists change. MIHOMO_YAMLS is an attempt to remove that work: the README describes it as a curated collection of configurations built specifically for the Mihomo / Clash Meta core, with a daily automated fetch that keeps configurations and rules current.

The audience is stated plainly. The README's beginner note tells first-time users not to edit the configuration file directly, and says that using a subscription conversion or the project's hosted templates is usually more stable than manual edits. That is an honest framing: this is a distribution of ready-made configs, not a config generator you tune. The repository layout backs it up, with separate directories for the YAML files (THEYAMLS/), overrides (Overwrite/), user customizations (custom/), documentation (THEDOC/) and the automation (scripts/).

One caveat about the pitch. The README leans on a star badge and a fork badge in its header, and closes by asking readers to star the repository. Those numbers say nothing about whether the rules inside are correct for your network, and the README itself does not claim they do.

How the daily build and rule-provider layout fit together

The mechanism visible in the repository is a scheduled job, not a running service. A scripts/ directory sits at the top level, and the README states that an automation script fetches upstream sources every day. The output of that job is what users consume: the THEYAMLS/ directory holds the YAML files, and Overwrite/ holds the pieces meant to override defaults. The README also links a dedicated ruleset document, THEDOC/RULESET_README.md, which it describes as explaining the traffic-splitting mechanism and how to customize it.

Rule sets in Mihomo are referenced through the rule-providers block, which points at remote lists and tells the core how to fetch and parse them. The repository's own documentation is the place to confirm the exact provider names and URLs it ships, because the README does not reproduce them. What the README does state is where the data comes from: THEDOC/CREDITS.md is described as the source list for the integrated community resources.

The release history shows the automation's cadence in a concrete way. Releases are named like backup-2026-09-21_22-35 with the title "Auto Backup: 2026-09-21_22-35", and three appear in the recent list, on 2026-09-17 and 2026-09-21. So the published artifacts are timestamped snapshots rather than numbered versions. If you need to know what changed between two builds, you diff two tags; the repository does not present a per-rule changelog.

Getting a Mihomo YAML file and loading it into a client

There is no package to install. The README routes readers to a client list at THEDOC/CLIENTS.md, which it describes as a roundup of Mihomo and Meta clients across platforms, and to the usage document at THEDOC/THE_REAL_README.md for the configuration categories. The README does not give a download command or a clone command, so the practical starting point is the repository's own web page, where you open THEYAMLS/ and pick a YAML file, or open the releases list and take one of the dated backup tags.

Once you have a file, open it and add your own proxy entries, since the repository ships routing and rule structure rather than your credentials. The README's beginner note advises against hand-editing the shipped configs and suggests a subscription conversion or the hosted template instead, so treat a local copy as the path for people who intend to customize.

Then point your client at the file. Mihomo clients generally accept a local YAML path or a URL, and THEDOC/CLIENTS.md is the place to match a client to your platform. The README does not document a rollback procedure for a config you have already loaded, so keep the previous file until the new one is confirmed working.

If you want to know which snapshot you are running, the release tags carry the timestamp in their name, as in backup-2026-09-21_22-35. Note that name down next to the file you saved; it is the only version marker the repository publishes.

Where MIHOMO_YAMLS is the wrong tool

The first limitation is provenance depth. The README says the data comes from the open source community and points at THEDOC/CREDITS.md, but a curated aggregation inherits whatever the upstream lists contain. If your threat model requires every domain in a routing list to be reviewed by your own team, an auto-fetched daily build is the opposite of what you want, because the contents can change without a review step you control.

The second is the update model. Dated backup tags tell you when a build happened, not what changed inside it. There is no evidence in the README of a semantic version, a migration note, or a compatibility statement against a specific Mihomo core release. A rule-provider entry that a newer core parses differently will surface as a client-side error, and the repository does not document a compatibility matrix.

The third is scope. This is a configuration repository, not a proxy service and not a client. It ships no nodes and no credentials. If your actual problem is that you have no working proxy endpoint, no YAML file here fixes that. The README's disclaimer also restricts redistribution and posting to public platforms in mainland China, and states the project is for technical exchange and study, which is a boundary on how the files may be passed around.

MIHOMO_YAMLS versus writing your own Mihomo config

The real alternative is not another repository. It is the Mihomo documentation plus your own YAML file, or a subscription conversion service that generates a config from your provider's link. The difference is where the rule logic lives. With a hand-written config, you own every rule-provider URL, every proxy group, and the order in which rules are matched, and you can put the file in your own git repository with a commit message for each change. With MIHOMO_YAMLS, you inherit a routing design that someone else chose and that is rebuilt on a schedule.

That trade is reasonable when you want to be running within ten minutes and you do not care which ad-blocking or streaming rule set handles a given domain. It is a bad trade when a misrouted domain has a cost, for example when a corporate endpoint must never leave a direct route. A subscription conversion sits between the two: it still generates rules for you, but the output is tied to your provider and you can diff it before loading.

The README acknowledges this split by pointing advanced users at the project's Wiki, which it says explains configuration syntax and design rationale. That is the honest path for anyone who outgrows the prebuilt files: read the Wiki, then fork the repository and maintain your own branch.

Maintenance cost, licence and what to check before adopting

The repository is not archived, and the last push was on 2026-09-23, so the automation is current as of that date. The release list shows backup builds on 2026-09-17 and 2026-09-21, which is consistent with the README's claim of a daily fetch, though the gaps between those timestamps suggest the schedule is not perfectly regular. For an operator, the ongoing cost is not patching: it is re-pulling the config when upstream rule sets change and confirming your client still loads it. Budget for that check after every backup you adopt.

The licence is AGPL-3.0, shown in the repository's LICENSE file and in the README badge row. That is a copyleft licence with a network-use clause. If you redistribute these files or run a modified version as a network service, the licence terms apply to your distribution, and the README separately prohibits reposting to public platforms in mainland China. This is a description of the terms, not legal advice; read LICENSE and, if your use is commercial or public-facing, get your own review.

The upgrade path is manual by design. There is no package manager entry and no documented self-update command, so upgrading means fetching a newer release tag or re-downloading the file from THEYAMLS/ and reloading it in your client.

Editorial conclusion

Adopt MIHOMO_YAMLS if you run a Mihomo or Clash Meta client and want a maintained starting point rather than a hand-written config, and if you accept that the rules are assembled from upstream community sources listed in THEDOC/CREDITS.md. Do not adopt it if your environment requires a pinned, reviewed rule set with a changelog per rule, because the repository publishes dated backup releases rather than a semantic version history. Before pointing a client at it, open THEDOC/RULESET_README.md to see how traffic is split, and check the newest backup tag to confirm the automation is still producing builds.

Frequently asked questions

Official sources

1. HenryChiao/MIHOMO_YAMLS on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases