AdBlock_Rule_For_Sing-box: one rule set, three formats, three mirrors each

Three formats, because SRS is not a file a client can read directly

The same rule set is published in three formats and the choice between them is not cosmetic.

The plain domain list is a text file of blocked domains. It is the format to read if you want to know what is in the set, and the one to convert if you are feeding something other than Sing-box.

The JSON form is the source format Sing-box's rule-set loader consumes, and the documentation calls the format source in the configuration.

The SRS form is the compiled binary representation Sing-box uses for a fast load, and the repository ships a Sing-box executable at its top level, which is how that compilation happens. A binary build tool committed alongside a list of domains is an unusual thing to find in a rules repository, and it is the clue to why there is a compiled artefact at all rather than only source.

So the choice is: JSON if you want the readable form or a format other than the compiled one, SRS if you want the load speed, and the text file if you want to read or reuse the list yourself.

Every format is behind three URLs, which is the real design decision

The link table in the README gives each format three subscription URLs, and that repetition is the most useful thing in the documentation.

Each of the three files is available from the GitHub raw host, from a jsDelivr CDN endpoint, and from a Statically CDN endpoint. So nine URLs in total for what is conceptually one list.

The reason is reachability rather than redundancy in the usual sense. A raw content host on GitHub is frequently slow or unreachable from some networks, and a proxy client that cannot fetch its rule set at startup either starts with no blocking or fails outright. Offering two independent CDN mirrors alongside the origin means a user whose network blocks one of the three still gets a working configuration, and the choice is a one-line edit rather than a support question.

The mirrors are pinned to the same branch as the origin, which is worth noting: they follow the branch rather than a tag, so they carry whatever is currently on it. Both CDN paths address the repository and branch directly in the URL rather than pointing at a separate published copy, which means there is no separate deployment to fall out of sync.

The cost is that a user has three places to look when a list misbehaves, and no way to tell from the URL whether a mirror is serving current content.

The rule set is applied twice, in DNS and in routing

The configuration example is short, and its structure is the part to copy rather than its contents.

The rule set appears in two places. It is referenced from the DNS section's rules with a reject action, and separately from the route section's rules with the same reject action. The route section also declares where the file comes from: a remote rule set, tagged, in the source format, with a URL and an update interval of one hour.

{
  "dns": {
    "rules": [
      {
        "rule_set": ["adblock"],
        "action": "reject"
      }
    ]
  },
  "route": {
    "rule_set": [
      {
        "tag": "adblock",
        "type": "remote",
        "format": "source",
        "url": "https://raw.githubusercontent.com/REIJI007/AdBlock_Rule_For_Sing-box/main/adblock_reject.json",
        "update_interval": "1h"
      }
    ],
    "rules": [
      {
        "rule_set": ["adblock"],
        "action": "reject"
      }
    ]
  }
}

Applying it in both places is not redundant. A DNS-level rejection stops the name lookup, so the request never leaves. A route-level rejection catches the traffic when the lookup happened anyway, for instance because something else resolved it or the client used a cached answer. The two together cover more cases than either alone.

The update interval is the detail to think about, and it does not match the publish cadence. The repository description states the list is regenerated every twenty minutes, and the release history shows timestamp-named releases arriving on that cycle. The example configuration tells the client to re-fetch hourly.

So a client following the documented example sees three of every twelve published versions. That is a perfectly reasonable default, since an ad list changes slowly enough that most updates are cosmetic, and it means the twenty-minute cadence serves the users who poll more aggressively rather than the average install.

The generator is a PowerShell script, and the repo is mostly data

The repository is small and almost all of it is output.

The top level holds the three published files, a whitelist, a timestamp file, a text file naming the rule sources it references, and one script. That script is the generator, and the repository's primary language is recorded as PowerShell, which tells you the pipeline is driven from Windows.

That is consistent with the release pattern. The releases are named with a numeric timestamp rather than a semantic version, which is the convention of a job that commits on a schedule rather than a person cutting a tag. There is one release visible in the recent list, published on the same day as the last push.

The whitelist file is the interesting one for anyone who hits a false positive. It is a generated artefact rather than a file you are meant to hand-edit, which means a local exception cannot be expressed by editing it without being overwritten on the next cycle. Doing that properly means adding a rule of your own with a higher priority, or reporting upstream, which is the same two options the collection project offers.

The two licence files at the root are worth a look before you rely on any of this. There is a copyleft file and a non-commercial file, and neither the README nor the repository summary says which one governs the rule data as opposed to the tooling.

Editorial conclusion

This rule set fits a Sing-box user on a network where GitHub's raw host is slow or unreachable, since every format ships with two CDN mirrors as well as the raw URL, and the published config shows the exact wiring for both the DNS and route sections. Leave it if you need per-domain exceptions you can edit, because the whitelist is generated rather than yours. Verify first which licence applies to your use, since the repository carries both a copyleft and a non-commercial licence file and does not say which governs the rule data, and remember that a client set to an hourly refresh sees only some of what is published every twenty minutes.

Frequently asked questions

Official sources

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