v2fly domain-list-community: @ tags ship, & affiliations vanish at build time

dlc.dat ships in four artifacts, and the checksum you need depends on which one you load

Every release publishes four files, and they exist as two pairs. dlc.dat is the binary file the proxy actually loads. dlc.dat_plain.yml is the same content in readable form. Then each of those has a companion checksum, dlc.dat.sha256sum and dlc.dat_plain.yml.sha256sum. The pairing matters in practice: a client that loads the binary artifact and verifies against the wrong checksum file fails verification. The releases themselves are named with build timestamps rather than versions, with recent tags including 20261103081536 on 2026-11-03 and both 20261102203016 and 20261102130044 on 2026-11-02, so nothing in the tag name tells you what changed between two downloads.

go run ./ reads the data directory you happen to be standing in

Rebuilding the artifact locally needs golang and git, and the documented sequence is four commands:

git clone https://github.com/v2fly/domain-list-community.git
cd domain-list-community
go mod download
go run ./

The default invocation takes no path argument, which means it uses the domain lists in the data directory of the current working directory. Pointing it somewhere else is explicit:

go run ./ --datapath=/path/to/your/custom/data/directory

So the same command means different things depending on where you are standing, and go run ./ --help is the reference for the remaining options. Anyone who wants custom .dat files is pointed at discussion 3370. The build itself is a Go module pinned at go 1.26.10, depending on v2ray-core/v5 at v5.56.0 and google.golang.org/protobuf at v1.36.12, so a machine on an older Go toolchain cannot build the current tree at all.

@ attributes reach the output while & affiliations and filtered includes do not

The data files carry two notations that look similar and behave oppositely. An attribute begins with @ and stays with the rule: attributes remain available in the final lists and in dlc.dat. An affiliation begins with & and pulls the rule into another target list as a data management shortcut, and it will not remain in the final lists or in dlc.dat. Inclusions behave the same way when filtered: include:list2 @attr1 @-attr2 adds only the rules from list2 that carry @attr1 and lack @attr2, and that filtering is not flagging, so nothing about it survives. The practical consequence is that a compiled list tells you which attributes a domain has but not which affiliation or which filtered include brought it in. When a domain shows up in a list you did not expect, the compiled file cannot answer why; you have to go back to the source files.

keyword and regexp rules are documented as slow, so existing ones are the ones to distrust

Adding new regexp and keyword rules is discouraged, for two stated reasons: they are easy to use incorrectly, and proxy software cannot efficiently match these types of rules. That guidance is about additions, so the pressure lands on the lines already in the tree. A keyword is a substring of a valid domain name, so keyword:google is not a statement about google.com, it is a statement about every hostname containing that substring, and a regexp has to be valid per Golang's standard. Both are compiled into real router rules: each keyword line becomes a plain domain routing rule and each regexp line becomes a regex domain routing rule.

Four line types compile into four router rule types, and the plain export is a build step

The whole data directory is built into an external geosite file for Project V, with each file becoming a section of the generated file. The build runs five general steps: read the files in the data path while ignoring all comments and empty lines, parse and resolve the source data by turning affiliations and inclusions into actual domain rules in the proper lists, deduplicate and sort rules in every list, export the desired plain text lists, and generate dlc.dat. That last step is where each prefix is converted, with domain: becoming a sub-domain routing rule, full: becoming a full domain routing rule, keyword: becoming a plain domain routing rule, and regexp: becoming a regex domain routing rule.

The list takes no position on blocking, and it has already deleted two tag families

The project states it is not opinionated, meaning it does not endorse, claim, or imply that a domain should be blocked or proxied, and that the data exists to generate routing rules on demand. That neutrality is why membership is not a verdict you can quote. Two identifier families have already been removed. Rules with the @!cn attribute were cast out of the cn lists, so geosite:geolocation-cn@!cn is no longer available; the notices point at issue 390 and pull requests 3119 and 3198. Dedicated non-category ad lists such as geosite:xxx-ads were removed as well, replaced by geosite:xxx@ads, while geosite:category-ads[-xx] is unaffected. A configuration file copied from an older guide can therefore reference a tag that no longer exists, and nothing in the dat file itself warns you which of its names are current.

A file name becomes a geosite tag, so renaming a data file breaks client configs

Each file in the data directory is a sub-list of domains named by the file name, and each of those names is what clients reference as geosite:filename. The guidance on naming is loose and then opinionated: theoretically any string works as long as it is a valid file name, but in practice names are preferred for a determinic group of domains, usually the owner of those domains, with google and netflix given as the examples. Names with unclear scope are discouraged, with evil named as one. The consequence is a coupling between the file system and the configuration of every client using the list. Renaming data/google to something more specific changes the tag, and every routing rule on every machine that referenced geosite:google stops resolving without any compile error on the client side.

A small Go repository with a main.go, a test file, and a data directory

The tree is small and mostly predictable at the top level: .github/, .gitignore, LICENSE, README.md, cmd/, data/, go.mod, go.sum, internal/, main.go, and main_test.go. The generator entry point is main.go, which the documentation points readers to for details, and the tests sit in main_test.go. Under data/ sit the lists themselves. Three indirect dependencies are declared, adrg/xdg, golang/protobuf, and golang/x/sys, alongside the two direct requirements. The last push to master is 2026-11-02, and the release cadence is close to continuous, which suits a dataset whose contents change for reasons outside the project, but it also means the gap between what you audited and what is live can be measured in hours rather than months.

Editorial conclusion

Reach for domain-list-community when your proxy already consumes geosite files and you want routing groups that stay inspectable as text and regenerable from source, since the whole artifact can be rebuilt with go run ./ on a machine that has Go 1.26.10. Stay away if you need a pinned dataset with a stable version interface: releases are named with timestamps such as 20261103081536, and the recent history holds three within the last two days. And read the notice section before reusing a tag from an older config, because geosite:geolocation-cn@!cn is gone and the dedicated xxx-ads lists are gone too.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes