How to read SNSCDN network check results: PASS, FAIL, and SKIP

SNSCDN netcheck helps identify the earliest abnormal step in one diagnostic run. It is not a speed test and does not validate a subscription, client configuration, or availability from every region.

After downloading or copying the public tools repository, open its root directory. On macOS or Linux, run:

bash bin/netcheck.sh example.com 443

On Windows PowerShell, run:

.\bin\netcheck.ps1 example.com 443

Replace example.com with the public hostname you need to test. Never use a subscription URL, token-bearing URL, administration address, private IP address, or another non-public target.

The scripts do not upload their result to SNSCDN, but they do make normal DNS queries and connections to the chosen target. The resolver and target may observe ordinary query or connection metadata.

Identify which version you ran

Some services reject HEAD, so Windows may report 403, 405, or a generic HTTP failure even though a browser using GET can open the page. That difference alone does not prove the site is offline.

Read the output from top to bottom

DNS lookup failed

This run did not obtain an IP address for the hostname. Check the spelling, then compare Wi-Fi with mobile data without changing other variables. A failure on only one network points first to that network or resolver path. Failures on several networks justify checking the domain's public DNS state. This line alone does not prove that the server is offline.

TCP port ... is unreachable

The device could not connect to the target port within the timeout. Possible causes include the local firewall, access network, route, port policy, or remote service. Later HTTP checks may fail as a consequence, so start with the earliest TCP error instead of treating every failed line as an independent problem.

TLS certificate received

This means only that the Bash script received certificate data that OpenSSL could parse over a TLS connection. It does not fully validate the trust chain, hostname match, validity period, or browser compatibility, so it is not equivalent to “the certificate is completely valid.”

If the browser still shows a certificate warning, separately check the device clock, hostname, validity period, and trust chain. Do not ignore the warning or disable certificate verification as a workaround.

TLS handshake or certificate check failed

The Bash script did not obtain parseable certificate data. The hostname, an intermediary, TLS configuration, or the remote service may be involved; this line alone does not prove that the certificate expired. Windows has no separate TLS line, so related exceptions usually appear in HTTP request failed: ....

An explicit HTTP 4xx or HTTP 5xx

Only an explicit HTTP status confirms that the tool received an HTTP response. A 4xx response usually means the request was rejected or did not meet endpoint requirements. A 5xx response means the service could not process it normally. Neither means that the network is completely unreachable.

The Bash version marks 2xx/3xx as PASS and other explicit status codes as FAIL. It does not follow redirects, so [PASS] HTTP 301 or 302 proves only that a redirect response was received, not that the destination works. The Windows version uses HEAD and may place non-success responses in its exception summary.

A generic HTTP request failed

This is not proof that the request reached the HTTP service. DNS, TCP, TLS, timeout, connection interruption, a rejected HEAD request, or a non-success status can all produce a generic failure. For PowerShell, read the exception summary on the same line. The Bash version suppresses curl's error summary, so look back to the earliest DNS, TCP, or TLS result above it.

[SKIP] and the final [PASS]

[SKIP] means that a check did not run; it does not mean that it passed. The Bash script counts only [FAIL], so it can still print [PASS] No blocking problem detected after one or more skipped checks. Review every line instead of reading only the summary. The Windows version currently has no SKIP output.

If every available check passes, that means only that this run found no blocking problem. It is not a bandwidth test, does not validate client settings, and does not prove stability from other networks, regions, routes, or times. Continue with the connection and support guide for broader troubleshooting.

Prepare a privacy-safe support report

Include only:

• device OS and version;
• network type, such as home Wi-Fi or mobile data;
• date, time, and time zone;
• the public hostname and port;
• each [PASS] and [FAIL] label, plus any [SKIP] from the Bash version;
• a short browser or client error shown at the same time.

Before sharing, remove resolved IP addresses, full URLs, certificate details, account email, order information, subscription URLs, QR codes, access tokens, and other credentials. A PowerShell exception summary may also contain a URL or internal detail, so inspect and redact it first. Do not paste a complete log into a public issue, forum, or group chat. Use the authenticated ticket system for account, order, and subscription questions.