Коли сервер недоступний або працює повільно — потрібно знати, де шукати проблему. Ось повний арсенал команд для діагностики мережі на VPS.

1. ping — базова перевірка доступності

# Перевірити доступність хоста
ping google.com

# IPv6 ping
ping6 google.com

# Надіслати 5 пакетів і зупинити
ping -c 5 8.8.8.8

# Пінг з розміром пакета 1400 байт (перевірка MTU)
ping -s 1400 -c 3 google.com

2. traceroute / tracepath — маршрут пакетів

# Стандартний traceroute
traceroute google.com

# Використати ICMP (як ping)
traceroute -I google.com

# Traceroute по IPv6
traceroute6 google.com

# tracepath — без прав root
tracepath google.com

3. mtr — найкращий інструмент для діагностики втрат

# Встановлення
sudo apt install mtr -y

# Інтерактивний режим (оновлюється в реальному часі)
mtr google.com

# Звіт на одну сторінку (зручно для тікетів у підтримку)
mtr --report google.com

# 100 пакетів, тільки числа
mtr -r -c 100 -n google.com

4. ss і netstat — відкриті порти та з'єднання

# Усі відкриті TCP-порти (що слухають)
ss -tlnp

# Усі з'єднання (TCP + UDP)
ss -tunap

# Застарілий netstat (аналог)
netstat -tlnp

# Подивитися хто слухає порт 80
ss -tlnp | grep :80
# або
lsof -i :80

5. nmap — сканування портів

# Встановлення
sudo apt install nmap -y

# Сканувати свої відкриті порти
sudo nmap -sS -O localhost

# Перевірити доступність порту на віддаленому хості
nmap -p 80,443,22 192.168.1.1

# UDP-сканування
sudo nmap -sU -p 53,123 google.com

6. tcpdump — перехоплення пакетів

# Весь трафік на інтерфейсі eth0
sudo tcpdump -i eth0

# Тільки HTTP-трафік на порту 80
sudo tcpdump -i eth0 port 80

# Трафік від конкретної IP
sudo tcpdump -i eth0 src 192.168.1.100

# Зберегти у файл для аналізу у Wireshark
sudo tcpdump -i eth0 -w /tmp/capture.pcap

Шпаргалка: що коли використовувати

Проблема	Інструмент
Сайт недоступний	ping → traceroute → mtr
Порт не слухає	ss -tlnp, lsof -i
Пакети губляться	mtr --report google.com
Потрібно знати маршрут	traceroute / ip route
Відкриті порти сервера	nmap localhost
Налагодження конкретного сервісу	tcpdump port N

💡 mtr для підтримки: Коли пишете тікет про проблеми з мережею — завжди додавайте вивід mtr --report google.com і mtr --report YOUR_SERVER_IP (обидві сторони). Це дає повну картину.

Типові помилки і що вони означають

Повідомлення	Причина
ping: connect: Network is unreachable	На сервері немає маршруту за замовчуванням — зазвичай після ручного редагування таблиці маршрутизації або збою DHCP на інтерфейсі
traceroute: command not found	Пакет traceroute не входить у мінімальний образ Debian/Ubuntu за замовчуванням — потрібно встановити його окремо
bind: Address already in use	Порт уже зайнятий іншим процесом; який саме — покаже `ss -tlnp \| grep :PORT`, а не nmap
tcpdump: You don't have permission to capture on that device	Команда запущена без sudo — захоплення пакетів вимагає прав CAP_NET_RAW, звичайного користувача недостатньо
nmap зсередини показує порт відкритим, а ззовні — закритим	Файрвол (ufw/iptables) блокує вхідні з'єднання ззовні, але дозволяє трафік з localhost — типова плутанина під час самодіагностики
mtr показує 100% loss лише на одному з проміжних хопів	Багато роутерів провайдера навмисно депріоритизують ICMP на транзитних вузлах — це не реальна втрата пакетів, орієнтуйтеся на loss в останнього хопа (цілі)

Коли цих інструментів недостатньо

Потрібен безперервний моніторинг з історією та алертами, а не разовий знімок — ці команди дають зріз моменту, для історії потрібен окремий сервіс на кшталт Zabbix або Prometheus
Проблема на рівні застосунку, а не мережі (повільний SQL-запит, витік пам'яті) — мережеві утиліти покажуть зв'язність і відкритий порт, але не причину затримки всередині бекенда
Потрібно змістовно аналізувати зашифрований TLS-трафік — tcpdump перехопить пакети, але без приватного ключа сервера вміст HTTPS так і залишиться зашифрованим
Діагностика потрібна для мережі клієнта, а не сервера — з сервера видно лише його бік маршруту, а проблема часто лежить у мережі провайдера самого клієнта

Збираємо діагностику в один звіт

Для тікета в підтримку зручніше додати один файл з усіма результатами одразу, а не переказувати симптоми словами. Постійний моніторинг замість разових знімків розбирають статті про Netdata і про звʼязку Grafana та Prometheus.

# Зібрати базову діагностику в один файл однією командою
{
  echo "--- ping ---"; ping -c 4 8.8.8.8
  echo "--- route ---"; ip route show
  echo "--- listening ports ---"; ss -tlnp
  echo "--- mtr ---"; mtr --report -c 20 8.8.8.8
} > /tmp/netdiag-$(date +%Y%m%d-%H%M).txt