AdguardTeam / HostlistsRegistry
Known hosts blocklists that are made available to the users of AdGuard products
AI Architecture Analysis
This repository is indexed by RepoMind. By analyzing AdguardTeam/HostlistsRegistry in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.
Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.
Repository Overview (README excerpt)
Crawler viewAdGuard Host Lists Registry • What Blocklists Can Be Added Here • Where Blocklists Are Published • Filters Metadata • Services Metadata • Safe Search Filters • How to Build • How to Compress • Localizations This repository contains the known hosts blocklists that are made available to the users of AdGuard products (AdGuard DNS, AdGuard Home, etc). Some of these blocklists are automatically converted to the rules format that AdGuard product understand better. Where Blocklists Are Published • contains all the blocklists added to the repo. is the location of the re-hosted blocklist. • is the meta-data of "Web Services". This is a part of the parental control functionality of AdGuard Home and AdGuard DNS. What Blocklists Can Be Added Here • The blocklist should be oriented towards DNS-level content blockers. There is a different repo for browser content blockers. • We prefer (mostly) original lists to compilations. • We prefer blocklists that are specifically made for AdGuard Home and use adblock-style syntax. Lists that use can also be added if there is no alternative. • The blocklist should have a clear purpose. Examples: • good: "blocks TV ads". • bad: "John Doe's personal blocklist" • The blocklist should have a place for receiving user complaints and holding discussions, such as a repository on github.com, or a public website/forum. • The blocklist should be relatively popular, meaning: • if there is a repository on GitHub, the number of stars should be at least 50. • if there is no repository on GitHub, the number of reported issues and discussions should be at least 10 per month. • the blocklist should be actively supported for at least 6 months. • The blocklist should be regularly updated with at least 10 updates per month. • Previously added blocklists that haven't received any support for a year will be removed. We reserve the right to remove the blocklist earlier, depending on circumstances. • If the blocklist contains too many problematic rules, it will not be added. A rule is considered problematic if it causes false positives or otherwise displays unitended behavior. Decisions about blocklists with problematic rules are arbitrary and there may be exceptions. • If the blocklist intentionally blocks or restricts access to a service for no reason other than being a reflection of the filter author's opinion, the blocklist will not get added, or will get removed if already added. • If the blocklist is popular in a specific region and there are no alternatives to it, then it can be added as is even if it does not satisfy requirements above. How to add a filter list To add a new filter, you need to: • Go to the filters folder. • Go to the category to which the new filter will belong. • Create a new folder with the name . • Create two files in this folder: and . The contents of these files are described below. • In the file add an object with the name and description of the filter according to the example added above. The files and must not be edited manually. Filters Metadata • Filter metadata. Includes name, description, etc. • — unique human-readable filter identifier (string) • - unique internal filter identifier (integer) • — filter name; can be localized • — filter description • — time when this filter was added to the registry; milliseconds since January 1, 1970; you can exec in the browser console to get the current time • — filter website/homepage • — optional, boolean, filter is deprecated and should not be used by the products, but filter is still available, i.e. not removed • — filter's default expiration period • — this number is used when AdGuard sorts available filters (GUI) • - either or . Only lists are available in AdGuard DNS. • - if set to , the blocklist won't be updated. • — a list of tags • - a flag that allows using rules for this filter. If the filter is not trusted, rules will be removed from the compiled filter. Metadata example • Filter version metadata, automatically filled and overwritten on each build. • Resulting compiled filter. • Configuration defines your filter list sources, and the transformations that are applied to the sources. See Hostlist compiler configuration for details Tags Every filter can be marked by a number of tags. Every tag metadata listed in . Example Possible tags: • — for language-specific filters; one or multiple lang-tags can be used. For instance, AdGuard Russian filter is marked with the tag. • — determines filters purposes; multiple purpose-tags can be used for one filter list. • — for low-risk filter lists which are recommended to use in their category. The category is determined by the pair of the and tags. • — for abandoned filter lists; filter's metadata with this tag will be excluded from and . How to add a blockable service To add a new blocked service, a new file must be added to the directory, the contents of the directory and the resulting file are described in the next section. Services Metadata The file combines information about services received from separate files located in the directory. The file is generated by a script, so there is no need to modify it manually. • Source files: Each file contains information about a specific service. The file name must match its . • File saving: files are stored in the services directory. • Updating information: In cases when it is necessary to change the configuration of a service, it is necessary to update the corresponding file in the services directory. • Adding a new service: to add a new service to it is necessary to add file to the services directory, after the script is run the file will be updated. **WARNING!** • Deletion of files is strictly forbidden. If a service file is deleted, the script will restore it from a previous version of the file. • It is also forbidden to change service inside the file. Service metadata includes , , , , : • — unique human-readable service identifier (string, as ) • — service name (string) • — list of domain…