Network Checker: a diagnostics and configuration suite for constrained networks

What the project is and where it comes from

Network Checker is a set of network tools curated for a specific situation. The README says it plainly in its subtitle: a set of network tools curated for Iran's Internet situation. The repository description is more compressed, describing it as a set of tools to help bypass DPI, which is deep packet inspection, the practice of inspecting traffic in order to block, throttle or shape it.

That framing explains the shape of the software. A general network diagnostic tool asks whether the internet is working. This one assumes the internet is filtered and asks which parts still work, which path a connection takes, and which configuration file will still connect once it does.

The implementation is a Flutter application written in Dart. The repository confirms it in the tree: an android/ directory, a linux/ directory and a windows/ directory alongside lib/, plus a pubspec.yaml, a pubspec.lock, a .fvmrc pinning a Flutter version, and a .metadata file. There is no ios/ or macos/ directory, so the three platforms named in the README, Android, Windows and Linux, are the complete set. The devtools_options.yaml and analysis_options.yaml are standard Flutter tooling files.

Two things frame the release history. The project is under the GPL-3.0 licence, and the tag names are plain version numbers: 1.7.2 on 2026-10-09, 1.7.1 on 2026-09-23 and 1.7.0 on 2026-09-11. The last push to the repository was on 2026-10-09, the same day as the 1.7.2 tag, so the releases and the source move together.

The diagnostics side: protocols, DNS and reachability

The first tool in the feature list is Internet Diagnostics, described as a set of automated tests for different network protocols, DNS providers and websites accessibility, and it is ready to be analyzed with AI. That last point is the interesting design choice. Rather than producing a pass or fail, the output is a structured report meant to be fed to a language model and explained.

The Domain Checker scans the most visited domains to see which are reachable, and you can add your own. This is the tool that answers the question a person in a filtered network asks first, which is whether a specific site works right now.

The DNS Latency Test measures latency against well-known DNS providers, and the README credits DNS-XS as its inspiration. The DNS Hunter checks what Iranian datacenters resolve DNS requests to for specific domains, and it credits a project of the same name. Both of these are measurements rather than actions, and that is worth noticing: when a network manipulates DNS, the resolver's answer is often the thing that has changed, and a latency number or a resolution result is evidence you can compare before and after.

The Diagnostics entry appears again as a screenshot tile alongside the others, which suggests the app presents each tool as a separate screen with its own output rather than one merged report.

For the Domain Checker and the DNS tools, the practical caveat is that they report what is true at the moment of the query from the network you are on. They are measurements, not configuration, and a result that passes does not make the underlying path stable.

The scanning side: edge IPs, CDN ranges and SNI

Three of the tools scan ranges of IP addresses.

The Edge IP Checker looks for accessible Cloudflare edge IPs. The Persian-language notes in the README add the operational detail that the official Cloudflare ranges are checked by default, that not all the ranges you can scan are official ones, and that any IP range using Cloudflare's service is usable, including ranges inside Iran. The connection domain can be changed from the settings at the top of the screen, and the default is set to chatgpt.com, though any domain behind Cloudflare works. For V2Ray, the note is more restrictive: only the main V2Ray domain is currently available to scan.

The CDN Xray Scanner scans CDN IP ranges using the Xray core with your own JSON configuration, and the README links a guide, get_json_for_cdn_scan.md in the repository, for preparing that configuration. A Persian note adds why using the Xray core matters: the scanner tests the IPs through the core, so if the test succeeds the IP will work in your configuration. The settings also let you increase the number of simultaneous scans.

The Akamai Scanner scans Akamai IP ranges.

The SNI Spoof Check tests whether SNI spoofing is open, and it credits an existing sni scanner project.

There is a Linux-specific instruction attached to the Edge IP Checker, and it is the kind of detail that only appears after someone has hit the problem:

ulimit -S -c unlimited -d unlimited -f unlimited -i unlimited -l unlimited -m unlimited -n 65535 -q unlimited -s unlimited -t unlimited -u 65535 -v unlimited -x unlimited

The note says to run this before launching the app if you are scanning a lot of IPs on Linux, and that it resets after a reboot. It raises the process limits so that a large number of sockets does not fail, which is what a scan across a wide range needs.

The configuration side: rewriting VLESS configs and generating Netlify configs

Two tools take an existing configuration and produce a modified one, which is where the project stops being a monitor and starts being an editor.

The VLESS Config Modifier replaces the IP address in a VLESS config with other IPs from a list or from IP ranges, and returns all the resulting configs. The inspiration credited is an existing v2ray config modifier project. The workflow is the obvious one: point it at a working configuration, give it candidate addresses, and get back a set of configurations that differ only in the address, each of which can be tried in turn.

The Netlify Config Generator produces multiple Netlify configurations from multiple SNIs and IPs, and it credits IR_NETLIFY. The pattern is the same, and the reason it works is the same: a configuration that names a domain which resolves to a specific address will fail once that address is filtered, and producing one configuration per candidate address turns a single point of failure into a list to try.

