Comenzi de depanare a rețelei pe VPS Linux: repară problemele rapid

Dacă un VPS Linux „are problemă de rețea”, cea mai rapidă cale spre rezolvare este să nu mai ghicești și să verifici straturile în ordinea corectă: interfață, adresă IP, rută, vecini, DNS, socketuri, traseu, firewall, captură de pachete și abia după aceea stratul aplicației. Asta este diferența dintre o rezolvare în cinci minute și două ore irosite cu restarturi făcute la nervi pe servicii care, de fapt, erau sănătoase. Acest articol este foaia de triere completă pentru genul de probleme care apar în lumea reală: timeout-uri, pachete pierdute, porturi moarte, DNS stricat, IPv6 pe jumătate funcțional, TLS care pare blocat și servere care „merg”, dar nu răspund cum ar trebui.

Și da, articolul ăsta vinde planuri VPS. Corect. Pentru că exact genul ăsta de depanare serioasă devine posibil și eficient doar când chiar controlezi serverul: root SSH, firewall, rute, captură de pachete, IPv4, IPv6, proxy, tuneluri și porturi. Dacă ai depășit faza de shared hosting și ai ajuns să citești ghiduri ca acesta, ai depășit deja și limita mediilor care îți ascund infrastructura.

Ordinea corectă de triere

• Interfața este activă?
• VPS-ul are adresa IP corectă?
• Există ruta implicită corectă?
• Poate ajunge la gateway și la vecinii de rețea?
• DNS-ul rezolvă corect?
• Procesul care ar trebui să răspundă chiar ascultă pe portul potrivit?
• Traseul până la destinație arată normal?
• Firewall-ul permite exact ce crezi că permite?
• Captura de pachete confirmă că traficul chiar intră și iese?
• Aplicația răspunde, sau problema este deasupra TCP?

Ordinea asta contează. Prea mulți administratori sar direct la aplicație și ignoră complet stratul de rețea de dedesubt. Apoi declară serverul „lent” sau „defect” când cauza reală este o rută greșită, un DNS prost, un MTU nepotrivit sau un port pe care nu a ascultat nimic niciodată.

Blocul de triere în 60 de secunde

Dacă ai un minut înainte să înceapă tichetele și telefoanele, rulează mai întâi acest bloc:

hostname -f
ip -br a
ip -br link
ip route
ip route get 1.1.1.1
ss -tulpen
resolvectl status || cat /etc/resolv.conf
ping -c 3 1.1.1.1
ping -c 3 google.com
curl -4 -I --connect-timeout 5 http://example.com
journalctl -u systemd-networkd -u NetworkManager -u systemd-resolved -n 100 --no-pager 2>/dev/null

Blocul ăsta îți spune foarte repede dacă VPS-ul are adrese, dacă interfețele sunt sus, dacă există rută implicită, dacă ascultă ceva pe porturi, dacă merge conectivitatea IP brută, dacă DNS-ul rezolvă și dacă HTTP răspunde deloc. Te obligă să separi aproape imediat „rețeaua e moartă” de „aplicația e moartă”.

1. Interfața, adresa IP și starea legăturii

În Linux modern, comanda de bază pentru interfețe și adrese este ip, nu reflexul vechi cu ifconfig. Începe cu vederea scurtă:

ip -br a
ip -br link

Asta îți spune imediat ce interfețe există, care sunt active și ce adrese sunt atribuite. Când ai nevoie de mai mult context, mergi direct aici:

ip addr show dev eth0
ip -s link show dev eth0
ip -d link show dev eth0

Dacă vezi erori RX sau TX în creștere, dacă interfața este jos sau dacă dispozitivul are o stare suspectă, nu are sens să pierzi timp cu DNS, TLS sau logurile aplicației. Mai întâi repari realitatea de la nivelul legăturii.

Pentru informații despre placa de rețea și contoarele ei, mai ales pe medii KVM unde placa virtuală încă expune date utile, folosește:

ethtool eth0
ethtool -S eth0

