Zbudowałem Gitae, bo ciągle wracałem do tego samego praktycznego pytania: czy strona naprawdę nie działa, czy problem jest tylko po mojej stronie?
Jedna karta przeglądarki to słabe narzędzie diagnostyczne. Strona może się nie otwierać, bo padł origin server, ale powodem może być też DNS, problem z certyfikatem HTTPS, routing, reguła firewalla, zamknięty lub filtrowany port, ISP, trasa VPN, stan przeglądarki albo lokalny cache. Objaw jest ten sam. Właściwa reakcja — zupełnie inna.
To właśnie chciałem rozwiązać w Gitae: nie tylko pokazać zielony albo czerwony status, lecz pomóc zawęzić problem do warstwy, którą warto sprawdzić jako następną.
Co naprawdę kryje się za „strona nie działa”
Wiele prostych website checkerów odpowiada na jedno wąskie pytanie: czy dany URL odpowiedział z jednego miejsca w jednym momencie? To jest przydatne, ale to jeszcze nie diagnostyka awarii.
Jeśli DNS jest błędny, restart aplikacji nic nie da. Jeśli HTTPS nie działa przez certyfikat, zmiana treści strony nie ma znaczenia. Jeśli port TCP jest nieosiągalny, sam serwer nadal może działać. A jeśli strona otwiera się z zewnętrznego serwera, ale nie z mojego łącza, problem może leżeć gdzieś na trasie między moją siecią a celem, a nie na application serverze.
Dlatego Gitae opiera się na prostym modelu: strona internetowa to łańcuch zależności, a każdy test daje informacje tylko o części tego łańcucha.
Zewnętrzny punkt widzenia, a nie wyrocznia
Testy Gitae uruchamiam z własnych serwerów VDS w Moskwie i Helsinkach. Dzięki temu mam punkty obserwacji poza komputerem i siecią, na których zauważyłem problem.
Jeśli lokalnie strona nie działa, ale odpowiada z obu VDS, to cenna wskazówka: origin przynajmniej nie jest niedostępny wszędzie. Wtedy dokładniej sprawdzam lokalny DNS, routing ISP, VPN, przeglądarkę, firewall lub inne problemy zależne od konkretnej trasy. Jeśli zawodzi także test zdalny, jest więcej powodów, by badać serwer, DNS, certyfikat, routing albo szerszy problem sieciowy.
Zdalny test nie jest jednak automatycznie „bardziej wiarygodny” od lokalnego. Dwie lokalizacje VDS nie reprezentują całego internetu. Strona może działać w Moskwie i Helsinkach, a nie działać w innym kraju, u innego ISP, na innym CDN edge albo w innej sieci. Traktuję zdalny wynik jako dodatkowy punkt obserwacji, a nie globalny werdykt.
Co Gitae sprawdza obecnie
- Website check — sprawdza, czy URL odpowiada z zewnętrznego serwera.
- SSL check — sprawdza stan certyfikatu HTTPS/TLS i problemy związane z certyfikatem.
- DNS check, nslookup i dig — pokazują, jak domena się rozwiązuje i jakie rekordy DNS są zwracane.
- Reverse DNS i IP check — pokazują dane IP oraz PTR/reverse-DNS.
- Domain info i domain age — dostarczają podstawowych informacji o domenie.
- Port check — testuje osiągalność portu z lokalizacji sondy.
- Find your IP — pokazuje publiczny adres IP widoczny dla usługi.
- Ping i traceroute — dostarczają sygnałów o latency, packet loss i trasie do hosta.
- Hosting check i CMS detection — pokazują sygnały infrastruktury i technologii pomocne przy identyfikacji.
Celowo traktuję te wyniki jako sygnały. Rekord PTR nie dowodzi, kto jest właścicielem serwera. CMS detection oparta na publicznych fingerprintach nie dowodzi dokładnego stacku. Port nieosiągalny z jednej sondy może być filtrowany po drodze, a nie zamknięty wszędzie.
Jak interpretuję wyniki
Największą wartość daje połączenie kilku testów.
Jeśli DNS zwraca oczekiwany adres, certyfikat HTTPS jest poprawny i strona odpowiada z obu VDS, ale lokalnie nadal się nie otwiera, najpierw dokładniej badam lokalną trasę, zanim zacznę zmieniać serwer. Jeśli DNS jest niespójny albo zdalny website check także się nie udaje, mam więcej powodów, żeby sprawdzać infrastrukturę.
Ping i traceroute też wymagają ostrożności. ICMP może być filtrowany albo rate-limitowany. Brak jednego hopa w traceroute nie oznacza automatycznie uszkodzonego routera, a host nieodpowiadający na ping może normalnie obsługiwać HTTPS. Te narzędzia dostarczają kontekstu, a nie ostatecznej diagnozy.
Moja główna zasada jest prosta: jeden udany test nie dowodzi, że cały system jest zdrowy, a jeden nieudany test sam nie wyjaśnia przyczyny.
Dostępność a SEO to nie to samo
Dostępność ma znaczenie także dla SEO, ale awaria techniczna nie jest tym samym co problem z rankingiem. Crawling to nie indexing, a indexing to nie traffic.
Jeżeli crawler nie może dotrzeć do strony z powodu błędów DNS, sieci lub serwera, w tym momencie nie może poprawnie pobrać danego contentu. Google dokumentuje, że błędy sieciowe i DNS podczas crawlowania są traktowane podobnie do błędów serwera 5xx, a długotrwała niedostępność może wpływać na crawl i już zaindeksowane URL-e. Nie oznacza to, że każda krótka awaria automatycznie powoduje stratę SEO, ani że narzędzie diagnostyczne może udowodnić, że późniejsza zmiana ruchu została wywołana właśnie tym przestojem.
Dla użytkownika sprawa jest prostsza: jeśli nie może wejść na stronę, nie może z niej korzystać. Zależnie od projektu może to oznaczać utracone sesje, leady, konwersje lub przychód. Sam test techniczny nie mierzy jednak wpływu biznesowego.
Praktyczna kolejność diagnostyki „leżącej” strony
- Potwierdź objaw z innej sieci. Nie zakładaj, że lokalna przeglądarka reprezentuje cały internet.
- Sprawdź DNS. Potwierdź rozwiązywanie domeny i oczekiwane rekordy.
- Sprawdź HTTPS/TLS. Zweryfikuj certyfikat i błędy połączenia.
- Sprawdź wymagany port. Przetestuj osiągalność z punktu pomiarowego.
- Porównaj sygnały sieciowe. Używaj ping i traceroute jako danych pomocniczych.
- Sprawdź IP, reverse DNS, hosting i CMS. Pomagają potwierdzić, że trafiasz do oczekiwanej infrastruktury.
- Dopiero wtedy zawężaj dochodzenie. Oceń, czy dowody wskazują bardziej na aplikację, serwer, DNS, trasę sieciową czy lokalne środowisko.
To nie jest uniwersalny protokół incident response. Dla mnie to przede wszystkim sposób, by nie zmieniać złej warstwy tylko dlatego, że jedyną początkową informacją jest „strona się nie otwiera”.
Najpierw realna użyteczność, potem monetyzacja
Gitae na razie nie jest monetyzowane. Najpierw zbudowałem je dla siebie, bo chciałem szybko sprawdzić stronę spoza własnego komputera, a następnie od razu przejść do DNS, certyfikatu, portów i sieci bez skakania między oddzielnymi narzędziami.
Obecny cel to poprawić wartość diagnostyki i zobaczyć, czy projekt może zdobywać organiczny ruch przez SEO i realny popyt. Jeśli osiągnie choć umiarkowany traffic, chcę dodać automatyczny monitoring stron z natychmiastowymi alertami w komunikatorach. To rozszerzenie tej samej idei z ręcznej diagnozy na wykrywanie: zauważyć niedostępność i dać właścicielowi wystarczająco dużo informacji, by szybko rozpocząć analizę.
Rdzeń pomysłu zostaje prosty
„Up” i „down” to objawy, a nie wyjaśnienia.
DNS, HTTPS/TLS, routing, porty, hosting, aplikacja i sieć użytkownika mogą prowadzić do tego samego pozornie prostego problemu z dostępnością. Gitae nie znajduje magicznie każdej root cause, a te zewnętrzne lokalizacje VDS nie pokazują tego, co widzi cały internet. Mogą jednak zebrać kilka niezależnych sygnałów w jednym miejscu.
Właśnie takiego narzędzia chciałem: przejść od „strona się nie otwiera” do znacznie lepszego pytania: „którą warstwę powinienem sprawdzić teraz?”