Прослідкуйте один запит від DNS до вашого застосунку.

Запишіть маршрут, який ви очікуєте

Цей огляд припускає Linux VPS, яким ви адмініструєте, робочу сесію 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. Відмова в з'єднанні означає, що з'єднання було активно відхилено; тайм-аут може стосуватися маршрутизації або фільтрації й не вказує, який брандмауер його спричинив. Помилка сертифіката означає, що очікуване захищене з'єднання не було встановлено. Не робіть вимкнення перевірки сертифікатів своїм постійним виправленням.

Щоб порівняти конкретне джерело, зберігаючи ім'я хоста в 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.

Для цього макета з одним застосунком відповідний блок Caddyfile такий:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Ім'я хоста та upstream мають відповідати вашому застосунку. Caddy's директива reverse proxy передає запити на налаштований upstream; розміщення довільного домену тут не дає вам контролю над ним. Збережіть наявну конфігурацію перед редагуванням. З пакетною службою та цим шляхом до файлу спершу виконайте перевірку, а потім перезавантажте лише після успішної перевірки:

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

Команди мають різне призначення: перевірка перевіряє завантаження конфігурації, тоді як перезавантаження застосовує зміну. Перевірте фактичний шлях до файлу та права встановленої служби. Довідник команд Caddy пояснює поведінку перевірки та перезавантаження.

Перевірте повний шлях, потім збережіть докази

Для звичайної автоматизації публічних сертифікатів Caddy потребує правильного DNS, зовнішньо доступних портів для челенджів, дозволу на прив'язку своїх слухачів і постійного доступного для запису сховища сертифікатів. Челенджі HTTP і TLS-ALPN використовують порти 80 і 443 відповідно; DNS-челендж — це окреме налаштування. Див. передумови Caddy HTTPS. Під час перегляду правил фаєрвола зберігайте адміністративний доступ незмінним.

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

Запишіть час запиту, ім'я хоста, сімейство адрес і перший рівень, що зазнав збою. Це резюме корисніше за «домен зламано». Коли шлях працює, використайте посібник з повторюваного релізу щоб зробити ті самі перевірки частиною кожного розгортання.