v2fly/domain-list-community: a community domain list with a neutral stance and strict syntax

What this project actually is

The repository is a collection of plain text files, one per category, each containing domain rules. The build tool compiles them into dlc.dat, a binary file that V2Ray reads as geosite data. The README is explicit that the project is not opinionated: it does not endorse, claim, or imply that a domain should be blocked or proxied. It only provides a structured list of domains. This is a deliberate design choice, and it matters. Many similar projects ship with a political or ethical agenda baked in. This one does not. The intended user is someone who wants routing rules on demand, not a ready-made policy. If you want to block ads or proxy Netflix, you combine this list with your own outbound rules in the V2Ray config.

The data format and its strict rules

Each file in the data directory is a sub-list. The syntax is simple but has sharp edges. A line can be a comment, an include, or a rule. Comments start with # anywhere. A domain rule can be domain:, full:, keyword:, or regexp:. The prefix domain: can be omitted, but the others cannot. Attributes follow a rule with @name, and affiliations follow with &name. Inclusions are special: include:another-file pulls in all rules from that file, but you can add attributes to filter which rules are included. The README warns that adding attributes after include is filtering, not flagging. That is a subtle distinction. If you write include:cn @ads, you get only the cn rules that have the ads attribute. If you write include:cn, you get everything. The filtering is done at build time, not at runtime. This is a data management feature, not a routing feature.

How the build process works

The build is a Go program. You run go run ./ from the project root, and it reads every file in the data directory. The steps are documented: read files, ignore comments and empty lines, parse and resolve inclusions and affiliations, deduplicate and sort rules, export plain text lists, then generate dlc.dat. The conversion to dlc.dat maps each rule type to a specific protobuf message in the routercommon package. domain: becomes a sub-domain routing rule, full: becomes a full domain rule, keyword: becomes a plain domain rule, and regexp: becomes a regex domain rule. This is important because the matching semantics differ. A domain: rule matches the domain and all subdomains. A full: rule matches exactly. A keyword: rule matches any domain containing the substring. A regexp: rule matches per Go's regex syntax. The build process is deterministic, so the output is reproducible. You can also specify a custom data path with --datapath, which is useful if you maintain your own fork.

Getting it running and updating

The README gives a clear path. You need Go and git installed. Clone the repository, cd into it, run go mod download, then go run ./. That generates dlc.dat in the current directory. You can also run go run ./ --datapath=/path/to/your/custom/data/directory to use your own data. The release page provides prebuilt downloads: dlc.dat, dlc.dat_plain.yml, and sha256sum files. The plain YAML is a human readable export of the same data. The releases are frequent, with timestamps in the tag names, so you can see exactly when a version was cut. For a routing list, freshness matters because domains change ownership and new domains appear. The project seems to update continuously, but you need to check the release page yourself. The README does not mention any automated update mechanism. You have to fetch the new release manually or write your own script.

Limitations and failure modes

The most obvious limitation is the recent breaking changes. The README lists two. First, rules with the @!cn attribute have been cast out from cn lists. So geosite:geolocation-cn@!cn is no longer available. Second, dedicated non-category ad lists like geosite:xxx-ads have been removed. You must use geosite:xxx@ads instead. If you have an old config that references these, it will break. The README points to issue and pull request numbers, but the exact migration path is not spelled out. Another limitation is that the project does not guarantee coverage. It is community managed, so the data quality depends on contributors. There is no mention of automated verification that domains are still valid. Also, the README explicitly discourages adding new regexp and keyword rules because they are easy to use incorrectly and proxy software cannot efficiently match them. That is a warning to contributors, but it also means the list may contain such rules, and they can cause performance problems in V2Ray. If you need a list with strict performance guarantees, you might want to filter these out.

Alternatives and how they differ

The main alternative is to maintain your own domain list in your V2Ray config. You can write domain: and full: rules directly in the routing section. That gives you full control and no dependency on a third-party project. The difference is effort. The community list gives you thousands of domains grouped by category, so you do not have to research each domain. Another alternative is a project like Loyalsoldier/v2ray-rules-dat, which provides a similar geosite.dat but with a more opinionated approach, often including categories like geolocation-!cn and ads. The key difference is that Loyalsoldier's list is maintained with a specific use case in mind, usually for proxy clients, while this project is explicitly neutral. If you want a list that says 'these domains are likely blocked in China', you need to combine this list with your own logic. If you want a list that already makes that judgement, you need a different project.

Maintenance, licensing, and what to verify

The project is under the MIT license, which means you can use, modify, and redistribute it freely, as long as you include the original copyright notice. That is a permissive license, so there are few legal constraints, but I am not giving legal advice. The maintenance is community driven. The repository is active, with recent pushes and releases, but there is no guarantee of long-term support. If the maintainers step away, the list will go stale. The build process is simple, so you can fork the project and run your own builds. The README mentions a discussion for custom .dat files, but it does not provide a guide. Before adopting, verify that the categories you need exist. The list is not exhaustive. Also, check the release date and the sha256sum to ensure integrity. The project does not provide a versioning scheme beyond timestamps, so you cannot rely on semantic versioning for compatibility. A breaking change like the @!cn removal can happen at any time.

Editorial conclusion

Adopt this project if you need a ready-made, community maintained geosite dataset for V2Ray routing and you agree with its non-opinionated stance: it does not say what to block or proxy, only what domains exist. Do not adopt it if you need a curated, policy-driven list like a blocklist or a proxy list, or if you require frequent updates beyond the release cadence. Before using, verify the specific categories you rely on, because the recent removal of @!cn and dedicated ads lists means some old rule names no longer work. Also check the release date and the sha256sum to ensure you have the latest data. The project is MIT licensed, so you can fork and modify it, but you must maintain your own fork if you want custom categories.

Official sources

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