A tutorial collection that treats geodata and ruleset as two different problems

It is a Jekyll site, not a software project

The repository is a documentation site. The top level listing gives it away: `_config.yml`, `_posts/`, `_data/`, `_plugins/`, `_tabs/`, `assets/`, `tools/`, a `Gemfile`, an `index.html` and a `.nojekyll` file.

Those are Jekyll conventions throughout. `_posts/` holds dated entries, `_data/` holds structured content that templates iterate, `_tabs/` builds navigation, and `_plugins/` holds Ruby extensions that run at build time. The `.nojekyll` file tells GitHub Pages to serve the directory as plain files, which means what is served is the built output committed or generated by the site tooling.

There is a `.devcontainer/` and a `.vscode/`, which suggests a defined local editing environment rather than a one-off blog. `.gitmodules` at the root indicates at least one submodule, consistent with the `tools/` directory holding external tooling rather than site content.

So there is nothing to install and nothing to run. The deliverable is knowledge, and the primary language detected is Shell because of the configuration examples the tutorials reproduce.

The published site is at proxy-tutorials.dustinwin.cc.cd, and that is the URL to read rather than the repository.

The core-to-wiki mapping is the first thing to use

The README states the collection is written against two specific core builds: the mihomo core from MetaCubeX, and the sing-box reF1nd edition core from the reF1nd project. It asks readers to use the latest core version and points to a separate proxy-tools repository for updating.

That fork detail matters and is easy to skim past. sing-box has an upstream project at sagernet.org, and this collection is written against a fork maintained under the reF1nd organisation. A tutorial that applies to that fork may not apply to upstream sing-box, and configuration keys can differ.

The README then gives a three-column mapping from core to documentation, which is the fastest way to route yourself to the right reference:

https://wiki.metacubex.one
https://sing-boxr.dustinwin.cc.cd/zh
https://sing-box.sagernet.org/zh

Read that as an admission of fragmentation. Three documents for what a newcomer experiences as one tool, because the community has not converged on a single core. The fourth entry, the proxy-tools repository, is where core updates happen.

The collection is also explicitly practical in orientation, leaning towards hands-on configuration rather than theory. Its scope is stated as installation, configuration, custom rules and DNS routing, so if you are looking for protocol explanation you are in the wrong place.

geodata versus ruleset: the tradeoff the README states plainly

The README clearly explains the two rule matching schemes.

The geodata scheme suits devices such as routers, where many devices are connected and the local process cannot be determined. Its configuration files are simple and it is friendly to beginners. In mihomo it uses `GEOSITE` and `GEOIP` rules paired with GeoSite.dat and GeoIP.dat, or Country.mmdb.

The ruleset scheme suits users with stricter requirements on routing rules. Its configuration is more complex to write, but it can be configured on demand and is flexible.

The per-core mapping is given the same way. mihomo uses the ruleset scheme with `RULE-SET` rules paired with.list and.mrs files. sing-box uses the `rule_set` rule paired with.json and.srs files.

Three observations follow. First, the file formats differ per core, so a rule set is not portable between mihomo and sing-box without conversion. Second, the scheme choice is a consequence of the deployment, not a preference: the router case has no process information, which is exactly why geodata exists. Third, the beginner-friendly path and the strict path are genuinely different, and a configuration built for one is not a simplification of the other.

All of these files live in a separate ruleset_geodata repository that the README recommends over generic rule sets, so the collection and the rule data are versioned separately.

Download source choice is a twelve-hour staleness decision

The README has a section on download sources, explaining why the source choice matters in networks where these configurations are used.

The default is the jsDelivr source, with the URL form:

https://cdn.jsdelivr.net/gh/[username]/[reponame]@[branchname]/[filename]

and the collection states plainly that file updates in this source have a twelve hour delay. If jsDelivr is unreachable, the address can be changed to:

https://testingcf.jsdelivr.net/gh/[username]/[reponame]@[branchname]/[filename]

