Как проверить доступность сервиса без браузера: curl, nc и ss

Проверить доступность сервиса без браузера проще всего тремя инструментами: curl, nc и ss. Браузер в такой проверке часто мешает: кэширует ответ, автоматически переходит по редиректам, прячет часть сетевых ошибок и не показывает, что происходит на уровне TCP.

Нормальная диагностика идёт по цепочке: сначала проверяем HTTP-ответ через curl, потом сам TCP-порт через nc, затем на сервере смотрим, слушает ли процесс нужный адрес и порт через ss. Если на одном шаге всё ломается, следующий шаг обычно уже понятен.

Быстрая схема проверки

Если нужно быстро понять, жив ли сервис, начните с этих команд. Они не чинят проблему, зато быстро отделяют ошибку приложения от сетевой ошибки.

curl -I https://example.com
nc -vz example.com 443
ss -ltnp | grep ':443' 

• curl показывает, отвечает ли HTTP или HTTPS сервис и какой код он отдаёт.
• nc проверяет, открывается ли TCP-соединение к порту.
• ss показывает локальные слушающие порты на сервере.

Проверка HTTP через curl

Для сайта, API или веб-панели начинайте с curl. Самая короткая проверка заголовков выглядит так:

curl -I https://example.com

В норме вы увидите строку ответа вроде HTTP/2 200, HTTP/1.1 301 или HTTP/1.1 403. Это уже ответ приложения или веб-сервера. Значит, TCP-соединение установилось, TLS как минимум начал работать, а запрос дошёл до сервиса.

Если нужен только код ответа, удобно использовать тихий режим:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com

Для диагностики редиректов добавьте -L, но сначала лучше посмотреть исходный ответ без перехода. Так проще заметить неправильный Location, циклический редирект или уход на старый домен.

curl -I https://example.com
curl -IL https://example.com

Если есть подозрение на проблему с DNS или виртуальным хостом, можно принудительно указать IP для имени. Это полезно после миграции сайта, смены nginx-конфига или проверки нового сервера до обновления DNS.

curl -I --resolve example.com:443:203.0.113.10 https://example.com

Что означают частые ошибки curl

• Connection refused — порт доступен по сети, но на нём никто не слушает или сервис сразу отвергает соединение.
• Connection timed out — до порта не удаётся достучаться. Часто это firewall, маршрутизация, закрытый security group или сервис слушает только внутренний адрес.
• Could not resolve host — проблема с DNS-именем.
• SSL certificate problem — соединение дошло до HTTPS, но сертификат не прошёл проверку.
• Empty reply from server — TCP-соединение было, но приложение закрыло его без HTTP-ответа.

Для подробного разбора включите verbose-режим. Он показывает DNS, попытку подключения, TLS и заголовки запроса.

curl -v https://example.com

Проверка TCP-порта через nc

Если curl не помогает или сервис не HTTP, проверяйте порт через nc. Например, так можно проверить HTTPS, PostgreSQL, Redis, SMTP или любой другой TCP-сервис.

nc -vz example.com 443
nc -vz 192.0.2.15 5432
nc -vz redis.internal 6379

Флаг -z включает режим проверки без отправки данных. Флаг -v печатает результат. Если соединение успешно, порт открыт с точки зрения текущей машины.

Важно: открытый TCP-порт не означает, что приложение работает правильно. Например, nginx может принимать соединение на 443, но отдавать 502 из-за недоступного backend. Поэтому nc отвечает только на вопрос «можно ли подключиться к порту».

Ручная проверка HTTP через nc

Иногда полезно отправить HTTP-запрос руками. Это грубый способ, но он хорошо показывает, принимает ли сервер обычный текстовый запрос на порту 80.

printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | nc example.com 80

Для HTTPS так обычно не проверяют, потому что поверх TCP нужен TLS. Для HTTPS используйте curl -v или openssl s_client, если нужно смотреть сертификаты и TLS-рукопожатие.

Проверка слушающего порта через ss

Команды curl и nc удобно запускать с клиента. На самом сервере первым делом проверьте, слушает ли сервис нужный порт. Для этого используйте ss.

ss -ltnp | grep ':443'

Расшифровка простая:

• -l — показать слушающие сокеты.
• -t — только TCP.
• -n — не преобразовывать порты и адреса в имена.
• -p — показать процесс, если хватает прав.

Обратите внимание на адрес, на котором слушает сервис. Это частая причина «на сервере работает, снаружи не открывается».

ss -ltnp | grep ':8080'
# 127.0.0.1:8080  — доступно только локально
# 0.0.0.0:8080    — слушает на всех IPv4-адресах
# [::]:8080       — слушает на IPv6, поведение зависит от настроек системы

Если сервис слушает только 127.0.0.1, извне он не откроется. Это нормально для backend-приложений за nginx, но плохо для сервиса, который должен принимать подключения напрямую.

Проверка снаружи и изнутри

Проверяйте доступность минимум из двух точек: с самого сервера и с внешней машины. Так быстрее понять, проблема внутри приложения или на пути к нему.

# На сервере
curl -I http://127.0.0.1:8080
ss -ltnp | grep ':8080'

# С другой машины
curl -I http://203.0.113.10:8080
nc -vz 203.0.113.10 8080

Если локально работает, а снаружи нет, смотрите firewall, NAT, security group, провайдера и bind-адрес сервиса. Если не работает даже локально, начинайте с процесса и логов приложения.

Мини-чеклист

• Есть HTTP-ответ через curl -I — смотрите код ответа, редиректы и заголовки.
• curl молчит или падает по таймауту — проверьте TCP-порт через nc -vz.
• nc не подключается — на сервере проверьте ss -ltnp.
• Порт слушает только 127.0.0.1 — снаружи он не обязан открываться.
• Порт слушает 0.0.0.0, но извне таймаут — ищите firewall или маршрутизацию.

Справка по командам

Для деталей по параметрам можно открыть официальную документацию curl и справочную страницу Linux по ss. Эти ссылки полезны, когда нужно проверить редкий флаг или поведение конкретной версии утилиты.

Коротко

Для веб-сервиса начинайте с curl -I. Если HTTP не отвечает, проверяйте порт через nc -vz. Если порт не открывается, заходите на сервер и смотрите ss -ltnp. Такая цепочка быстро показывает, где сбой: в приложении, на TCP-порту или в сетевом доступе.

Похожие материалы

• Ping проходит, а TCP timeout: как понять, где ломается соединение
• Диагностика TCP-соединений в Linux
• Таблица сетевых масок IPv4: CIDR, маска и количество адресов