There are suspicions that the site is behaving in a special way with you? There are many local and not very reasons why the site can be opened by the developer, but be inaccessible to customers. Or vice versa. An overview of popular causes, as well as methods for diagnosing them using the free features of the
HostTracker service
, is under the cat.

“Everything works for me, look for the cause on my side” - a phrase that, because of its banality and omnipresence, was already firmly established in the environment of near-jokes and epics. There may be a lot of reasons, but the result is always annoying: how is it, here’s the source code, everything is compiled, but you still get the cap. The first reaction from the developer to such a situation is often a deep immersion into the depths of the code, although the reason is not always in it. Therefore, to save time and effort, it is strongly recommended to first locate the cause. Remote site verification services, for example this one, can help in
this .

')
This publication is a continuation of the series, which describes in detail the functions of the
HostTracker service. The previous parts can be found here:
first ,
second ,
third .
For whom my site does not work?
Obviously, the first thing that needs to be done when suspicion arises is to find where this problem has manifested itself. For this, it is very convenient to be able to test from a distributed network:

The test results show where the site is available and where it is not from. The check also shows the time it takes to determine the DNS records, page load, as well as the IP address being checked - which helps determine the cause when using redirects, CDN and some other utilities. If the site is not accessible via HTTP, an error will be returned. This may be an HTTP error code — for example, 404, 503, and others. Or a connection error. Or timeout. For each type of error, you need to look at where it is spotted: if, for example, the site is physically located in Germany, and we see timeouts from Australia and South America, it means that some brakes have appeared on the server or on the network and requests with a greater physical delay are processed no longer have time. If there is a server error, but not from anywhere - the limit of simultaneous connections may be exceeded, or the server is overloaded and unable to process all requests at once. You can also find interesting “terrain features” - some hosting or even whole countries banned visits from some other regions and countries. And this will also be displayed in the results.
However, checking over HTTP still cannot provide complete information. Therefore, there are additional checks available - ICMP (ping):

Shows whether everything is good with network access. There is also a trace:

which can help to identify some problems, even if the ICMP protocol is closed by the hoster in order to avoid DDoS attacks, as is often the case lately. Some of the information about the availability of the network can be pulled even from here.
It is still possible to check any port, which can greatly simplify the search for problems in cases where the firewall is configured not from the shoulders, answer the questions - why the site does not pull information from the database / FTP server (whereas locally “everything works”) and simplify a lot other abnormal situations.
As practice shows, the skillful use of this tool can greatly simplify life. Making sure that the site is accessible from all over the world - you can not run back to the previous version because of one client, which, as it turns out, javascript is disabled in the browser. Having seen a network error, feel free to strain administrators or data center support, arguing your answer with a link to the results of this check. And if the test still shows a server error, you can quickly go into the logs and act according to the principle “quickly raised is not considered to have fallen”.
Prevention - who needs it
However, the technical problems of the site itself are not the only things that the responsible site can face. The site can be blacklisted by Roskomnadzor - for this there is a RusRegBL check. Or in the lists of spammers and malicious hackers, even without having anything to do with it - the DNSBL check is suggested, you can read more
here . Also, the site is constantly creeping problems, the causes of which are bugs or holes in platforms or development tools. To solve these problems, the Health Check function has been created, which checks the site for current and popular vulnerabilities:

And finally, there is a function WhoIs - to see who owns the domain or site, without using Google once again.
What if?
Is it possible to break a competitor's website using these functions? - No you can not. Many consecutive checks of the same site will be carried out through the captcha or even blocked. If this is your website that you want to check regularly - there is a function of regular checking, which is described in the
previous section . To do this, of course, you will need to register, in order to avoid abuse. But it helps a lot to automate the process of monitoring and diagnostics. For these purposes there is also an
API , but this is already for the automation gurus.
As always, we will be grateful for all wishes and criticism.