Strona internetowa nie działa, ale serwer jest dostępny? Śledź awarię od DNS do aplikacji

„SSH działa, strona nie” — Zacznij od właściwego pytania

Alarmy zaczynają się włączać, użytkownicy mówią, że strona nie działa, a Twój pierwszy test daje Ci dziwny rodzaj ulgi: SSH wciąż Cię wpuszcza. Ten moment wydaje się uspokajający, ponieważ serwer nie zniknął. Ale to także miejsce, gdzie zaczyna się wiele złego rozwiązywania problemów, ponieważ „wciąż mogę się zalogować” to nie to samo co „strona powinna działać”.

Użyteczne pytanie to nie „co mogę najpierw zrestartować?” Ale „która warstwa zawiodła pierwsza?” Działająca sesja SSH dowodzi, że maszyna jest osiągalna na porcie 22. Nie dowodzi, że domena rozwiązuje się prawidłowo. Nie dowodzi:

• że porty 80 i 443 są osiągalne
• że HTTPS jest w dobrym stanie
• że aplikacja za serwerem WWW odpowiada

Ten przewodnik zbudowany jest wokół tego rozróżnienia i skupia się na diagnostyce, zamiast próbować być pełnym podręcznikiem nginx, DNS, TLS, Docker lub bazy danych.

⚠️ Ostrzeżenie: Ślepe restartowanie nginx, Docker, PHP-FPM lub całego VPS w pierwszych minutach incydentu może wymazać wskazówki, których potrzebujesz. Najpierw zbierz jedną rundę dowodów, a następnie zmień tylko warstwę, która faktycznie zawiodła.

Mapa Triage’u w Jedną Minutę

Zanim pójdziesz głębiej, zorientuj się. Kształt awarii często mówi ci, która warstwa zasługuje na uwagę w pierwszej kolejności, nawet jeśli nie znasz jeszcze przyczyny źródłowej.

Traktuj poniższą tabelę jako skrót triage’u, a nie ostateczny werdykt.

Ważna jest pierwsza uszkodzona etapa. Jeśli DNS zawiedzie, późniejsze warstwy to szum. Jeśli 443 odpowiada, ale TLS się nie powiedzie, aplikacja nie jest jeszcze twoim pierwszym pytaniem. Poniższy model mentalny to to, co sprawia, że ta sekwencja wydaje się logiczna zamiast losowa.

Dlaczego SSH nie potwierdza, że witryna działa

SSH i ruch sieciowy to różne ścieżki z różnymi zadaniami. SSH na porcie 22 potwierdza, że możesz dotrzeć do maszyny przez jej drzwi do zdalnego zarządzania. Witryna zależy od portów 80 i 443, plus warstw za nimi. To są oddzielne testy, więc „serwer dostępny” i „witryna dostępna” to nie zamienne stwierdzenia.

Najłatwiej wyobrazić sobie to jako budynek biurowy. DNS pomaga odwiedzającemu znaleźć adres budynku. Porty 80 i 443 to recepcja dla publicznych odwiedzających. Serwer WWW to recepcjonista, który przyjmuje żądanie i decyduje, gdzie ono trafia. Aplikacja to biuro, które wykonuje rzeczywistą pracę. Baza danych lub inna zależność może znajdować się głębiej w budynku. SSH to zupełnie inne wejście. Jest przydatne dla personelu, ale nie potwierdza, że recepcja jest otwarta lub że przekazanie do biura działa.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

Gdy ludzie mówią, że usługa „nasłuchuje”, mają na myśli, że faktycznie akceptuje połączenia na oczekiwanym punkcie końcowym. To jest rozróżnienie, które zmienia niejasny moment „serwer działa” w możliwą do śledzenia ścieżkę żądania.

To ważne, ponieważ HTTPS może się nie powieść zanim aplikacja w ogóle odpowie, a awarie proxy lub aplikacji mogą się zdarzyć po tym, jak frontend jest już dostępny. Dlatego następny krok jest zawsze taki sam: spójrz z zewnątrz najpierw i znajdź ostatni udany etap żądania.

