v2ray/domain-list-community: geosite domain lists and how the dlc.dat build works

What v2ray/domain-list-community solves, and for whom

Project V routing rules are written by hand. A rule that sends a set of company domains to one outbound means typing every domain into the config, and keeping that list current as domains are added. This repository exists so that work is shared. It manages a list of domains, in the words of the README, "to be used as geosites for routing purpose in Project V".

The audience is narrow and specific. It is for people who already run a Project V client or server and want to route by domain group rather than by hand-written domain entries. It is also for contributors who want to add or correct entries in those groups. The README is explicit that the project itself takes no position: it "does NOT endorse, claim or imply that a domain should be blocked or proxied". A list named category-ads-all is a bag of domains with a label, not a recommendation. That distinction matters when you read a pull request or a section name.

Note the announcement at the top of the README. Due to a lack of members capable of code review, the project moved to v2fly/domain-list-community, where more contributors can get manager access after a few successful PRs. This repository is now a release channel for dlc.dat only; issues and pull requests are handled at the new one.

The data directory and the five line types

Everything lives under data. Each file in that directory is one sub-list, named by the file name, and becomes one section in the generated output. The content format is line-oriented, and the README lists five forms.

# comments
include:another-file
domain:google.com @attr1 @attr2
keyword:google
regex:www\.google\.com
full:www.google.com

A comment starts with # and may begin anywhere in the file; the rest of that line is ignored. include: pulls in the contents of another file in the same directory, which is how overlapping groups are assembled without copying lines. domain: matches subdomains and may be written without the prefix, so a bare google.com is equivalent to domain:google.com. keyword: matches a plain string. regex: takes a regular expression that must be valid under Go's standard library. full: matches a complete domain only.

The last piece is attributes. Any of domain, keyword, regex and full may carry one or more attributes, each written as @name. The README's own example is a google file whose ad-serving domains are marked @ads, which can then be selected as geosite:google@ads in a routing rule. That is the mechanism for sub-groups: one file, several selectable views of it.

How a section becomes a routing rule

The build walks the data directory and emits an external geosite file for Project V. The README describes the transformation step by step: strip comments, replace include: lines with the actual content of the referenced file, drop empty lines, then map each remaining line to a routing rule type. domain: becomes a sub-domain rule, keyword: a plain domain rule, regex: a regex domain rule, and full: a full domain rule. The README links each of those to the corresponding message in v2ray-core's app/router/config.proto.

Two consequences follow from that pipeline. First, include: is resolved at build time, so the generated file is flat; a section that includes another does not depend on the other at runtime. Second, the four match types are not interchangeable in cost or precision. A regex rule is evaluated as a regular expression, a keyword rule is a substring match, and a full rule matches exactly one name. If you are debugging why a domain was routed the wrong way, the line type in the source file tells you which kind of comparison the router performed.

The README also states the rule for choosing file names. Any valid file name works in theory, but the guidance is to prefer names for a determinate group of domains, usually the owner, with google and netflix given as examples. Names with unclear scope, such as evil or local, are described as generally unrecommended.

Installing the tool and generating dlc.dat yourself

The README gives a manual build path. It requires golang and git to be installed first, then the project code is fetched with go get. The command as printed includes the --insecure flag.

go get -u -v --insecure github.com/v2ray/domain-list-community

Running the built binary with no arguments uses the data directory of the repository inside $GOPATH. Passing --datapath points the build at your own directory of files instead, which is the path to take if you are testing edits before opening a pull request.

$(go env GOPATH)/bin/domain-list-community
$(go env GOPATH)/bin/domain-list-community --datapath=/path/to/your/custom/data/directory

If you only want the published output, the README lists two download links: dlc.dat at the release branch of this repository, and dlc.dat.sha256sum alongside it. The checksum file is there so you can verify the download before loading it. The README does not describe a rollback procedure for a dlc.dat that breaks routing, so keep the previous file if you replace it in place.

On the consuming side, the README's usage example is a routing block. Each file in data is referenced as geosite:filename, and attributes are appended after an @. A rule can then name several sections at once.

