DPI Checkers: four tools for testing whether your ISP applies deep packet inspection, and how

Four censorship-detection tools in one repository, from browser checks to a Go binary

DPI Checkers contains four distinct tools aimed at different aspects of ISP censorship detection. The first is dpi-ch, a standalone Go binary for comprehensive DPI analysis, available as prebuilt binaries for Windows, macOS, Linux and Android. The second is a browser-based TCP 16-20 checker that detects whether an ISP uses the TCP 16-20 blocking method on popular web services. The third is a browser-based IPv4 Whitelisted Subnets checker that finds which datacenter IP subnets an ISP places on its whitelist. The fourth is the TCP 16-20 DWC (domain whitelist checker), which identifies which specific domains are whitelisted on a network where TCP 16-20 blocking is applied.

All four carry an 'RU ::' prefix, indicating their test data and blocking-method references are drawn from the Russian ISP context. The repository's warning block states that the content is for research and educational purposes only, and that users are solely responsible for compliance with local laws. The tools detect and document censorship methods; they do not bypass restrictions, except that the DWC tool's output is described as also useful for bypassing limitations.

For anyone outside Russia, the test data and endpoint choices are tied to the Russian network topology. The checkers would need new endpoint data and blocking-method parameters to be useful in a different jurisdiction.

dpi-ch: the Go binary for comprehensive DPI analysis outside the browser sandbox

dpi-ch is described in the README as the 'big brother' of all the other checkers, not limited by the browser sandbox. Where the web-based tools are constrained by what a browser can and cannot do in a sandboxed environment, dpi-ch runs as a standalone process with access to the full network stack. A wide range of configuration options is available; the full reference is in the documentation at ru/dpi-ch/docs rather than in the main checkers list.

Binaries are prebuilt for four platforms: Windows, macOS, Linux and Android. This is broader platform support than most censorship-related tooling, and including Android is significant because mobile internet is often under more aggressive restrictions than home broadband. The binary approach also means no language runtime needs to be installed; downloading and running the file is the full install path.

The documentation directory at ru/dpi-ch/docs contains the detailed description. The README points there rather than duplicating the configuration reference inline. Anyone evaluating dpi-ch for a specific blocking method or for a novel ISP configuration needs to read that documentation first, since the README gives no sample configuration or output format in its own text.

The most recent version is dpi-ch v0.13.0, published on 2026-09-06.

Downloading prebuilt binaries when hyperion-cs.github.io may itself be blocked

dpi-ch binaries are available from the GitHub repository's build artifacts. For the web-based checkers, the entry point is the GitHub Pages site at https://hyperion-cs.github.io/dpi-checkers/. Both paths have a practical complication: some providers block access to hyperion-cs.github.io, and the documented workaround is to load the checker in a browser before switching to the restricted connection.

This is a meaningful constraint. A tool designed to test whether an ISP censors traffic may itself be blocked by the ISP before the test can run. Preloading means opening the checker page on an uncensored network or connection before switching to the restricted one, so the browser has the tool available in memory even if the hosting domain becomes unreachable. The workaround requires anticipating the test, not reacting to a blocked connection after the fact.

For dpi-ch, the binary does not depend on the GitHub Pages domain; once downloaded, it runs without any connection to the hosting site. This is another reason to consider dpi-ch over the browser tools on networks where the GitHub Pages domain is restricted.

TCP 16-20 browser checker: three GET parameters for timeout, custom host, and provider name

The TCP 16-20 browser checker detects whether an ISP uses the TCP 16-20 blocking method by connecting to popular web services hosted by providers whose subnets are potentially subject to restrictions. The tests run inside the browser, and the source code is available on the checker's page. VPN must be disabled during the check, because a VPN connection would route traffic through a different path and hide the ISP's behavior.

The checker supports three optional GET parameters in the URL. The timeout parameter takes an integer value and defaults to 15000, setting the connection timeout in milliseconds. The host parameter takes a string and adds a custom endpoint to the tests alongside the defaults; its CORS policy does not affect whether the check can reach it. The provider parameter takes a string name for the custom endpoint and defaults to 'Custom' when not set.

These parameters let a tester add their own server to the check, which is useful when the default test hosts may give ambiguous results for a particular ISP. A server on a subnet the tester controls provides a known baseline against which the ISP's behavior can be compared more directly.

