DNS? Aplikacja? Reverse proxy? A może ruch w ogóle nie dociera do serwera? Można zgadywać i grzebać na chybił trafił, restartując po kolei wszystko, co się nawinie. Można też podejść do tego jak detektyw i sprawdzać krok po kroku, od domeny aż po pakiety wpadające do serwera. Ta druga metoda jest nudniejsza, ale za to działa.

Czy domena w ogóle wskazuje na Twój serwer# 

dig przyklad.pl +short

Dostaniesz adres IP, na który domena rozwiązuje się w tej chwili. Porównaj go z adresem swojego serwera. Nie zgadzają się? To problem siedzi w DNS-ie, czyli w złym rekordzie A/AAAA w panelu domeny albo w Cloudflare. Ruch nawet nie dochodzi do Twojego VPS-a.

Podejrzewasz, że zmiana DNS jeszcze się nie rozeszła po świecie? Zapytaj bezpośrednio konkretny serwer DNS, na przykład Google’a, z pominięciem cache u Twojego dostawcy internetu:

dig @8.8.8.8 przyklad.pl +short

Czy aplikacja w ogóle działa lokalnie#

Zanim zaczniesz rzucać podejrzenia na reverse proxy czy firewall, sprawdź najprostszą rzecz: czy sama aplikacja odpowiada, bezpośrednio na serwerze, z pominięciem całej reszty:

curl -v http://localhost:3000/

-v pokazuje cały przebieg połączenia: nawiązanie, wysłane nagłówki, odpowiedź. Jeśli tu wszystko gra, aplikacja jest niewinna i problem leży gdzieś dalej.

A jeśli przed aplikacją stoi reverse proxy, które rozpoznaje strony po nazwie domeny (virtual host)? Wtedy możesz udać konkretną domenę prosto z terminala, bez ruszania DNS-u, podając nagłówek Host:

curl -s -o /dev/null -w "%{http_code}\n" -H "Host: przyklad.pl" http://127.0.0.1/

200 oznacza, że proxy znalazło tę domenę i ją obsłużyło. 502, 404 albo 000 (brak odpowiedzi) mówią, że coś jest nie tak z konfiguracją reverse proxy. I to zanim w ogóle w grę wejdzie prawdziwy ruch z internetu.

Sprawdzanie reverse proxy (nginx/Apache)#

Na początek składnia konfiguracji:

sudo nginx -t

Dla Apache odpowiednikiem jest sudo apache2ctl configtest.

Składnia w porządku, a strona dalej leży? Pora zajrzeć do logu błędów. Nginx jest tam zaskakująco rozmowny i zwykle mówi wprost, co mu nie pasuje:

sudo tail -f /var/log/nginx/error.log

Taki wpis zobaczysz, gdy nginx działa, ale aplikacja za nim (backend) leży:

connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9999/", host: "localhost"

Czytamy: nginx dostał żądanie, próbował przekazać je pod 127.0.0.1:9999, a tam nikt nie odebrał. Sprawdź wtedy, czy aplikacja naprawdę działa i czy proxy_pass w konfiguracji nginx celuje we właściwy port.

Czy ruch z internetu w ogóle dociera do serwera#

Ostatnia deska ratunku. Lokalnie wszystko wygląda dobrze, a z zewnątrz strona dalej milczy. Czas zobaczyć na żywo, czy pakiety w ogóle do serwera docierają:

sudo tcpdump -i eth0 -n port 80

Zostaw to włączone, a w drugim oknie albo z telefonu spróbuj wejść na stronę.

Widzisz w tcpdump przychodzące pakiety (Flags [S] to próba nawiązania połączenia)? Ruch dociera, więc problem jest po stronie serwera: w aplikacji albo w proxy. Cisza? Ruch w ogóle nie dochodzi. Sprawdź firewall (UFW/iptables) i to, czy w panelu Mikrusa masz otwarty i przekierowany właściwy port.

Podglądanie kończysz Ctrl+C.

Najczęstsze błędy#

curl localhost działa, więc “przecież działa”. To, że coś odpowiada lokalnie, nie znaczy, że odpowiada światu. Firewall albo przekierowanie portów mogą blokować ruch z sieci i w ogóle nie dotykać ruchu lokalnego.

DNS sprawdzony z własnego komputera, więc “u wszystkich jest tak samo”. Nie jest. DNS potrafi wyglądać różnie zależnie od operatora i lokalizacji, zwłaszcza tuż po zmianie rekordu. dig @8.8.8.8 daje wynik pewniejszy i niezależny od Twojego cache.

Pomijanie logu błędów proxy. nginx -t sprawdza tylko składnię, nie to, czy backend odpowiada. Prawdziwą przyczynę prawie zawsze widać dopiero w error.log.