Krok 1: Odtwórz błąd spoza serwera

Zacznij od strony klienta, a nie z wnętrza VPS. Jeśli to możliwe, najpierw przetestuj z innej sieci lub urządzenia, aby nie pomylić lokalnej pamięci podręcznej DNS, starego wpisu /etc/hosts lub lokalnego problemu z firewallem/VPN z rzeczywistą awarią serwera.

Użyj szczegółowego zewnętrznego żądania, aby zobaczyć, jak daleko żądanie dojdzie, zanim się nie powiedzie:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v nie jest tutaj narzędziem tylko dla ekspertów. Czytaj to jako ślad postępu. Jeśli nigdy nie rozwiąże nazwy, jesteś w gałęzi DNS. Jeśli się połączy, a następnie wyświetli Connection refused, host odpowiedział, ale nic użytecznego nie akceptuje tam ruchu. Jeśli zawiesza się do limitu czasu, pomyśl o filtrowaniu, routingu lub głębszym zawieszeniu później w ścieżce żądania. Jeśli otrzymasz odpowiedź HTTP, nawet stronę błędu, już przeszedłeś warstwę połączenia i weszłeś w wyższą gałąź.

💡 Wskazówka: Porównaj IPv4 i IPv6 na wczesnym etapie. Zapomniany rekord AAAA może sprawić, że awaria będzie wyglądać niespójnie, ponieważ niektórzy klienci preferują IPv6 w pierwszej kolejności, a inni nie.

Uruchom ten sam test raz na rodzinę protokołu, gdy w grę wchodzi dual stack:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

Jeśli IPv4 działa, a IPv6 zawodzi, lub odwrotnie, już zawęziłeś incydent szybciej niż restart usługi kiedykolwiek by to zrobił. Jeśli błąd zaczyna się od rozpoznania nazwy lub wyboru miejsca docelowego, DNS jest następną czystą gałęzią do sprawdzenia.

Krok 2: Sprawdzenie DNS i potwierdzenie prawidłowego miejsca docelowego

Zanim debugujesz nginx, potwierdź, że domena rzeczywiście wysyła odwiedzających na serwer, który myślisz, że to jest. Jest to szczególnie ważne po migracjach, zmianach IP, dostosowaniach CDN lub częściowych edycjach rekordów.

Najpierw sprawdź rekordy publiczne:

dig +short A example.com
dig +short AAAA example.com

Te dwie linie odpowiadają na bardzo praktyczne pytanie: gdzie internet uważa, że example.com znajduje się teraz? Jeden z częstych scenariuszy awarii to sytuacja, w której SSH przez IP osiąga nowy VPS, ale domena nadal wskazuje na stary adres. Inny to sytuacja, w której rekord A został zaktualizowany, ale rekord AAAA nadal wskazuje gdzieś na przestarzały adres. W takim przypadku tylko część Twojego ruchu zawodzi.

📝 Uwaga: curl --resolve jest bezpieczniejszy niż zmiana publicznego DNS w trakcie incydentu. Pozwala przetestować pochodzenie, które zamierzasz użyć, zachowując jednocześnie hostname i SNI.

Użyj curl --resolve, aby wymusić test względem IP, który oczekujesz, bez dotykania rekordów publicznych:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Jeśli to działa, podczas gdy publiczna domena nadal zawodzi, serwer może być w porządku, a DNS może być uszkodzonym warstwą. Jedna uwaga dotycząca ograniczonego CDN warta zapamiętania. Jeśli Twoje pochodzenie jest zablokowane, aby akceptować ruch tylko z zakresu IP CDN, test bezpośredniego pochodzenia może zawieść po prostu dlatego, że pochodzenie oczekuje ruchu edge, a nie arbitralnych żądań publicznych. Po potwierdzeniu miejsca docelowego, następnym pytaniem jest, czy coś użytecznego odpowiada na 80 lub 443 tam.

Krok 3: Sprawdzenie, co nasłuchuje na portach 80/443

