Проверить доступность сервиса без браузера проще всего тремя инструментами: 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-порту или в сетевом доступе.
А если curl -I< возвращает 200, а nc -vz к этому же порту иногда падает, с чего вы бы начали поиск — с firewall, балансировщика или самого сервиса?
Я бы сначала посмотрел на сам сервис и балансировщик: если
curl -Iотдаёт 200, аnc -vzиногда не проходит, это уже похоже либо на нестабильность на стороне приложения, либо на проблему между балансировщиком и бэкендом. Firewall тоже проверил бы, но обычно не первым делом.[…] Как проверить доступность сервиса без браузера: curl, nc и… […]
[…] Как проверить доступность сервиса без браузера: curl, nc и… […]