Aici cauți lucruri evidente: lipsa legăturii, viteze negociate bizar sau contoare care sugerează că ceva se pierde sau se strică sub stratul aplicației.

2. Rutarea: dacă serverul nu știe pe unde să trimită traficul, restul nu mai contează

Verificările clasice de rutare rămân și cele mai utile:

ip route
ip route show table main
ip rule
ip route get 8.8.8.8
ip route get 203.0.113.20
ip route get 2001:4860:4860::8888

ip route get este una dintre cele mai bune unelte de triere pe un VPS Linux. Îți spune ce adresă sursă, ce interfață și ce gateway ar folosi Linux chiar acum pentru o destinație. Asta contează enorm când serverul are mai multe IP-uri, rutare pe politici, IP-uri suplimentare, tuneluri VPN, rețele Docker sau dual-stack cu IPv4 și IPv6.

Dacă vezi că traficul pleacă cu adresa sursă greșită, problema este deja locală. Nu da vina pe furnizorul upstream înainte să citești ieșirea acestei comenzi.

3. Vecinii de rețea și gateway-ul real

Dacă ruta arată corect, dar pachetele tot mor imediat, verifică tabelul de vecini:

ip neigh
ip neigh show dev eth0
ping -c 3 <gateway-ip>

Dacă gateway-ul nu se rezolvă, dacă vecinii rămân în stări de tip FAILED sau INCOMPLETE, sau dacă ping-ul către gateway nu primește nimic, nu ai o problemă de aplicație. Ai o problemă de conectivitate între server și prima verigă din rețea.

Pe segmente locale IPv4, arping este foarte util:

arping -I eth0 <gateway-ip>

Îți spune repede dacă relația locală există deloc la nivelul potrivit, mai ales când IP-ul pare „aproape viu”, dar ceva încă nu se leagă.

4. Socketuri și porturi: ascultă cineva sau nu?

Ridicol de multe „probleme de rețea” sunt, de fapt, probleme de tipul „nu ascultă nimic pe portul respectiv”. Aici intră în scenă ss:

ss -tulpen
ss -ltnp
ss -lunp
ss -pant
ss -s

Interpretarea practică este simplă:

• ss -ltnp pentru procese care ascultă pe TCP
• ss -lunp pentru procese care ascultă pe UDP
• ss -pant pentru sesiuni active, stări și PID-uri
• ss -s pentru un rezumat rapid când vrei doar să vezi starea generală

Dacă serviciul ar trebui să răspundă pe 443 și nu ascultă nimic pe 443, nu ai o enigmă de rețea. Ai o problemă de serviciu, configurație sau bind address.

Dacă procesul ascultă doar pe 127.0.0.1:8080 și tu te așteptai să fie expus public, ai din nou o problemă de configurare, nu una de rețea „misterioasă”.

5. DNS: separă rezolvarea greșită de lipsa conectivității

Mulți spun „rețeaua a căzut” când, de fapt, vor să spună „DNS-ul rezolvă prost”. Nu sunt aceeași problemă.

Începe cu starea resolverului local:

resolvectl status
resolvectl query example.com
resolvectl query google.com
cat /etc/resolv.conf

Dacă sistemul folosește systemd-resolved, resolvectl îți arată imaginea reală a resolverului activ. Apoi verifici direct lanțul DNS cu dig:

dig example.com A +short
dig example.com AAAA +short
dig example.com MX +short
dig -x 203.0.113.20 +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig +trace example.com

Aici răspunzi la întrebări concrete:

• Domeniul se rezolvă deloc?
• Se rezolvă diferit pe resolveri publici diferiți?
• Reverse DNS-ul este ceea ce crezi că este?
• Delegarea este stricată mai sus pe lanț?

dig +trace rămâne una dintre cele mai bune comenzi pentru cazurile în care DNS-ul este cu adevărat stricat și vrei să vezi lanțul autoritativ, nu doar ce ți-a răspuns un cache.

6. Conectivitate brută și pierderi: ping este simplu, dar nu naiv

ping rămâne cea mai rapidă dovadă de bază pentru accesibilitatea IP și pentru comportamentul pierderilor de pachete:

ping -c 5 1.1.1.1
ping -c 5 8.8.8.8
ping -c 5 google.com
ping -4 -c 5 google.com
ping -6 -c 5 google.com

Rulează-le în ordine. Mai întâi un IP brut, apoi un hostname. Asta separă imediat eșecul de transport de eșecul DNS. Apoi verifică IPv4 și IPv6 separat, pentru că foarte multe servere sunt „pe jumătate stricate” doar pe o familie de adrese.

Nu interpreta isteric o singură replică ICMP pierdută de la o gazdă publică aglomerată. Dar dacă pică gateway-ul, resolverul și destinația aplicației, ai destule dovezi că problema este reală.

7. Traseul și MTU: unde se rupe drumul

Când traficul iese din VPS, dar se comportă prost undeva pe traseu, treci la uneltele hop cu hop:

traceroute example.com
traceroute -T -p 443 example.com
tracepath example.com
mtr -rwzc 50 example.com

Rolurile lor sunt diferite:

• traceroute pentru traseul clasic
• traceroute -T -p 443 când te interesează mai mult drumul pentru TCP 443 decât sondele UDP implicite
• tracepath când suspectezi MTU și vrei un indiciu rapid fără privilegii speciale
• mtr când vrei latență și pierderi măsurate în timp, nu o singură fotografie

mtr este una dintre cele mai bune unelte pentru plângerile de tip „merge greu” pentru că îți arată dacă pierderea este locală, undeva pe traseu sau doar aparentă pe un router care deprioritizează ICMP.

Iar problemele de MTU sunt cât se poate de reale. Dacă HTTPS se blochează pe răspunsuri mari, dacă traficul prin VPN merge pentru pachete mici, dar se rupe pe cele mari, sau dacă unele negocieri TLS par înghețate, MTU intră imediat pe lista scurtă de suspecți.

8. HTTP, HTTPS și stratul aplicației: testează serviciul, nu doar rețeaua

După ce IP-ul, ruta și DNS-ul par sănătoase, urcă la marginea aplicației. Aici curl face diferența dintre „pare lent” și „știu exact unde se pierde timpul”.

curl -I http://example.com
curl -I https://example.com
curl -vk https://example.com
curl -4 -vk https://example.com
curl -6 -vk https://example.com
curl --connect-timeout 5 -m 15 -w '\ncode=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' -o /dev/null -s https://example.com

Aici separi foarte clar lucrurile:

• DNS-ul durează prea mult?
• Conectarea TCP merge repede, dar TLS se blochează?
• TLS se termină, dar aplicația întârzie primul byte?
• IPv6 pică în timp ce IPv4 merge?

Ultima comandă merită memorată. În câteva secunde îți spune dacă întârzierea este în rezolvarea numelui, în conectare, în handshake-ul TLS sau în răspunsul aplicației.

9. Firewall-ul: citește regulile reale, nu ce crezi că ai configurat

Pentru Linux modern, punctul de plecare ar trebui să fie nftables, nu presupuneri vagi despre „am deschis portul”.

nft list ruleset
nft list tables
nft -n list ruleset
nft monitor trace

Aici contează ordinea lanțurilor, politica implicită, NAT-ul și prioritățile. Dacă te bazezi pe memorie și nu citești efectiv regulile, depanezi orb.

Dacă folosești UFW, verifică și stratul lui explicit:

ufw status verbose
ufw app list

Dar regula rămâne aceeași: adevărul final este în ruleset, nu în intenția ta inițială.

10. Captura de pachete: linia dintre bănuială și dovadă

Când comenzile simple nu mai ajung, intră cu tcpdump. Aici se vede clar și de ce troubleshootingul serios cere un VPS adevărat.

tcpdump -ni eth0
tcpdump -ni eth0 host 203.0.113.20
tcpdump -ni eth0 port 443
tcpdump -ni eth0 'tcp port 443 and host 203.0.113.20'
tcpdump -ni any udp port 53
tcpdump -ni eth0 -w /root/capture.pcap

Aceste filtre răspund la întrebări foarte concrete:

• Ajung deloc pachetele SYN?
• Răspunsurile pleacă, dar nu se mai întorc?
• Cererile DNS ies, dar răspunsurile lipsesc?
• Se folosește interfața greșită?
• Firewall-ul oprește traficul înainte ca aplicația să-l vadă?

Dacă faci depanare serioasă pe Linux și nu ajungi uneori la captură de pachete, înseamnă că încă nu ai ajuns la incidentele care chiar contează.

11. Logurile de rețea: nu ignora ce îți spune sistemul

Nu totul se vede din comenzi interactive. Unele probleme sunt evidente în jurnal:

journalctl -u systemd-networkd -n 100 --no-pager
journalctl -u NetworkManager -n 100 --no-pager
journalctl -u systemd-resolved -n 100 --no-pager
dmesg | tail -n 100

Dacă interfața flapează, dacă DHCP-ul renegociază prost, dacă driverul rețelei raportează erori sau dacă resolverul local are probleme, aici apar indiciile clare.

12. Comenzi rapide pentru tipare reale de incident

SSH nu se conectează

ss -ltnp | grep ':22'
ip route
ping -c 3 <gateway-ip>
nft list ruleset
tcpdump -ni eth0 port 22

Verifici listenerul, ruta, gateway-ul, firewall-ul și dacă pachetele chiar ajung.

Website-ul dă timeout, dar ping merge

ss -ltnp | egrep ':80|:443'
curl -vk https://example.com
tcpdump -ni eth0 port 443
journalctl -u nginx -u apache2 -u httpd -n 100 --no-pager

Aici problema este aproape întotdeauna la port, TLS, proxy sau aplicație, nu în conectivitatea IP brută.

DNS rezolvă greșit sau inconsistent

resolvectl status
dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig +trace example.com

Aici separi problemele resolverului local, diferențele dintre cache-uri recursive și defectele de delegare autoritativă.

Un serviciu extern este lent doar din VPS

mtr -rwzc 50 remote.example.com
curl --connect-timeout 5 -m 20 -w '\nconnect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' -o /dev/null -s https://remote.example.com
traceroute -T -p 443 remote.example.com

Asta îți spune dacă durerea vine din traseu, din conectarea TCP, din TLS sau din răspunsul aplicației remote.

Există plângeri despre pierderi de pachete

ping -c 20 1.1.1.1
mtr -rwzc 100 1.1.1.1
ip -s link show dev eth0
ethtool -S eth0

Nu trage concluzii serioase dintr-un singur ping -c 4. Măsoară corect și citește contoarele interfeței.

IPv6 pare „ciudat”

ip -6 addr
ip -6 route
ping -6 -c 5 google.com
curl -6 -vk https://example.com
dig example.com AAAA +short

Foarte multe incidente „intermitente” sunt de fapt probleme izolate pe IPv6, în timp ce IPv4 merge normal.

13. Când problema nu este rețeaua hostului, ci rețeaua containerelor

Dacă pe VPS rulează Docker, foarte multe „probleme de rețea” sunt de fapt confuzii între bind-ul serviciului, rețeaua containerului și porturile publicate. Minim, verifică asta:

docker ps
docker network ls
docker network inspect bridge
ss -tulpen
ip route
tcpdump -ni any port 80 or port 443

Dacă aplicația ascultă în container, dar portul nu este publicat, dacă rețeaua bridge este ruptă sau dacă proxy-ul invers pointează spre adresa greșită, simptomele se vor vedea ca „rețea stricată”, deși problema este de orchestration și bind.

Pentru partea asta, citește și Gestionarea Docker și a containerelor pe un VPS: cele mai bune practici pentru stabilitate și performanță.

14. Când ghidul ăsta îți spune clar că ai nevoie de un VPS adevărat