Teraz przejdź na serwer i zadaj wąskie pytanie: czy cokolwiek faktycznie akceptuje połączenia sieciowe na oczekiwanych portach? Maszyna może być aktywna, SSH może działać, a nginx może być nawet zainstalowany. Jednak publiczne porty sieciowe mogą nadal nie mieć żadnego użytecznego nasłuchiwacza.

Najpierw sprawdź nasłuchujące porty:

sudo ss -ltnp

Puste wyjście dla :80 lub :443 oznacza, że nic użytecznego tam nie nasłuchuje. Nasłuchiwacz na 127.0.0.1 oznacza, że usługa akceptuje połączenia tylko z lokalnej maszyny. Nasłuchiwacz na 0.0.0.0 oznacza, że jest powiązany z interfejsami IPv4. [::] zwykle oznacza interfejsy IPv6. Nie zakładaj, że powiązanie IPv6 automatycznie gwarantuje potrzebną Ci ścieżkę IPv4.

Następnie użyj małego pakietu zdrowotności nginx przed zmianą czegokolwiek:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• Jeśli systemctl mówi active (running), to tylko potwierdza, że proces usługi istnieje
• nginx -t mówi Ci, czy konfiguracja jest prawidłowa
• journalctl pokazuje, czy niedawne przeładowanie nie powiodło się, plik certyfikatu zaginął, lub vhost przerwał się przy starcie.

Dla czytelników Apache’a, równoważna składnia sprawdzenia to apachectl configtest. Gdy już wiesz, że coś nasłuchuje, następny dowód jest bardziej szczegółowy: czy odpowiada właściwa strona lokalnie, gdy usuniesz sieć zewnętrzną z równania?

💡 Wskazówka: Najpierw przetestuj konfigurację, a następnie preferuj reload zamiast ślepego restartu, gdy jest to odpowiednie. Przeładowanie waliduje nową konfigurację i utrzymuje starych workerów, jeśli nowa konfiguracja jest zła; ślepi restart jest znacznie bardziej brutalny w środku incydentu.

Krok 4: Przetestuj witrynę lokalnie z prawidłowym hostem i SNI

To jest najważniejszy punkt rozgałęzienia w całym śledztwie. Zwykły curl 127.0.0.1 może być mylący. Wiele serwerów hostuje wiele witryn i wybiera odpowiedź na podstawie nagłówka Host lub, dla HTTPS, SNI. Nie pytasz, czy coś odpowiada lokalnie. Pytasz, czy prawidłowa ścieżka witryny odpowiada lokalnie.

Użyj testów lokalnych, które zachowują logikę nazwy hosta:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Sensownym sukcesem jest oczekiwana strona, oczekiwane przekierowanie lub oczekiwana odpowiedź aplikacji z prawidłowej witryny. Nie jest to domyślny host nginx, zły certyfikat ani generyczne “zwróciło HTML”. Stąd wynikają trzy czyste wyniki: lokalny sukces, lokalnie nieprawidłowa witryna lub zachowanie certyfikatu domyślnego, lub lokalny błąd/timeout. Dobry wynik lokalny wskazuje na zewnątrz na firewall, dostawcę, CDN lub kontrole routingu. Zły wynik lokalny trzyma cię wewnątrz stosu, w gałęziach upstream lub TLS.

Krok 5: Jeśli działa lokalnie, ale nie zewnętrznie, prześledzij ścieżkę sieciową

Gdy test lokalny przebiegnie pomyślnie, przestań na chwilę podważać nginx. Stack witryny prawdopodobnie działa na serwerze, a brakujący element zwykle znajduje się gdzieś między odwiedzającym a działającą usługą lokalną. Zacznij od zapory hosta, ponieważ jest to najbliższa zewnętrzna granica, którą kontrolujesz.

Sprawdź reguły po stronie hosta za pomocą narzędzia, które faktycznie używa Twój system, i wykonaj jedną szybką kontrolę rozsądku dla samodzielnie spowodowanego blokowania:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

To wyjście pokazuje tylko warstwę systemu operacyjnego gościa. Nie pokazuje filtrowania po stronie dostawcy, grup bezpieczeństwa ani reguł zapory na poziomie panelu, które znajdują się poza samym VPS. Na przykład na VPS AlexHost zapora maszyny i wszelkie kontrole sieciowe na poziomie panelu to oddzielne kwestie. Obie mają znaczenie, gdy testy lokalne działają, ale publiczni odwiedzający nadal zawodzą.

