Теория из прошлого урока — это фундамент. IP, порты, протоколы — всё красиво. Но когда сайт не открывается, а начальство нервничает, вам нужны не определения, а инструменты. Конкретные команды, которые за секунды покажут: проблема в сети, в DNS, в сервере или в вашем приложении.

Сегодня — три таких инструмента. Они решают 80% задач сетевой диагностики, и вы будете использовать их каждый день. Первый вопрос, который нужно задать: а какой вообще IP у этой машины? Особенно актуально, когда вы подключились к серверу и хотите понять, где вы. Раньше для этого использовали ifconfig, но в современном Linux его заменил ip:

ip a

Это сокращение от ip addr show. Вывод будет выглядеть примерно так:

1: lo: <LOOPBACK,UP> mtu 65536
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500
    inet 192.168.1.42/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::1/64 scope link

Что здесь видно?

• lo — loopback-интерфейс. Это 127.0.0.1, localhost, «сам себе». Всегда есть, всегда работает.
• eth0 — сетевой интерфейс. 192.168.1.42 — ваш IP-адрес в локальной сети. /24 — маска подсети (означает, что первые три октета — адрес сети, последний — адрес машины).

На облачных серверах вы увидите публичный IP, на домашней машине — частный (192.168.x.x или 10.x.x.x). На серверах интерфейс может называться не eth0, а ens3, enp0s3 или даже ens192 — не пугайтесь, это просто разные схемы именования.

Ещё несколько полезных вариаций ip:

# Только IPv4-адреса (без лишнего шума)
ip -4 a

# Таблица маршрутизации (куда уходят пакеты)
ip route

# Шлюз по умолчанию (ваш роутер)
ip route | grep default
# default via 192.168.1.1 dev eth0

Последняя команда показывает шлюз по умолчанию — адрес роутера, через который ваша машина выходит в интернет. Если шлюза нет — в интернет вы не попадёте, даже если IP есть. Хорошо, IP у нас есть. А теперь главный вопрос сетевой диагностики: «Вообще, связь есть?» Для этого существует ping — самая простая и самая полезная сетевая команда в мире.

ping google.com

Вывод:

PING google.com (142.250.74.46) 56(84) bytes of data.
64 bytes from 142.250.74.46: icmp_seq=1 ttl=118 time=12.3 ms
64 bytes from 142.250.74.46: icmp_seq=2 ttl=118 time=11.8 ms
64 bytes from 142.250.74.46: icmp_seq=3 ttl=118 time=12.1 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Что произошло? Ваш компьютер отправил маленький пакет серверу Google, тот ответил. Туда-обратно — 12 миллисекунд. Это как крикнуть в пещеру и услышать эхо — если эхо вернулось, значит, пещера (сервер) существует и связь есть.

На Linux ping работает бесконечно, пока вы не нажмёте Ctrl+C. Если хотите ограничить количество пакетов:

# Отправить 4 пакета и остановиться
ping -c 4 google.com

Что нам говорит вывод ping?

А вот когда что-то не так:

# Сервер не отвечает (100% потерь)
ping -c 3 192.168.1.200
# 3 packets transmitted, 0 received, 100% packet loss

# Имя не резолвится (DNS не работает)
ping nonexistent.example.com
# ping: nonexistent.example.com: Name or service not known

Простое правило диагностики: ping 8.8.8.8 работает, а ping google.com нет? Значит, интернет есть, а DNS сломан. Оба не работают? Проблема глубже — сеть или маршрутизация. Оба работают, но сайт не открывается? Значит, проблема в конкретном сервере или порте.

И вот мы подошли к главному герою этого урока — curl. Если ping — это «ты живой?», то curl — это «дай мне вот эту страницу, пожалуйста». Он делает HTTP-запросы прямо из терминала — как браузер, только без картинок и кнопок.

curl https://example.com

В терминал вывалится HTML-код страницы. Не очень читаемо для человека, зато вы точно видите: сервер работает, отвечает, отдаёт контент. А если хочется видеть только заголовки ответа — без тела:

curl -I https://example.com

Вывод:

HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 1256
server: ECAcc (dcd/7D4B)
last-modified: Thu, 17 Oct 2019 07:18:26 GMT

HTTP/2 200 — сервер ответил, всё хорошо. Код 200 значит «OK». Если бы сайт не работал, вы бы увидели 500 (ошибка сервера), 502 (Bad Gateway), 404 (страница не найдена) и так далее.

Вот набор команд curl, который покрывает большинство ситуаций:

# Просто получить страницу
curl https://example.com

# Только заголовки (быстрая проверка «жив ли?»)
curl -I https://example.com

# Подробный вывод: весь процесс соединения
curl -v https://example.com

# Следовать за редиректами (301/302)
curl -L http://example.com

# Скачать файл
curl -O https://example.com/file.tar.gz

# Отправить POST-запрос с данными
curl -X POST -d '{"name":"alice"}' -H "Content-Type: application/json" https://api.example.com/users

# Таймаут — не ждать дольше 5 секунд
curl --connect-timeout 5 https://slow-server.com

Давайте разберём реальный сценарий диагностики. Коллега пишет: «Сайт лежит!» Что делаем?

# 1. Есть ли вообще интернет?
ping -c 2 8.8.8.8
# Если нет — проблема с сетью, дальше не идём

# 2. Работает ли DNS?
ping -c 2 example.com
# Если ping 8.8.8.8 работает, а ping example.com нет — DNS сломан

# 3. Отвечает ли веб-сервер?
curl -I https://example.com
# 200 — работает. 502 — сервер упал. Connection refused — сервис не запущен

# 4. Если curl молчит — проверяем, открыт ли порт
curl --connect-timeout 3 https://example.com
# Timeout — порт закрыт файрволом или сервер не слушает

Четыре команды — и вы знаете, где искать проблему. Не «сайт лежит, я не знаю что делать», а «DNS резолвит, пинг ходит, но curl получает 502 — значит, упал бэкенд, идём смотреть логи». Подведём итог. Три инструмента, три уровня диагностики:

• ip a — «Кто я? Какой у меня адрес?»
• ping — «Вижу ли я другую машину?»
• curl — «Отвечает ли конкретный сервис?»

Запомните эту тройку — она будет с вами всю карьеру. В следующем уроке разберём DNS: как браузер узнаёт, что google.com — это 142.250.74.46, и что делать, когда это знание теряется.