Dacă troubleshootingul tău real implică tcpdump, nft list ruleset, ip rule, capturi live, teste pe IPv6, proxy-uri inverse, tuneluri VPN, rutare pe politici sau depanare de porturi și socketuri, ai depășit deja shared hostingul. Nu mai ești în zona în care „un panou simplu și niște clickuri” sunt suficiente. Ai nevoie de un server virtual pe care îl controlezi complet.

Aici articolul se leagă direct de serverele virtuale ServerSpan. Nu pentru că ar trebui să îți vindem orice cu orice preț, ci pentru că exact genul ăsta de diagnostic devine serios și reproductibil doar când ai SSH root, vizibilitate pe rute, acces la firewall, captură de pachete, IPv4, IPv6 și resurse pe care le controlezi tu.

15. Ce plan ServerSpan merită pentru genul ăsta de muncă

Dacă vrei doar să înveți și să rulezi laboratoare simple, vm.Entry la 4,99 EUR pe lună este suficient ca punct de plecare. Dacă vrei un VPS Linux util pentru website-uri reale, proxy-uri mici, teste VPN sau workloaduri obișnuite, vm.Ready la 9,99 EUR pe lună este pragul sănătos. Dacă administrezi servicii de producție și vrei spațiu pentru captură de pachete, mai multe servicii, monitorizare și depanare fără să lovești imediat limitele, vm.Steady la 17,99 EUR pe lună este alegerea care are cel mai mult sens pentru majoritatea oamenilor serioși. Dacă rulezi mai multe servicii, trafic mai mare sau un stack mai complex, vm.Go este pasul natural următor.

Motivul pentru care insistăm aici pe VPS-uri KVM este simplu: depanarea rețelei devine mult mai clară când ai control complet asupra sistemului, rețelei și resurselor. Nu mai stai să te întrebi dacă mediul îți ascunde ceva. Vezi direct ce se întâmplă.

16. Dacă nu vrei să fii omul care face toate aceste verificări la 2 dimineața

Atunci punctul corect de handoff nu este încă un plugin, încă un restart sau încă o speranță. Este administrarea Linux ServerSpan. Ghidul ăsta îți arată exact cât control, câtă răbdare și câtă disciplină cere troubleshootingul real. Unii oameni vor control total. Alții vor doar ca problema să dispară corect. Ambele sunt opțiuni legitime, dar a doua cere să lași pe altcineva să dețină incidentul până la capăt.

17. Lecturi conexe care se leagă perfect de ghidul ăsta

Dacă vrei partea de containere a aceleiași discipline, citește Gestionarea Docker și a containerelor pe un VPS: cele mai bune practici pentru stabilitate și performanță. Dacă vrei mentalitatea operațională din spatele plângerilor vagi de performanță, citește Realitatea tichetelor de tip „Serverul meu merge greu”. Și dacă tot confunzi presiunea de memorie cu probleme de rețea, du-te direct la Linux swap vs RAM: ghidul definitiv pentru gestionarea memoriei pe VPS.

Răspunsul practic

Cea mai rapidă cale de a repara rețeaua pe un VPS Linux nu este o comandă magică. Este o ordine disciplinată și un set de unelte corecte: ip pentru adrese și rute, ss pentru socketuri, ping pentru accesibilitate de bază, dig și resolvectl pentru DNS, traceroute, tracepath și mtr pentru analiză de traseu, curl pentru stratul aplicației, nft pentru adevărul din firewall și tcpdump atunci când ai nevoie de dovadă. Dacă nu ții minte altceva din articolul ăsta, ține minte ordinea de triere și încetează să sari direct la aplicație de fiecare dată când rețeaua pare suspectă.

Dacă încă încerci să faci genul ăsta de muncă pe un hosting care nu îți oferă root, captură de pachete, control pe firewall și vizibilitate asupra rutelor, îți sabotezi singur depanarea. Ia un VPS KVM adevărat sau lasă altcuiva responsabilitatea prin administrare Linux administrată. Ghidul ăsta este dovada că depanarea serioasă cere control serios.