IPv4 Whitelisted Subnets: Cache the list from a clean network before running the check

The IPv4 Whitelisted Subnets checker has three buttons: Cache, Check and Save. They must be used in a specific order, and the order reveals a constraint that is easy to miss on first read. The Cache button fetches and stores in the browser's local storage a set of IPv4 subnets from autonomous systems that could potentially be on an ISP's whitelist. The README specifies that this caching process uses services that are almost certainly not on the whitelist themselves, which means Cache must be run when the provider does not use whitelists, for example on a home ISP's Wi-Fi connection. Running Cache from within the restricted network would fail to retrieve the subnet data from those services.

After caching, Check tests whether those subnets are currently reachable through the network under test. Save exports the results to a .csv file.

Four GET parameters tune the check. timeout defaults to 5000 (milliseconds per connection attempt). sn_sample_size defaults to 25, setting the number of random hosts checked per subnet. sn_alive_min defaults to 3, setting the minimum number of responding hosts needed to declare a subnet whitelisted. sn_only_24_prefix defaults to true, limiting tests to /24 subnets within each autonomous system; the default reflects that a censor is unlikely to whitelist larger subnets.

The checker sends an HTTP(S) HEAD request to port 443 for each selected host. Two failure modes are documented: false negative results are possible because selective sampling is used, and the checker will not work at all if the ISP also restricts TLS SNI, because the browser sandbox cannot spoof SNI. In the worst case, total runtime equals the number of suitable subnets multiplied by the timeout value, reaching several tens of minutes.

DWC domain checker: Python 3 and curl required, ready-to-use results available separately

On a network using TCP 16-20 blocking, DWC identifies which specific domains have been whitelisted. Unlike the three browser-based tools, DWC requires Python 3, the curl utility, and a specially configured server running on the restricted network itself, rather than only on the tester's machine. That server requirement means DWC cannot be run entirely from a single client.

A list of domains is the input, and the checker determines which of those domains are on the whitelist. Full details and configuration instructions are in the ru/tcp-16-20_dwc directory of the repository. This data can be used to understand the whitelist structure or to work around restrictions.

Pre-computed results are available for download in that same directory for anyone who does not want to configure the server component. Pre-computed results cover whitelisted domains at the time the data was last generated, which may be out of date for an ISP that changes its whitelist. The DWC tool and its pre-computed output address a different need than the browser checkers: they identify specific domains rather than subnet-level reachability.

Permissive terms, Russia-focused endpoints, and what the checkers cannot tell you

The repository is licensed under permissive open-source terms that allow modification and redistribution. The last push was on 2026-09-23.

All four tools are named with an 'RU ::' prefix and their test data is drawn from Russian ISP topology: the subnet lists reflect autonomous systems relevant to Russia, and the TCP 16-20 method is one specifically documented in the Russian censorship context. Using these tools to test an ISP in another country would require replacing the test endpoints with data relevant to that network, which is not documented in this repository.

The checkers answer the question of whether a blocking method is present and what parameters it uses. They do not answer the question of which specific resources are blocked on a given day, since that list changes and the tests work from known subnets and hosted endpoints rather than arbitrary URL lists. For the IPv4 check, even with a full Cache run, false negatives remain possible because only a sample of each subnet's hosts is tested. The browser tools are also limited to what a browser can send and observe, which excludes certain low-level network behaviors that dpi-ch can test outside the sandbox.

Some providers block the project's hosting domain hyperion-cs.github.io, which is the detail that separates the browser tools from dpi-ch in practice: if access to the hosting site is blocked before you can preload the browser checker, dpi-ch is the only tool available without a separate workaround.

Editorial conclusion

Use DPI Checkers when you need to know which blocking methods a Russian ISP applies to your connection. The browser tools are the fastest path: run the TCP 16-20 checker with VPN disabled, and use the subnet checker in two stages, caching the subnet list from an uncensored connection before checking from the restricted one. Skip the IPv4 checker if TLS SNI is also blocked, since the browser cannot spoof SNI and results will be incomplete. The DWC domain checker needs Python 3, curl, and a server the README does not configure for you. All four tools target Russian ISP methods; applying them outside Russia requires independent knowledge of local blocking parameters.

Frequently asked questions

Official sources

1. hyperion-cs/dpi-checkers on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases