# v2fly/domain-list-community: generating geosite.dat routing rules from plain text domain lists

> The repository is a community-maintained set of plain text domain lists plus a Go generator that compiles them into dlc.dat, the geosite file Project V reads at routing time. It is a data project, not a proxy, and its value depends entirely on how well its list conventions fit your routing config.

**v2fly/domain-list-community** — Community managed domain list. Generate geosite.dat for V2Ray. Domain list community This project manages a list of domains, to be used as geosites for routing purpose in Project V.

- Repository: https://github.com/v2fly/domain-list-community
- Website: https://www.v2fly.org
- Stars: 9,559 · Forks: 1,435
- Language: Go
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/v2fly-domain-list-community

## What domain-list-community actually ships

The repository holds two things that are easy to confuse. The first is a directory of plain text files under data/, each one a named list of domains. The second is a Go program at the repository root that reads those files and emits a binary geosite file, dlc.dat, which Project V loads for routing. The project describes itself as community managed and explicitly states it is not opinionated: it does not endorse, claim or imply that any domain should be blocked or proxied. That sentence is the whole design brief. The lists are raw material; the decision about what to do with a match belongs in your config.

This matters for adoption. If you are looking for a curated blocklist with a point of view, this is the wrong repository. If you want a maintained set of domain groupings that you route yourself, it fits. The unit of reuse is the list name: every file in data/ becomes addressable as geosite:filename, so a file called netflix produces the tag geosite:netflix. The README recommends naming files after a deterministic group, such as the owner of the domains, and discourages names with unclear scope.

Releases are cut frequently. The three most recent are dated 2026-08-27, and the last push to the default branch was on 2026-08-27. The repository is not archived.

## The rule syntax and how affiliations differ from attributes

Each data file is line-oriented. A line starting with # is a comment and is ignored in production. A domain line is either domain:example.com for a subdomain rule, full:analytics.google.com for a full-domain rule, keyword: followed by a substring, or regexp: followed by a Go regular expression. The README discourages adding new keyword and regexp rules, on the grounds that they are easy to misuse and that proxy software cannot match them efficiently. That is a rare piece of honest guidance in a data repository, and it should shape how you contribute.

Two suffixes on a rule look similar and behave nothing alike. An attribute begins with @ and survives into the final lists and into dlc.dat. An affiliation begins with & and does not survive; it copies the rule into another named list as a data-management convenience. The README is explicit that attributes remain available while affiliations are stripped. Getting these backwards will produce a list that looks correct in the source file and wrong at runtime.

Inclusion works the same way. include:list2 inside data/list1 pulls all rules from list2 into list1. With attributes, include:list2 @attr1 @-attr2 means take only rules that carry @attr1 and do not carry @attr2. The README notes this is filtering, not flagging, which is the kind of distinction that only becomes obvious after you have written a rule that silently includes the wrong set.

## Installing the generator and building dlc.dat from source

The README gives the manual build path directly. You need Go and git. Clone the repository, move into it, download the module dependencies, then run the generator from the repository root. With no datapath option, the program reads the data directory of the current working directory.

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

To point the generator at your own directory of list files instead of the bundled data path, the README shows the datapath flag. This is the path you want if you maintain private lists alongside the community ones.

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

Running go run ./ --help prints the remaining options; the README points there rather than enumerating them. The go.mod file pins the module to github.com/v2fly/v2ray-core/v5 at v5.52.0 and google.golang.org/protobuf at v1.36.12, so the build pulls the routing rule definitions from the core repository rather than redefining them. The generator's own logic lives in main.go, which the README names as the place to read for detail.

## Wiring a generated list into a Project V routing block

The README's usage example is a routing object with domainStrategy set to IPIfNonMatch and a rules array. Each rule has a type of field, an outboundTag, and a domain array whose entries are either literal domain: prefixes or geosite: list references. Rejecting ads and adult categories, sending Apple and private ranges direct, and pushing an anticensorship list to a proxy happen in the same array.

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

The README warns that the rule types defined in these data files are not fully compatible with rules a user writes directly in a V2Ray config, and that copying between the two is a mistake. So the geosite: reference is the correct integration point, not a paste of the underlying domain lines. If you generate your own dat file, point the core at it; do not transcribe its contents into the routing block.

## Two tags that no longer exist, and what to use instead

The README carries a notice that rules with the @!cn attribute have been cast out of the cn lists, and that geosite:geolocation-cn@!cn is no longer available. It links three issues and pull requests as the record of that change. If your config still references that tag, it will not resolve, and the failure will look like a routing miss rather than a config error.