⚠️ Ostrzeżenie: Jeśli Docker publikuje porty na hoście, nie zakładaj, że wyjście UFW mówi całą historię. Docker może kierować opublikowany ruch kontenera przez NAT przed zwykłymi łańcuchami UFW. Oznacza to, że „UFW wygląda dobrze” nie zawsze oznacza, że ścieżka pakietu jest dobra.

CDN i moduły równoważenia obciążenia zasługują tutaj na własną gałąź. Źródło może być zdrowe i nadal niedostępne bezpośrednio, ponieważ tylko zakresy IP krawędzi mogą się z nim komunikować. Gdy potrzebujesz dowodu, czy pakiety w ogóle docierają, użyj tcpdump jako narzędzia tak-lub-nie:

📝 Notatka: Nieudany test bezpośredniego źródła za listą dozwolonych CDN zwykle wskazuje na politykę krawędzi, a nie na martwe źródło. W tej konfiguracji źródło jest zaprojektowane do zaufania ścieżce CDN, a nie każdemu bezpośredniemu odwiedzającemu.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Jeśli w ogóle nie widzisz pakietów SYN, ruch nie dociera do serwera. Jeśli SYN-y przychodzą i żaden SYN-ACK nie wychodzi, serwer lub ścieżka zapory nadal blokuje przekazanie. Jeśli żaden z tych wzorców nie wydaje się być blokerem, pozostałe błędy zwykle znajdują się za frontendem w przekazaniu upstream.

Krok 6: Jeśli Frontend Odpowiada, ale Witryna Wciąż Jest Uszkodzona, Śledź Upstream

W tej gałęzi serwer WWW jest osiągalny, ale następny skok za nim nie jest wystarczająco zdrowy, aby ukończyć żądanie. Tutaj “upstream” oznacza usługę, do której nginx przekazuje żądanie dalej: proces aplikacji, runtime wspierany gniazdem, kontener lub inną wewnętrzną zależność.

Strony statyczne działające, podczas gdy logowanie, wyszukiwanie, kasa lub trasy API zawodzą, to silny wskaźnik, że frontend jest obecny, a awaria zaczyna się na etapie przekazania za nim.

📝 Uwaga: Traktuj 502 jako “następny skok odpowiedział źle” i 504 jako “następny skok odpowiedział zbyt wolno.” Oba są znakami, aby śledzić ścieżkę upstream, zamiast zatrzymywać się na frontendzie.

Sprawdź aktywne przekazanie, a następnie przetestuj upstream bezpośrednio:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

W wyjściu nginx szukaj dyrektyw takich jak proxy_pass, fastcgi_pass lub uwsgi_pass. Sprawdzasz, czy nginx wskazuje na właściwy cel, przez właściwy protokół, na właściwym porcie lub gnieździe. Jeśli zaangażowane są kontenery, dodaj krótki test kondycji kontenera zamiast zgadywać:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Jeśli bezpośredni test aplikacji zawiedzie, problem jest za serwerem WWW. Jeśli działa bezpośrednio, ale zawiedzie przez nginx, konfiguracja przekazania jest gałęzią do sprawdzenia. Osiągalność bazy danych ma znaczenie tylko jako sprawdzenie zależności tutaj, a nie jako osobliwa głęboka analiza. Jeśli ten wzorzec awarii upstream powtarza się wciąż, to właściwy moment, aby przejść do dedykowanego przewodnika rozwiązywania problemów zamiast rozciągać jeden incydent na domysły.

Krok 7: Izoluj błędy TLS i certyfikatów

Ta gałąź jest węższa: coś odpowiada na porcie 443, ale przeglądarka nadal nie może ukończyć czystej, godnej zaufania sesji HTTPS. Pomyślne połączenie TCP do portu 443 nie potwierdza, że certyfikat, dopasowanie nazwy hosta lub ścieżka uzgadniania są w porządku.

