# 10007_auto: auto-updated hosts and filter subscriptions for ad blocking

> 10007_auto is a small shell-scripted repository that regenerates a set of ad blocking hosts and filter lists and publishes them as subscription URLs. It suits someone who wants a single URL to paste into Adguard, Adaway or Adclose, and it is of no use if you want to control the rules yourself.

**lingeringsound/10007_auto** — ZH: 自动更新去广告的hosts ，En: Automatically update ad hosts

- Repository: https://github.com/lingeringsound/10007_auto
- Website: https://lingeringsound.github.io/10007_auto/
- Stars: 621 · Forks: 18
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lingeringsound-10007-auto

## The output of this repository is a URL, not a program

10007_auto is described in the repository as an automatic updater for ad hosts, and the primary language recorded for it is Shell. What you actually consume is a set of generated text files hosted on GitHub, and what you use is a subscription URL that a blocking client fetches on a schedule.

The distinction is worth making early, because the project is easy to misread as a piece of software you install. It is closer to a data pipeline with a public output. The root of the repository contains the generated artefacts themselves, including the two hosts lists named all and reward, an Adguard rule file named adb.txt, an Adaway white list named Adaway_white_list.prop, and an Adclose rule file named 10007.rule. Alongside them sit update_action.sh and update_README.sh, a configure directory, an index.html for the GitHub Pages site, and a busybox entry whose purpose is not explained anywhere in the documentation.

If your plan was to clone a tool and run it locally, there is no such entry point described. You subscribe to a URL.

The licence is GPL-3.0, which is worth noting for a generated data set. The generated output is what other projects redistribute, and the GPL text covers the repository contents rather than the URLs in it.

## Two hosts lists differ by a small, deliberate gap

The two main subscription targets are the full list and the reward variant. The Chinese README states the counts it had on 2026-10-20 at 14:02:07: the full version had 12563 cumulative blocked domains, and the version that keeps ad reward domains had 12493.

The gap is 70 domains. That is a small fraction of the total, and it is the whole point of the second file. Some sites pay users a small amount for viewing ads, and a blanket block stops that from working. The reward variant is for people who want the ad hosts gone but want to keep the sites that compensate them, and for anyone whose income depends on a blocked domain still resolving.

The project also takes the opposite position in one place. There is an Adaway white list in the subscription table, which is a list of domains to exclude from blocking rather than to block. Keeping both the block list and the exclusion list consistent is the hard part of any ad blocking setup, and shipping the exclusion list as a subscription alongside the block list is a practical answer to that.

The counts in the README are a snapshot of one run. They are not a promise about the size of the next one.

## Each blocking client gets its own file format

A hosts file is not a filter list, and the repository publishes a separate artefact for each target rather than one universal format. The table in the README lists five subscriptions, each with a raw GitHub link, a GitHub Pages link and a CDN accelerated link.

For Adguard, the artefact is adb.txt, an Adguard rules file. For Adaway, the artefact is Adaway_white_list.prop, a property style white list. For Adclose, the project publishes its own rule format in 10007.rule, named after the repository, and the repository topics include adclose and adguard-blocklist entries.

The two hosts files, all and reward, are the generic entries in that table, and they are the ones you would use with a plain hosts file, an Adguard Home instance or a router based blocking.

The practical consequence is that the client you use decides which URL you paste, and mixing them up leads to a blocking setup that silently does nothing, because the client parses the file it was given and finds nothing it recognises. The README also tells users inside China to prefer the mirror links, which is a routing consideration rather than a technical one, but it applies to every row of the table.

## First use is one URL pasted into one client

There is no installer here, so the walkthrough is short. Open the subscription table in the README, decide which client will read the rules, and copy the raw GitHub link for the matching artefact. For a hosts file based setup you would take the all link, for Adguard the adb.txt link, for Adaway the Adaway_white_list.prop link, and for Adclose the 10007.rule link.

To see what the payload looks like before you commit to it, you can pull the two hosts files directly with curl. These are the raw subscription endpoints listed in the README table:

```bash
curl https://raw.githubusercontent.com/lingeringsound/10007_auto/master/all
curl https://raw.githubusercontent.com/lingeringsound/10007_auto/master/reward
```

The output is a plain list of host entries, one domain per line, and the difference between the two responses is the domains kept for ad reward sites. Fetching the Adguard rule file and the Adclose rule file works the same way, with adb.txt and 10007.rule in place of all.

Paste that URL into the subscription or blocklist field of your client and let it fetch. A hosts file client will read the same content as a hosts file, so the file is downloaded to a known path on disk, while a rule based client keeps the URL and pulls it again on its own schedule. The difference shows up in how you update later: the URL based client updates on its own, and the file based one needs your automation to fetch the URL again and replace the file.

Two decisions belong to you at this point rather than to the project. The first is the full list against the reward list, and the second is the mirror choice, raw GitHub, GitHub Pages or jsDelivr. Nothing in the documentation tells you which combination is best for your network, so pick the mirror that resolves quickly where you are and check that the client reports the expected number of rules after the first fetch. If the count is zero, the format and the client do not match and the rules are being ignored.

## The ruleset is assembled from upstream lists

The credits table in the README is the most informative part of the documentation. Nine upstream projects are acknowledged as the sources of the hosts entries: a project called ad-wars, yhosts, the Steven Black hosts list, oisd, neodevhost, the 1024 hosts list, AD-hosts, hblock and 1Host.

So the assembly is a merge. The repository does not discover ad domains itself, it collects from lists that others maintain, and its own contribution is the combination, the two variants, and the per-client formatting. That division of labour has an obvious upside, since the hard, continuous work of finding new ad domains stays with the upstream projects, and an obvious downside, since a mistake or an overreach in any of the nine sources lands in your blocking client unchanged.

