Когда сайт или внешний сервис недоступен с VPS, проверяйте уровни последовательно: адрес и маршрут, DNS, затем TCP/TLS и ответ приложения. Это помогает не менять firewall или DNS-сервер вслепую.

1. Проверьте адрес и маршрут

ip -br address
ip route
ip -6 route

У интерфейса должен быть ожидаемый адрес, а у нужного семейства IP — подходящий маршрут. Наличие IPv4 не подтверждает работоспособность IPv6. Не копируйте шлюз с другого сервера: параметры маршрутизации задаёт провайдер.

Для конкретного разрешённого узла, адрес которого вы знаете, используйте ip route get АДРЕС. Команда покажет выбранный интерфейс и исходный IP, не изменяя маршруты.

2. Отделите DNS от соединения

Замените service.example.com своим проверяемым доменом:

getent ahosts service.example.com

Отсутствие результата требует проверки имени, резолвера и доступности DNS. Сравните возвращённый адрес с ожидаемым. Не подменяйте /etc/resolv.conf первым публичным резолвером: файл может управляться systemd-resolved или сетью хостера, а сервис зависеть от приватной зоны.

3. Проверьте путь небольшим числом пакетов

ping -c 4 service.example.com
sudo apt update
sudo apt install mtr-tiny
mtr --report --report-cycles 10 service.example.com

Ping может быть запрещён, хотя HTTPS работает. В mtr отсутствие ответа промежуточного маршрутизатора или потери только на нём могут означать ограничение служебных ICMP-ответов. Ищите устойчивое ухудшение, доходящее до конечного узла, и повторяйте замер в момент проблемы.

Если целевой сервис использует TCP/443 и диагностика разрешена, сравните TCP-маршрут:

sudo mtr --tcp --port 443 --report --report-cycles 10 service.example.com

4. Проверьте HTTPS без отключения TLS

curl -4 -I --connect-timeout 5 --max-time 15 https://service.example.com/
curl -6 -I --connect-timeout 5 --max-time 15 https://service.example.com/

Сравнение -4 и -6 полезно только для домена с соответствующими DNS-записями и сервера с настроенным протоколом. Не добавляйте -k: ошибка сертификата — отдельный диагностический результат. Ответ 403 или 500 обычно означает, что соединение состоялось, но приложение или промежуточный прокси отказал.

Некоторые приложения не поддерживают HEAD. При ответе 405 повторите ограниченный обычный GET с выводом в /dev/null, сохранив код ответа. Не проверяйте тяжёлую выгрузку вместо простой страницы.

Что отправить в поддержку

Укажите точное время и часовой пояс, исходный и целевой адреса, порт, длительность проблемы и краткий вывод команд. Удалите токены, cookie, пароли и приватные заголовки. Не публикуйте полный curl -v с авторизацией. Эта проверка ничего не исправляет автоматически — изменения делайте только после локализации причины.

Связанные инструкции

Официальные источники