Проследите один запрос от DNS до вашего приложения.

Запишите маршрут, который ожидаете

Это пошаговое руководство предполагает VPS с Linux, которым вы администрируете, работающий сеанс SSH, приложение с безвредной /healthz конечной точкой и доступ к авторитетным настройкам DNS для домена, которым вы управляете. Пример приложения слушает 127.0.0.1:3000; Caddy — публичный обратный прокси. Если ваше приложение использует другой супервизор или прокси, сохраните порядок диагностики и используйте его документацию.

api.example.com и 203.0.113.10 — это заполнители документации, а не живая служба. Замените оба перед выполнением проверок своей системы. Запишите настоящее имя хоста, предполагаемый IP-адрес, порт приложения и имя службы в одном месте. Установка имени хоста VPS в конфигураторе не создаёт публичную запись DNS.

1. DNS возвращает предполагаемый адрес.
2. Соединение достигает нужного сервера и порта.
3. TLS аутентифицирует запрошенное имя хоста.
4. Прокси пересылает запрос нужному upstream.
5. Приложение возвращает ожидаемый ответ.

Проверьте оба семейства адресов

С машины вне VPS запросите записи, которые собираетесь публиковать. dig относится к инструментам DNS от BIND; имена пакетов различаются. Эти команды запрашивают раздел ответа, чтобы вы увидели тип записи, адрес и оставшееся время кэширования. См. справку по BIND dig.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

Сравните каждый возвращённый адрес с предполагаемым назначением. Публикуйте запись AAAA только когда маршрутизация, прослушивание и фильтрация IPv6 работают для этого адреса. Старая запись AAAA может направить некоторых клиентов не туда, куда указывает запись A. Если вы намеренно используете CDN или DNS-прокси, его адреса могут быть правильными; зафиксируйте этот дополнительный переход вместо предположения, что должен появляться VPS.

Пустой ответ требует более внимательного изучения полного dig ответа: он может означать отсутствие записи такого типа, несуществующее имя или проблему разрешения. Проверьте, какая служба DNS является авторитетной, прежде чем редактировать. Запишите старое значение и TTL, внесите предполагаемое изменение там, затем сравните свежие результаты после истечения существующих кэшей. Повторяющиеся несвязанные правки затрудняют понимание хронологии.

Отделите сбои соединения от сбоев сертификата

Запросите небольшую конечную точку извне сервера. Используйте GET, а не предполагайте, что ваше приложение реализует HEAD. Параметры таймаута curl ограничивают проверку; его подробный вывод показывает ход соединения и TLS. Curl документирует эти параметры и проверку сертификатов.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

Ошибка разрешения указывает обратно на DNS. Отказ в соединении означает, что соединение было активно отклонено; таймаут может включать маршрутизацию или фильтрацию и не определяет, какой брандмауэр его вызвал. Ошибка сертификата означает, что ожидаемое защищённое соединение не было установлено. Не делайте отключение проверок сертификатов своим постоянным исправлением.

Чтобы сравнить конкретный origin, сохраняя имя хоста в TLS-запросе, используйте переопределение адреса curl:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

Если это сработает, а обычный запрос — нет, сравните DNS и любые промежуточные узлы. Это переопределение не редактирует DNS. Когда существуют и A-, и AAAA-записи, повторите обычный запрос с --ipv4 и --ipv6 из клиента, который действительно поддерживает соответствующую сеть.

Изучите серверную сторону соединения

На VPS проверьте прослушиваемые TCP-сокеты и обратитесь к приложению напрямую:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss показывает слушателей и, при достаточных правах, их процессы. Слушатель на loopback доступен локально; его наличие само по себе ничего не говорит о внешнем доступе. Сверьтесь с руководством по upstream в ss. Если прямой запрос к приложению не удался, перейдите к руководству по диагностике процессов прежде чем менять DNS.

Для этой одно-приложенческой схемы relevant блок Caddyfile таков:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Имя хоста и upstream должны соответствовать вашему приложению. В Caddy директива reverse proxy перенаправляет запросы на настроенный upstream; указание произвольного домена здесь не даёт вам контроля над ним. Сохраните существующую конфигурацию перед редактированием. При использовании пакетной службы и этого пути к файлу сначала выполните проверку, а затем перезагружайте только после успешной проверки:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

У команд разные назначения: проверка проверяет загрузку конфигурации, а перезагрузка применяет изменение. Проверьте фактический путь к файлу и права установленной службы. Справочник команд Caddy объясняет поведение проверки и перезагрузки.

Проверьте полный путь, затем сохраните доказательства

Для обычной автоматизации публичных сертификатов Caddy нужны корректный DNS, внешне доступные порты для challenge, разрешение на привязку слушателей и постоянное записываемое хранилище сертификатов. HTTP- и TLS-ALPN-challenge используют порты 80 и 443 соответственно; DNS-challenge — это отдельная настройка. См. предварительные требования Caddy HTTPS. Сохраняйте административный доступ при проверке правил фаервола.

Иллюстративный результат: локальная конечная точка возвращает {"status":"ok"}, внешний запрос HTTPS возвращает то же небольшое тело, а curl сообщает об успешной проверке сертификата. Это ожидаемые наблюдения для данного примера, а не записанные результаты с сервера OffVPS. Также выполните одно обычное действие приложения: поверхностная конечная точка проверки здоровья может проходить, тогда как маршрут, зависящий от базы данных, — нет.

Зафиксируйте время запроса, имя хоста, семейство адресов и первый отказавший уровень. Такая сводка полезнее, чем «домен сломан». Когда путь заработает, используйте руководство по повторяемым релизам чтобы сделать такие же проверки частью каждого развёртывания.