There is no per-entry provenance. A domain in the all file tells you nothing about which upstream list contributed it, so if one source is too aggressive, there is no supported way to exclude that source's entries. The one exclusion mechanism offered is the Adaway white list, which is a domain-level rather than a source-level filter.

This is also the clearest reason the project is not an alternative to the upstream lists. It is a packaging layer on top of them.

## Updates happen in the repository, not on your device

The repository contains a .github directory and two scripts, update_action.sh and update_README.sh, and the last push was on 2026-10-20, the day before the counts in the README were recorded. The repository is not archived and publishes no GitHub releases, so there is no version to pin and no changelog to read; the only history is the commit log and the files themselves.

That model is the point. You add one URL to a client, and the client keeps pulling the current version. There is nothing to schedule on your own machine, no cron job, and no merge conflict to resolve when two of your devices update at once.

The cost is that you are trusting a moving target on someone else's repository. If a commit introduces a bad entry, every subscriber receives it on the next fetch, and there is no published rollback mechanism. A pin-and-review workflow, where you pull the file, diff it against last week's and commit your own copy, avoids that and loses the automation.

The README does not state a commit schedule, so how often the generated files change is not something the documentation commits to.

## Mirrors exist because the primary host sometimes does not respond

Each subscription is offered in three forms: the raw.githubusercontent URL, the GitHub Pages copy at lingeringsound.github.io/10007_auto, and the jsDelivr accelerated copy on cdn.jsdelivr.net. The homepage of the project is the Pages site, and index.html in the repository root is the page itself, which carries the subscription table and the statistics.

A fourth set of links sits inside a details block, titled in a way that says the primary source may stop working at some point. Those point at a Gitlink mirror, and the same five artefacts are available there: the full list, the reward variant, the Adguard rules, the Adaway white list and the Adclose rules.

That is four ways to reach the same content, which tells you something about the operational reality of this project. The intent is clearly to keep a blocking configuration working for users whose network cannot reach GitHub quickly or at all, and the mirror set is the reason a subscription pasted a year ago can still resolve.

The practical advice is to pick one URL per client and not mix forms. Two clients on different mirrors will update at different times, and if you ever compare their contents to work out which is ahead, the answer is usually that they are simply different snapshots.

## A hosts file is a blunt instrument compared with DNS filtering

The alternative approach to the one this project offers is to filter at the DNS layer with a server you control, and the difference is worth understanding before you pick a subscription.

A hosts file is a list of domain names mapped to a null address, applied by the operating system before any request goes out. The advantage is that it needs no server, no extra software and no network hop. The limitation is equally clear. It does not apply to applications that resolve names through their own path, it does not cover traffic to shared hosting or CDN addresses where a blocked domain shares an IP with content you want, and it cannot express anything other than a flat domain match.

A DNS filtering service, such as an Adguard Home instance, applies the same kind of rule set but on the network, where it can also filter by URL for browsers that support encrypted DNS, log what was blocked, and apply rules per device or per client. The cost is running a server, keeping it reachable, and accepting that devices must be pointed at it.

The 10007_auto subscription format follows the first model, with the Adguard and Adclose rule files as the middle ground, since those clients apply rules inside an app or a server you already run. Which model fits depends on your network, not on the quality of the domain list.

## Conclusion

Adopt 10007_auto if you want a single subscription URL that keeps itself current, and you are happy to trust a ruleset assembled from upstream lists such as Steven Black and oisd rather than curating your own. Do not adopt it if you need to see which domain came from which source, or you need the ruleset to be auditable and locally generated, because the repository publishes generated output rather than the filtering logic behind it. Before you point a device at it, read the reward variant against the full variant and pick one deliberately, then check that the URL you paste points at the raw file, the GitHub Pages mirror or the jsDelivr copy, since the three are not guaranteed to update at the same moment.

## FAQ

### How do I use the 10007_auto subscription?

Pick the artefact that matches your blocking client from the subscription table in the README: the hosts lists named all and reward, adb.txt for Adguard, Adaway_white_list.prop for Adaway, or 10007.rule for Adclose. Each is available as a raw GitHub link, a GitHub Pages link, a jsDelivr link and a Gitlink mirror link, and the README tells users in China to prefer the mirrors.

### What is the difference between the full list and the reward list in 10007_auto?

The full version blocks every collected domain, while the reward version keeps domains that pay users for viewing ads. The README recorded 12563 blocked domains in the full version and 12493 in the reward version on 2026-10-20.

### Where do the blocked domains in 10007_auto come from?

The README credits nine upstream hosts projects as sources, including the Steven Black hosts list, oisd, yhosts, ad-wars, neodevhost, 1024, AD-hosts, hblock and 1Host. The repository combines their entries and publishes the result in several formats.

### How often does 10007_auto update?

The repository holds update_action.sh and update_README.sh under a .github directory, and the last push was on 2026-10-20, but the README does not state a commit or update schedule. Consumers get the current file by pointing their blocking client at the subscription URL.

### What licence does 10007_auto use?

The repository is licensed under GPL-3.0, with the LICENSE file in the repository root.

## Sources

- [Issues](https://github.com/lingeringsound/10007_auto/issues)
- [License: GPL-3.0](https://github.com/lingeringsound/10007_auto/blob/master/LICENSE)
- [lingeringsound/10007_auto on GitHub](https://github.com/lingeringsound/10007_auto)
- [Project website](https://lingeringsound.github.io/10007_auto/)
- [README](https://github.com/lingeringsound/10007_auto/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lingeringsound-10007-auto