Linux - Diagnostyka sieci krok po kroku (ip, dig, ss, ssh)

W pracy z serwerami liczy się nie ilość narzędzi, tylko kilka poleceń, które naprawdę skracają drogę do diagnozy. Ten materiał porządkuje komendy Linux używane przy diagnostyce sieci, obsłudze serwerów i codziennej administracji. Pokazuję je tak, jak używa się ich w praktyce, a nie w oderwaniu od realnego problemu.

Jakie polecenia warto znać na start

Nie próbuję zapamiętać wszystkiego naraz. W sieciach i na serwerach naprawdę liczy się mały zestaw narzędzi, które razem dają pełny obraz sytuacji: od interfejsu, przez trasę i DNS, po porty, usługi i logi. Właśnie dlatego zaczynam od kilku sprawdzonych poleceń, które w 80 procentach przypadków prowadzą do źródła problemu szybciej niż przypadkowe klikanie.

Starsze materiały często pokazują ifconfig i netstat, ale dziś w praktyce opieram się na ip i ss. Są czytelniejsze, bliższe temu, jak Linux naprawdę opisuje sieć, i lepiej skalują się do pracy na serwerach z wieloma interfejsami oraz kontenerami.

Gdy nie pamiętam składni

Nie zgaduję. Najpierw sprawdzam man ip, man ss albo polecenie --help, bo składnia różni się między narzędziami i dystrybucjami. To drobiazg, ale właśnie on oszczędza najwięcej czasu, gdy wraca się do serwera po kilku tygodniach.

To właśnie ten zestaw najczęściej prowadzi mnie dalej do diagnozy, bo dopiero po nim widać, czy kłopot leży w adresacji, usłudze, DNS czy samym łączu.

Jak diagnozować sieć bez zgadywania

W praktyce idę po warstwach. Najpierw sprawdzam, czy system widzi interfejs i ma poprawną trasę. Potem weryfikuję DNS, łączność z hostem i port, a dopiero na końcu przyglądam się samej aplikacji. Taka kolejność nie jest teoretyczna, tylko oszczędza czas, bo eliminuje fałszywe tropy już na starcie.

1. Interfejs i adres.
2. Trasa i brama domyślna.
3. DNS i dostępność hosta.
4. Port i odpowiedź aplikacji.
5. Logi usługi, jeśli wcześniejsze kroki wyglądają poprawnie.

Najpierw interfejs i trasa

Jeśli serwer nie ma poprawnego adresu albo bramy, dalsze testy są tylko szumem. Ja zaczynam od sprawdzenia, czy karta sieciowa jest aktywna, jaki adres dostała i którędy ma wychodzić ruch. To podstawowy filtr, który od razu pokazuje, czy problem jest lokalny, czy dopiero „za” maszyną.

ip link show
ip addr show
ip route

`ip addr show` mówi mi, jakie adresy są przypisane do interfejsów, a `ip route` ujawnia, czy system zna domyślną trasę. Jeśli nie widzę tu nic sensownego, nie ma sensu jeszcze sprawdzać aplikacji webowej, bo sama sieć nie jest gotowa.

Potem DNS i dostępność hosta

Gdy sieć wygląda poprawnie, przechodzę do DNS i prostego testu zasięgu. `ping` odpowiada na jedno pytanie: czy host jest osiągalny. `tracepath` pokazuje, którędy idą pakiety i gdzie po drodze pojawia się blokada. W wielu sytuacjach wybieram właśnie `tracepath`, bo nie wymaga uprawnień superużytkownika i jest wystarczająco szybki do codziennej diagnostyki.

ping -c 4 serwer
tracepath serwer
dig nazwa-domeny

`ping` nie testuje usługi. Sprawdza tylko, czy host odpowiada na ICMP. Jeśli ping działa, a strona nadal nie otwiera się poprawnie, problem może siedzieć w porcie, firewallu albo samej aplikacji. `dig` z kolei szybko ujawnia, czy domena wskazuje tam, gdzie powinna, i czy lokalny resolver nie podaje błędnej odpowiedzi.

Przeczytaj również: TTFB test - Jak skrócić czas do pierwszego bajtu?

Na końcu port i odpowiedź aplikacji

Jeżeli host żyje, ale usługa nie odpowiada, sprawdzam port nasłuchu. `ss -tulpn` pokazuje, czy proces rzeczywiście słucha na porcie, a `nc -vz` potrafi szybko potwierdzić, czy połączenie TCP w ogóle dochodzi do celu. To jest moment, w którym najłatwiej odróżnić błąd aplikacji od problemu sieciowego.

ss -tulpn
nc -vz serwer 443

W przypadku stron i API dodatkowo sięgam po curl -I, żeby zobaczyć odpowiedź HTTP bez pobierania całej treści. Przy serwerach WWW to jeden z najprostszych testów, a jednocześnie bardzo skuteczny, bo pokazuje status, nagłówki i to, czy reverse proxy faktycznie przepuszcza ruch.

Kiedy ten etap mam za sobą, zwykle wiem już, czy problem wynika z sieci, DNS, portu, czy z samej aplikacji. Jeśli dalej coś nie gra, wtedy nie zgaduję, tylko przechodzę do usług i logów.

Jak obsługiwać usługi i logi na serwerze

Gdy sieć już odpowiada, nie ma sensu dalej gapić się w trasę pakietu. Wtedy sprawdzam usługę, jej stan i logi. Na serwerach z systemd to najkrótsza droga do odpowiedzi, bo systemctl pokazuje status jednostki, a journalctl daje kontekst błędu. W praktyce właśnie tutaj wychodzi większość awarii aplikacyjnych.

systemctl status nginx
systemctl restart nginx
systemctl enable --now nginx
journalctl -u nginx -f

`status` mówi mi, czy usługa działa i jak zakończyła się ostatnia próba uruchomienia. `restart` stosuję po zmianach konfiguracji, ale jeśli usługa wspiera przeładowanie, wolę reload, bo nie przerywa pracy bardziej niż trzeba. enable --now łączy uruchomienie z autostartem, więc nie muszę pamiętać o dwóch oddzielnych krokach.

Najbardziej praktyczne jest jednak logowanie. Jeśli usługa startuje i natychmiast wpada w błąd, nie kombinuję dalej z portami, tylko od razu czytam journalctl -u nazwa-uslugi. Gdy problem jest świeży, dodaję -f, żeby obserwować logi na żywo i zobaczyć moment, w którym system się wysypuje. Po ręcznej edycji plików jednostek przydaje się też systemctl daemon-reload, bo bez tego systemd nie zawsze zauważy zmianę.

Jeśli wszystko wygląda poprawnie, a usługa nadal nie działa, często winny jest nie sam demon, tylko zapora, uprawnienia albo zła konfiguracja reverse proxy. Do takiego scenariusza najlepiej przygotować się wcześniej, bo wtedy zdalna praca i transfer plików robią największą różnicę.

Jak łączyć się zdalnie i przenosić pliki

W administracji serwerami nie chodzi tylko o diagnozę, ale też o wygodną pracę na odległość. Najczęściej korzystam z SSH, a do przenoszenia danych używam scp albo rsync. Różnica jest istotna: scp sprawdza się przy jednorazowym kopiowaniu, natomiast rsync wygrywa tam, gdzie liczy się synchronizacja, powtarzalność i backup.

ssh uzytkownik@serwer
ssh -L 8080:localhost:80 uzytkownik@serwer
rsync -avz katalog/ uzytkownik@serwer:/backup/

Jeśli łączę się częściej niż raz, ustawiam klucz SSH zamiast opierać się wyłącznie na haśle. To nie jest ozdobnik, tylko praktyka, która oszczędza czas i zmniejsza ryzyko pomyłek przy wielu serwerach. Przy rsync zwracam też uwagę na opcję --delete i używam jej tylko wtedy, gdy naprawdę chcę mieć lustrzaną kopię, a nie zwykły transfer.

Na stronach internetowych i serwerach aplikacyjnych właśnie ten zestaw daje największą kontrolę: mogę wejść na maszynę, sprawdzić usługę, podejrzeć logi i przenieść poprawiony plik bez ręcznego klikania w panel hostingu. Zanim jednak człowiek zacznie działać szybciej, dobrze jest uniknąć kilku błędów, które regularnie fałszują obraz sytuacji.

Najczęstsze błędy, które fałszują diagnozę

• Mylę host z usługą. Ping działa, ale port 443 nadal jest zamknięty, więc problem nie leży w tym samym miejscu.
• Sprawdzam DNS za późno. Zły rekord albo lokalny resolver potrafi udawać awarię sieci.
• Ignoruję firewall. Usługa może działać poprawnie, a i tak nikt z zewnątrz się do niej nie dostanie.
• Używam jednego testu jako wyroku. Jeden udany ping nie znaczy, że wszystko jest stabilne.
• Nie używam odpowiednich uprawnień. Bez sudo część informacji bywa ukryta albo ucięta.
• Trzymam się starych narzędzi z przyzwyczajenia. ifconfig i netstat nadal się zdarzają, ale w nowych środowiskach lepiej opierać się na ip i ss.

Ja trzymam się prostego porządku: najpierw warstwa sieci, potem DNS, potem port, potem usługa, na końcu logi. Taki schemat jest mniej efektowny niż szybki restart wszystkiego, ale za to znacznie skuteczniej prowadzi do rzeczywistej przyczyny problemu.

Zestaw, od którego zacząłbym na każdym serwerze

Gdybym miał zostawić tylko kilka poleceń na czarną godzinę, wybrałbym właśnie te. Nie są efektowne, ale w praktyce prowadzą od objawu do przyczyny szybciej niż większość „uniwersalnych” porad. To też dobry zestaw dla osób, które ogarniają hosting strony, aplikację webową albo serwer VPS i chcą działać pewniej, bez przypadkowych prób.

• ip addr show i ip route do sprawdzania adresacji oraz trasy.
• ss -tulpn do weryfikacji portów nasłuchu.
• ping, tracepath i dig do szybkiej diagnostyki sieci oraz DNS.
• curl -I do sprawdzania odpowiedzi HTTP na stronach i API.
• systemctl status oraz journalctl -u do kontroli usług i logów.
• ssh i rsync do wygodnej pracy zdalnej oraz kopii danych.

Jeśli mam dołożyć jeszcze jedną zasadę, to brzmi ona prosto: nie zgaduję, tylko zawężam problem warstwa po warstwie. Właśnie dlatego te polecenia są tak użyteczne w sieciach i na serwerach, a szczególnie wtedy, gdy liczy się szybka reakcja bez psucia działającej konfiguracji.