Sprawdź, jaki certyfikat jest faktycznie serwowany:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Tu łapiesz typowe formy błędów: zła nazwa hosta, wygasły certyfikat, niekompletny łańcuch lub odnowienie, które nigdy nie zostało ukończone czyszczenie. Mówiąc prościej, SNI mówi serwerowi, którą nazwę hosta miałeś na myśli. -verify_hostname sprawdza, czy serwowany certyfikat odpowiada tej nazwie hosta. Po odzyskaniu sprawdź ścieżkę odnowienia, aby to nie stało się następną awarią:

⚠️ Ostrzeżenie: Jeśli polegasz na walidacji HTTP-01 do odnowienia certyfikatu, port przychodzący 80 musi być osiągalny. Zapora lub reguła dostawcy blokująca 80 może po cichu przerwać odnowienia na długo przed tym, jak użytkownicy zgłoszą, że HTTPS wygląda na martwy.

sudo certbot renew --dry-run

Krok 8: Sprawdź obciążenie zasobów, zanim uznasz to za losowe

Niektóre incydenty wcale nie są awariami osiągalności. Ścieżka jest technicznie nienaruszona, ale serwer jest zbyt głodny zasobów, zablokowany lub przeciążony, aby odpowiedzieć na czas. Wtedy witryna może wyglądać „częściowo żywa” z jednej strony i wciąż wydawać się martwa dla użytkowników.

Uruchom mały pakiet zasobów pierwszego przejścia:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Czytaj wyniki w wzorcach, a nie w izolacji.

• df -h pokazuje zwykłe wyczerpanie dysku.
• df -i wyłapuje wyczerpanie inode’ów, gdzie miejsce wydaje się istnieć, ale system plików nie może utworzyć więcej wpisów.
• free -h ma znaczenie przede wszystkim, gdy dostępna pamięć się zawala i aktywność swap rośnie.
• uptime może pokazać wysokie obciążenie nawet gdy CPU nie jest w pełni obciążony, co często oznacza, że zadania czekają na dysk lub ciśnienie pamięci, a nie na aktywne obliczenia.
• Linie dziennika jądra o zdarzeniach OOM mówią ci, czy system zaczął zabijać procesy, aby przetrwać.

Wykresy dostawcy mogą potwierdzić oś czasu. Na VPS AlexHost mogą być przydatne do sprawdzenia, czy skoki RAM, dysku lub I/O pokrywają się z awarią. Ale dowody z terminala powinny nadal prowadzić diagnozę. Ta sekcja nie jest przewodnikiem strojenia; to gałąź, która mówi ci, że witryna może zawodzić pod ciśnieniem, a nie zawodzić w routingu.

Myśl warstwami, nie paniką

Gdy SSH działa, ale strona się nie otwiera, utrzymuj łańcuch krótki i powtarzalny:

1. odtwórz błąd zewnętrznie
2. zidentyfikuj ostatni udany etap
3. potwierdź DNS i cel
4. zweryfikuj rzeczywisty listener na 80/443
5. przetestuj poprawną stronę lokalnie
6. rozgałęź się na ścieżkę sieciową, upstream, TLS lub zasoby

💡 Wskazówka: Nie zamykaj ostatniej działającej sesji SSH, dopóki nie potwierdzisz, że świeże logowanie nadal działa i masz alternatywną ścieżkę dostępu, taką jak dostęp przez konsolę dostawcy. Podczas incydentu na żywo zachowanie kontroli jest równie ważne co naprawienie pierwszego objawu.

Utrzymuj nawyki lekkie: monitoruj zewnętrznie, prowadź logi i testuj certyfikaty za pomocą certbot renew –dry-run. Zabezpiecz dostęp kopiami zapasowymi i ścieżką konsoli. Narzędzia dostawcy — zapora, wykresy, konsola (w tym AlexHost) — powinny wspierać rozwiązywanie problemów, a nie je zastępować. Skoncentruj się na naprawie pierwszej uszkodzonej warstwy, aby każdy incydent był obsługiwany z jaśniejszymi dowodami i mniejszą paniką.