Прямой ответ
«Сервис недоступен» разбирается послойно, снизу вверх, и каждый слой — одна команда: DNS — dig +short host (резолвится ли вообще, в тот ли IP — DNS-механика); доступность хоста — ping host (но: ICMP часто заблокирован — пинг не проходит ≠ хост мёртв); маршрут — mtr host/traceroute (где теряются пакеты — свой дата-центр, транзит, последний хоп); порт — nc -zv host 443 или curl -v telnet://host:443 (слушает ли сервис — пинг живой при закрытом порте — норма для фаерволов); локальная сторона — ss -tlnp (а наш ли сервис вообще слушает там, где ждём); TLS/HTTP — curl -vI и openssl s_client(рукопожатие, сертификат, код ответа — [TLS-статья](./https-i-tls-rukopozhatie-prostymi-slovami.md)). Правило, экономящее часы: **менять по одному фактору и фиксировать, что показала каждая команда** — «то работает, то нет» почти всегда про конкретный слой (DNS-кеш, фаервол по источнику, балансировщик), а диагностика «перезапущу-ка всё» слой не показывает.curl -v` — самая информативная одна команда: в одном выводе — резолвинг, соединение, TLS, заголовки и ответ.
Слои 1–2: DNS и хост
DNS: dig +short example.com — пустой ответ/NXDOMAIN — записи нет или резолвер врёт (проверить dig @1.1.1.1 +short — прямой запрос к публичному резолверу: расхождение — локальный кеш/фильтр); несколько IP — round-robin (проверять каждый: curl --resolve host:443:IP1 ... — «половина запросов падает» = один из адресов мёртв); AAAA-запись при неработающем IPv6 — клиент уходит в v6 и висит до таймаута (curl -4 подтверждает диагноз). Хост/маршрут: ping -c 10 host — потери и RTT (стабильные 100% — хост не отвечает на ICMP или мёртв; плавающие 10–30% — проблема в пути, не в хосте); mtr -rwzbc 50 host — трассировка с потерями по каждому хопу: потери, начинающиеся с какого-то хопа и продолжающиеся до конца — проблема там; потери только в середине при чистом последнем хопе — маршрутизатор не отвечает на TTL-exceeded (норма, не неисправность); traceroute -T -p 443 — трассировка именно TCP-портом (ICMP-маршрут может отличаться от боевого — фаерволы фильтруют по протоколу).
Слой 3–4: порт и локальная проверка
Порт — граница «сеть vs приложение»: nc -zv host 443 — connected/refused/timeout, три разных диагноза: refused — хост жив, порт закрыт (ничего не слушает или reject-правило — на чужом сервере их различить снаружи трудно); timeout — пакеты дропаются (фаервол DROP — файрволы, облачная security group, порт не открыт) — самый частый случай «висит и не подключается»; connected — транспорт в порядке, проблема выше (TLS/HTTP/приложение). Локальная сторона (когда «недоступен» — наш сервер): ss -tlnp — процесс слушает? на 0.0.0.0 или 127.0.0.1 (слушание на loopback — снаружи недоступно по построению — половина «сервер не отвечает извне» при живом сервисе); ss -s — сводка (тысячи TIME_WAIT/CLOSE-WAIT — признак исчерпания/бага приложения); ip a/ip r — адрес и маршрут на месте. Изнутри наружу: curl -v localhost:8080 работает, а снаружи — нет: слой между — фаервол хоста, security group, NAT.
Слой 5+: TLS и HTTP глазами curl -v
curl -vI — полная лента событий: * Trying 203.0.113.5:443(резолвинг и адрес — какой IP выбран),* Connected to(TCP-соединение — до этой строки проблемы сетевые),* TLS handshakeи сертификат (subject/issuer/dates — просрочка и hostname видны сразу),> GETи< HTTP/2 200(прикладной уровень). Чтения по симптомам: зависание послеTrying— порт дропается;Connection refused— не слушает; TLS-ошибки — [каталог в TLS-статье](./https-i-tls-rukopozhatie-prostymi-slovami.md);HTTP 502/504— прокси жив, backend мёртв/тормозит (граница «nginx vs приложение»);HTTP 429— [лимиты](./rate-limiting-i-zashchita-api-ot-zloupotrebleniy.md). Тайминги одной командой:curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' — где именно медленно (dns/connect/tls/ttfb) видно числами без гаданий; -w — недооценённый инструмент быстрой перф-диагностики. Для API-отладки: curl -v + точное воспроизведение запроса клиента (заголовки, тело) — «у Postman работает» часто про различие запросов, а не про сеть.
Практический сценарий: «API партнёра недоступен» в четыре слоя
Алерт: интеграция получает таймауты к api.partner.com с 10:15. Разбор: (1) dig +short api.partner.com → два IP, оба те же, что вчера — DNS в порядке; (2) mtr -T -P 443 -rwzbc 30 до первого — чисто; до второго — 100% потерь с восьмого хопа (транзит партнёра) — диагноз сужен: половина адресов мертва, round-robin рандомно кидает на мёртвый; (3) `curl -v --resolve api.partner.com:443:IP1 → 200 за 80 мс — живой адрес подтверждён; (4) временная мера: пин IP1 в hosts-файле/конфиге клиента + тикет партнёру с трассировкой (доказательство — их сторона, их фикс); (5) постоянная: retry с переключением адресов в HTTP-клиенте (список адресов резолвится, первый таймаут — следующий — httpx-настройка): инцидент партнёра больше не роняет интеграцию. Время разбора — 10 минут, потому что каждый слой проверялся отдельно и результат фиксировался: «попробовали пинг — не пингуется — перезапустили сервис» дало бы те же таймауты через час.
FAQ
ping проходит, а сайт не открывается (и наоборот) — как так? Разные протоколы: ICMP (ping) и TCP 443 фильтруются независимо — фаервол может пропускать одно и дропать другое; обратный случай (пинг есть, HTTP нет) — слушает не тот сервис/порт. Пинг — проверка «хост отвечает», не «сервис работает».
traceroute показывает звёздочки — это поломка? Часто нет: промежуточные маршрутизаторы не отвечают на probe-пакеты (rate-limit ICMP) при исправной передаче трафика; диагноз — по конечному хопу и сквозной проверке (curl до сервиса), а не по середине трассы.
Почему из контейнера сеть работает иначе? Свой сетевой стек namespace: свой DNS (resolv.conf от Docker — сети контейнеров), NAT наружу, MTU моста (большие пакеты теряются — «мелкие запросы работают, большие висят» — MTU-классика); диагностика — изнутри контейнера теми же командами, сравнение с хостом.
Что смотреть при «то работает, то нет»?
Интермиттентность почти всегда про один из: round-robin с одним мёртвым адресом (проверка каждого IP), перегруженный балансировщик/backend (тайминги -w в серии запросов), DNS-кеш с разными ответами, фаервол с лимитом (срабатывает после N запросов). Серия из 20 curl -w total показывает распределение, единичная проверка — нет.
Источники: man traceroute/ss, документация curl — ссылки в шапке.