The recommended route is the GitHub source, in three URL forms, releases first:

https://github.com/[username]/[reponame]/releases/download/[tagname]/[filename]
https://raw.githubusercontent.com/[username]/[reponame]/[tagname]/[filename]
https://raw.githubusercontent.com/[username]/[reponame]/[branchname]/[filename]

And if GitHub is unreachable, the fix is a prefix rather than a different host:

https://ghfast.top/https://github.com/[username]/[reponame]/releases/download/[tagname]/[filename]

with the same prefix applied to the two raw.githubusercontent.com forms.

The delay figure is the operational takeaway. A twelve hour lag on your geodata files means routing decisions can be made against stale data for half a day after a change lands upstream, and if you rely on the recommended custom rule set files you control, that delay applies to your own updates too. Using the GitHub source removes it.

Note also the distinction between a tag and a branch in these URL forms. Pointing at a branch gives you moving targets; pointing at a tag gives you a fixed artefact.

Five categories, and what the shared-configuration section really is

The collection is split into five categories, and the fifth one shapes how most people will actually use it.

The categories are pinned items, direct-link configurations, tool configurations, DNS configurations and shared configurations. The README states that people who want a ready-made file can go straight to the shared configurations section for reference, and asks them to prefer the author's customised rule set files where possible.

That is a tension worth naming. A tutorial collection and a shared-configuration repository serve different needs, and the second one is where the risk concentrates: a shared configuration encodes someone's routing policy, their DNS resolvers, their rule ordering and possibly their subscription provider. Copying one and only changing the subscription line means adopting all of that without reviewing it.

The DNS configuration category is the one with the most independent value. DNS routing decides which of your lookups go to your resolver and which are resolved through the proxy, and getting it wrong produces the specific failure mode these tools are notorious for: a domain resolving to a local address or an address your proxy cannot reach, while everything else works. A category dedicated to it is a reasonable signal about where the difficulty actually lies.

The tool configurations category presumably covers the surrounding software, and the repository topics corroborate a broad scope beyond the two cores: adguard-home, clash, clash-meta, shellcrash and singbox all appear alongside mihomo and proxy.

Maintenance, licence, and what the repository does not tell you

The licence is MIT, with a LICENSE file at the root, which is worth noting for a site whose subject matter is configuration templates: the text is permissively licensed, but the configurations themselves point at third-party services whose terms are their own.

The README includes a commercial recommendation section linking to a paid service. That is a sponsorship arrangement rather than technical guidance, and it is worth separating from the documentation when you evaluate anything here.

On maintenance, the repository is not archived and the last push was on 2026-09-25. There are no GitHub releases, which is consistent with a site that deploys from the default branch.

What the repository does not provide is the main limitation. There is no version pinning for the core builds the tutorials target, no dated statement of which core version a given configuration was tested against, and no automated validation that a configuration in the collection still loads on the current core. Configuration tutorials for proxy software age badly, because a renamed key or a changed default produces a config that loads and behaves differently rather than one that fails loudly.

There is also no changelog in the README describing what changed between tutorial revisions. For a collection whose core upstream is forked and moving, that means the safest use is as a map of which decisions to make, not as a source to paste from.

Editorial conclusion

Adopt this collection as a reference if you configure mihomo or sing-box and want to understand the geodata versus ruleset tradeoff before copying a configuration, particularly since the site maps each core to its own wiki and ships custom rule set files you can point at. Do not treat a shared configuration from the collection as a starting point you can leave unexamined, because rule behaviour depends on the geodata files or rule sets you actually resolve. Verify first which core build you have, since the collection is written against the mihomo core and a reF1nd fork of sing-box, and prefer the GitHub download source over jsDelivr given the stated twelve hour update delay.

Frequently asked questions

Official sources

1. DustinWin/dustinwin.github.io on GitHub
2. Issues
3. License: MIT
4. Project website
5. README