"routing": {
  "domainStrategy": "IPIfNonMatch",
  "rules": [
    {
      "type": "field",
      "outboundTag": "Reject",
      "domain": [
        "geosite:category-ads-all",
        "geosite:category-porn"
      ]
    }
  ]
}

The example continues with a Direct rule mixing literal domain: entries such as domain:icloud.com and domain:icloud-content.com with geosite:cn, and a Proxy rule naming geosite:category-anticensorship and geosite:category-media. The names you can use are exactly the file names under data, plus attributes where the file defines them.

Where this project is the wrong tool

The most concrete limitation is governance, and it is stated by the project itself. The README says the move happened because of a lack of members capable of code review. If your reason for being here is to contribute a domain or dispute an entry, the workflow you want is not in this repository: the README says issues and pull requests are handled at v2fly/domain-list-community, and that this repo is only used to release dlc.dat. A pull request opened here is aimed at the wrong place.

There is a second, quieter limitation in the data model. include: pulls whole files together, and attributes carve out sub-groups, but a domain line carries no explanation of why it is in a file. The comment syntax lets contributors write that down, and the build strips comments out. So the generated artifact tells you what matches and never why. If your routing decision needs an auditable reason per domain, this format does not carry one into the file the router reads.

Finally, the lists are not a blocklist product. The project declines to say a domain should be blocked or proxied, so a section name like category-ads-all is a grouping someone chose, not a judgement the maintainers stand behind. Anyone looking for a curated, reviewed threat list is looking at the wrong kind of artifact. This is routing input, and the accuracy of any section is only as good as the pull requests that touched it.

What to use instead, and how the approaches differ

The direct alternative is v2fly/domain-list-community, the repository this project says it moved to. The difference is not in the file format or in the generated output, which the README describes as the same dlc.dat release; it is in where the work happens. The README states that the move allows more contributors to have manager access after a few successful PRs, and that issues and PRs are handled there. So the two repositories differ in review capacity and in who can merge, not in what a domain: line means.

A different kind of alternative is writing the domains directly into your routing config. That is the approach the README's own example mixes in, with literal entries like domain:icloud.com sitting next to geosite:cn. The trade-off is control against maintenance. A hand-written list is exactly what you decided, and it never changes under you; a geosite section updates on the project's release cadence, and you inherit whatever was merged. For a handful of stable domains, the hand-written list wins on predictability. For a group like a large content provider's domains, which shift often, the shared list is the only version that stays current without your attention.

A third option is generating your own dat from your own data directory. The --datapath flag exists for exactly this, and it gives you the format's include and attribute machinery without depending on anyone else's merge decisions. The cost is that you now own the domain entries.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-08-28. The three most recent releases listed are 20260827152101, 20260826065759 and 20260825144803, dated 2026-08-28, 2026-08-27 and 2026-08-26 respectively. The release identifiers look like timestamps, which is consistent with a build that is published on each change rather than on a version plan. There is no semantic version to pin to, so "upgrade" here means replacing dlc.dat with a newer one, and the only handle on which build you have is the release name and the checksum file.

That cadence has a practical cost. A domain entry merged into a section you use will reach you at the next release, and there is no documented way to subscribe to changes in one section only. If a section matters to your routing, the workable approach is to keep your own copy of the file and diff it against the published one before replacing anything.

The project is MIT licensed, and the LICENSE file sits at the top level of the repository. MIT is permissive, so redistributing the data and the generated dlc.dat inside your own product is the kind of use the licence text addresses. What MIT does not do is give you any warranty about the contents of the lists, and the README's statement that the project does not endorse blocking or proxying any domain is worth reading next to the licence rather than instead of it. For advice on your own redistribution, ask a lawyer; the licence text is the source, not this paragraph.

Editorial conclusion

Adopt this repository only as a download source for dlc.dat or as a reference for the data file syntax. If you intend to open an issue, send a pull request, or apply for manager access after a few successful PRs, go to v2fly/domain-list-community instead, because the README states that this repository handles only dlc.dat releases. Before wiring geosite: names into a config, verify the specific section and attribute you depend on, since the project states it is not opinionated about what should be blocked or proxied and the lists change with each release.

Frequently asked questions

Official sources

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