The second notice concerns the dedicated ad lists. Lists named like geosite:xxx-ads have been removed; the replacement is the attribute form geosite:xxx@ads. The category-ads and category-ads-xx lists are unaffected. Anyone upgrading an older config should audit for both patterns before switching cores, because the two removals fail in the same quiet way. Neither notice is a bug report; both are deliberate consolidations of the tag namespace, and the README asks users to report problems or questions if something is unclear.

## Where the project is the wrong tool

The data path is the boundary. A geosite list answers a single question: does this domain belong to this named group. It cannot express time-of-day policy, per-user rules, bandwidth shaping, or anything that depends on who is asking. If your requirement is that one department reaches a domain and another does not, the list format has no place to put that, and the routing config is where it has to live.

The second limitation is the one the README states about itself. Because the project is not opinionated, a list existing does not mean its domains should be blocked or proxied. A contributor adding a company's domains to a list is not making a policy claim, and a reader who treats the presence of a domain in a list as a verdict has misread the artifact. The third is the discouraged rule types: keyword and regexp entries are supported but the README advises against adding them, so a workflow that depends on regular-expression matching is pushing against the project's own preference. The fourth is that this repository produces data for Project V. It is not a proxy, a client, or a subscription service, and it will not do anything on its own.

## Alternatives and what changes if you leave

The realistic alternative is to stop using a shared list and write domain rules directly into your Project V config, using the domain: and full: prefixes the routing block already accepts. The difference is ownership of maintenance. A local list gives you exact control and no upstream surprises, at the cost of tracking domain changes yourself: the community repository is regenerated on every push, and its last push was on 2026-08-27, so someone else is absorbing that churn. The trade is churn absorption against change notification. With a local list you never get a tag removed without warning, because there is no upstream to remove it.

A second path is to fork the data directory and run the generator against your fork with --datapath. You keep the file format and the build tooling from go.mod while controlling the contents. The cost is that you now own merges, and the notices about @!cn and the removed ad lists will arrive as conflicts rather than as a release you can simply consume. A third option is to consume the published dlc.dat from the release assets and never build anything, which removes the Go toolchain from your environment but also removes your ability to add a private list.

## Licence, upgrade cost and what to check before adopting

The repository is MIT licensed, which is permissive and places few obligations on reuse of the generator and the list files. The README does not document rollback, versioning of list contents, or a deprecation window for tag removals, so the practical upgrade cost is not the licence but the tag namespace. Two removals are already documented, and each one is a config edit you have to find by reading the notices rather than by watching a build fail. Pin the release you consume, keep the sha256sum files that ship alongside dlc.dat and dlc.dat_plain.yml, and diff the plain YAML between two releases when you upgrade: that is where a tag change becomes visible before it reaches your routing block. The README does not describe a compatibility guarantee across releases, so treat the tag set as something to re-verify on each upgrade rather than as a stable interface.

## Conclusion

Adopt it if you run Project V or a compatible core and want routing rules maintained as reviewable text files instead of hand-written domain entries in a config. Skip it if you need per-user policy, if you cannot accept that the project states it does not endorse blocking or proxying any domain, or if you need the removed geosite:geolocation-cn@!cn and geosite:xxx-ads tags. Verify first that the list names you plan to reference exist as files under data/, and that your core accepts the geosite:filename form for each one.

## FAQ

### Why would someone buy a domain?

This repository does not cover domain registration or purchase. It manages lists of existing domains under data/ so they can be compiled into geosite routing rules for Project V, and the README states the project is not opinionated about whether any domain should be blocked or proxied.

### What are the 7 types of domains?

The README does not describe seven domain categories. It defines four rule types for list files: domain: for a subdomain rule, full: for a full domain rule, keyword: for a substring match, and regexp: for a Go regular expression, with the README discouraging new keyword and regexp entries.

### What are the 5 top-level domains?

The README does not list five top-level domains. The closest concept here is the list name: each file in the data directory becomes a geosite list addressable as geosite:filename, and the README recommends naming files after a deterministic group such as the domain owner.

### What is an example of a domain?

The README's structure example uses google.com for a domain: line, analytics.google.com for a full: line, and google for a keyword: line. In a routing config, entries appear either as literal prefixes like domain:icloud.com or as geosite: list references.

## Sources

- [Official documentation](https://www.v2fly.org)
- [Official README](https://github.com/v2fly/domain-list-community#readme)
- [Project repository](https://github.com/v2fly/domain-list-community)
- [Release notes](https://github.com/v2fly/domain-list-community/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/v2fly-domain-list-community