The Akamai Scanner and the Edge IP Checker feed this workflow. The scanner finds candidate addresses that respond, the generator rewrites the configuration, and the result is something you can try. That division of labour is the clearest thing about how the tools relate to one another, and it is also why the scanners report the domain they were tested against: a candidate that responded to one SNI is not automatically usable for another.

One caveat the README raises for the CDN scanner is worth carrying into any plan. A passing scan means the IP worked at that moment, from that network, with that configuration. Filtering rules change, and an address that works today can stop working without anything on your side changing.

The Android-only piece: encoding a config into SMS

One feature is marked as Android only, and it is the one with the most interesting reasoning.

The Config Encoder for SMS exists because sending configuration files over SMS is normally blocked. The tool encodes English text using Persian characters, and decodes it on the target device. The trick is that the payload stops looking like the English text an inspection system would recognise, and becomes an ordinary sequence of characters from a script that is expected to appear in Persian-language traffic.

This is the only feature in the set that depends on the receiving device as well as the sending one, and it is why the download section separates the Android build from the Windows and Linux builds.

The persistence of the tools is also worth noting. The Akamai and Edge scanners work by testing addresses against a domain, so a scan performed from one network may return addresses that are useful from another network and vice versa. The project therefore has some value as a shared dataset rather than only as a local utility, which is presumably part of why the licence is the GPL-3.0 rather than a permissive one: sharing the code is required, and the data it produces can be shared freely on top of that.

The last thing to note is what the diagnostics output enables. The Internet Diagnostics report is described as ready to be analyzed with AI, which suggests the intended workflow is to run the tests, hand the output to a language model, and get an explanation of what the network is doing to you. That is a sensible use of a general-purpose model, and it does not require the tool to know anything about your particular filtering regime.

Limits: measurement is not a fix, and scanning is bounded by what you can reach

Several limits are worth stating plainly.

The first is that every tool here reports or edits, and none of them changes the network. A passing domain check tells you a site is reachable from where you are. An accessible edge IP tells you one address answered. Neither makes the filtering go away, and neither makes the access stable. The tools produce the inputs for a manual process, and the process of trying configurations until one works is still manual.

The second is the scope of the scanning. The Edge IP Checker works on Cloudflare ranges, the Akamai Scanner works on Akamai ranges, and the README says that for V2Ray only the main domain is currently available to scan. The DNS Hunter is specific to Iranian datacenters. None of these is a general reachability test against arbitrary providers, and the Cloudflare note about non-official ranges being usable means the tool operates on ranges its authors did not necessarily authorise for scanning.

The third is platform coverage. Android, Windows and Linux are what exist. The absence of an iOS build is not an oversight but a design position, given that the SMS encoder feature depends on the platform.

The fourth is that the project is not a library and not an API. It is a Flutter application you download as a binary from the releases page, with the source in the repository. There is no documented command line interface, no scripting surface and no way to drive the scanners from a schedule. That matters if you wanted to run the scans on a timer and feed the results somewhere automatically.

Finally, the release cadence is fast: three tagged versions between 2026-09-11 and 2026-10-09. Fast releases in this space are good, because the networks change often, but they also mean you should check what changed between versions rather than assuming your configuration carries over.

Network Checker against a general network diagnostic and against doing the scanning yourself

Two comparisons make the choice clearer.

The first is against a general network diagnostic tool. A generic connectivity checker answers one question, is this host reachable, and it does so with a handful of HTTP requests. Network Checker does something different: it runs a broad set of protocol tests and produces a structured report designed to be read and explained. For a network that filters selectively, where some protocols work and others do not, and where the diagnosis matters more than the single yes-or-no, that difference is the whole value. For an ordinary connection, the general tool is faster to answer with and gives a cleaner signal.

The second is against doing the scanning with your own scripts. This is entirely feasible, and the README credits the individual open source projects that each of its tools was inspired by: DNS-XS for the DNS latency test, DNS Hunter for the resolver check, CF Scan Tolid Melli for the edge IP scanner, a v2ray config modifier for the VLESS rewriting, Morteza Bashsiz Scanner for the CDN scanning, and an sni scanner for the SNI check. So each tool corresponds to an existing script or tool that you could run yourself.

What running them yourself does not give you is the integration. The scan, the config rewriting and the diagnostics are separate projects that each need their own setup, and the useful workflow is to scan, rewrite, then test, which is exactly the sequence the app performs. There is also the packaging: one Flutter application that runs on Android, Windows and Linux, with the platform-specific bits such as the SMS encoder and the Linux socket limits already handled.

The honest counterpoint is that a collection of scripts is more flexible. You can schedule them, pipe the output, and modify the logic, none of which the application supports. The choice comes down to whether you want a working tool now or a pipeline you can extend.

Editorial conclusion

Adopt Network Checker if you are diagnosing a network that inspects and throttles traffic and you want the measurements and the configuration rewriting in one place rather than assembling them from separate scripts. Do not adopt it as a general network troubleshooting tool for an unrestricted connection, where the scanning features are mostly noise, and do not treat a passing scan as proof a configuration will keep working. Verify first which platform build you install, that the Xray or V2Ray core your configuration depends on is present if you use the config tools, and that the ranges you scan are ones you are permitted to test.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mirarr-app/network-checker on GitHub
4. README
5. Releases