Śledź jedno żądanie od DNS do aplikacji.

Zapisz oczekiwaną trasę

Ten przewodnik zakłada VPS Linux, który administrujesz, działającą sesję SSH, aplikację z nieszkodliwym /healthz punktem końcowym oraz dostęp do autorytatywnych ustawień DNS dla domeny, którą kontrolujesz. Przykładowa aplikacja nasłuchuje na 127.0.0.1:3000; Caddy jest publicznym odwrotnym proxy. Jeśli Twoja aplikacja używa innego nadzorcy lub proxy, zachowaj kolejność diagnostyczną i skorzystaj z jego dokumentacji.

api.example.com oraz 203.0.113.10 są symbolami zastępczymi dokumentacji, a nie działającą usługą. Zastąp oba przed uruchomieniem kontroli względem własnego systemu. Zapisz rzeczywistą nazwę hosta, zamierzony adres IP, port aplikacji i nazwę usługi w jednym miejscu. Ustawienie nazwy hosta VPS w konfiguratorze nie tworzy publicznego rekordu DNS.

1. DNS zwraca zamierzony adres.
2. Połączenie dociera do zamierzonego serwera i portu.
3. TLS uwierzytelnia żądaną nazwę hosta.
4. Proxy przekazuje żądanie do właściwego upstreamu.
5. Aplikacja zwraca oczekiwaną odpowiedź.

Sprawdź obie rodziny adresów

Z maszyny poza VPS odpytaj rekordy, które zamierzasz opublikować. dig należy do narzędzi DNS BIND; nazwy pakietów są różne. Te polecenia żądają sekcji odpowiedzi, aby można było zobaczyć typ rekordu, adres i pozostały czas życia w pamięci podręcznej. Zobacz referencję BIND dig.

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

Porównaj każdy zwrócony adres z zamierzonym miejscem docelowym. Opublikuj rekord AAAA tylko wtedy, gdy routing, nasłuch i filtrowanie IPv6 działają dla tego adresu. Stary rekord AAAA może wysłać niektórych klientów gdzie indziej niż rekord A. Jeśli celowo używasz CDN lub proxy DNS, jego adresy mogą być poprawne; zapisz ten dodatkowy przeskok, zamiast zakładać, że VPS musi się pojawić.

Pusta odpowiedź wymaga bliższego przyjrzenia się pełnej dig odpowiedzi: może oznaczać brak rekordu tego typu, nieistniejącą nazwę lub problem z rozwiązywaniem nazw. Przed edycją sprawdź, która usługa DNS jest autorytatywna. Zapisz starą wartość i TTL, wprowadź zamierzoną zmianę tam, a następnie porównaj świeże wyniki po wygaśnięciu istniejących pamięci podręcznych. Powtarzane niepowiązane edycje utrudniają zrozumienie osi czasu.

Oddziel błędy połączenia od błędów certyfikatu

Zażądaj małego punktu końcowego spoza serwera. Użyj GET, zamiast zakładać, że aplikacja implementuje HEAD. Opcje limitu czasu curla ograniczają kontrolę; jego pełne wyjście pokazuje postęp połączenia i TLS. Curl dokumentuje te opcje i weryfikację certyfikatów.

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

Błąd rozwiązywania nazw wskazuje z powrotem na DNS. Odmowa połączenia oznacza, że połączenie zostało aktywnie odrzucone; limit czasu może dotyczyć routingu lub filtrowania i nie wskazuje, która zapora go spowodowała. Błąd certyfikatu oznacza, że oczekiwane bezpieczne połączenie nie zostało nawiązane. Nie czyń wyłączania kontroli certyfikatów swoją trwałą naprawą.

Aby porównać konkretne źródło, zachowując nazwę hosta w żądaniu TLS, użyj nadpisania adresu w curlu:

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

Jeśli to się powiedzie, a zwykłe żądanie zawiedzie, porównaj DNS i wszelkie elementy pośredniczące. To nadpisanie nie edytuje DNS. Gdy istnieją zarówno rekordy A, jak i AAAA, powtórz zwykłe żądanie z --ipv4 oraz --ipv6 z klienta, który faktycznie obsługuje odpowiednią sieć.

Zbadaj końcówkę serwera tego połączenia

Na VPS sprawdź nasłuchujące gniazda TCP i zapytaj aplikację bezpośrednio:

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

ss pokazuje nasłuchujące procesy, a przy wystarczających uprawnieniach także ich procesy. Nasłuch na interfejsie loopback jest osiągalny lokalnie; jego obecność sama w sobie nic nie mówi o dostępie zewnętrznym. Skonsultuj się z podręcznikiem upstream ss. Jeśli bezpośrednie żądanie do aplikacji zawiedzie, przejdź do przewodnika diagnozy procesów przed zmianą DNS.

Dla tego układu z jedną aplikacją odpowiedni blok Caddyfile to:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Nazwa hosta i upstream muszą odpowiadać Twojej aplikacji. Dyrektywa reverse proxy Caddy'ego przekazuje żądania do skonfigurowanego upstreamu; umieszczenie tutaj dowolnej domeny nie daje nad nią kontroli. Zachowaj istniejącą konfigurację przed edycją. W przypadku usługi z pakietu i tej ścieżki pliku najpierw zwaliduj, a przeładuj dopiero po pomyślnej walidacji:

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

Polecenia mają różne cele: walidacja sprawdza wczytywanie konfiguracji, a przeładowanie stosuje zmianę. Sprawdź rzeczywistą ścieżkę pliku i uprawnienia zainstalowanej usługi. Dokumentacja poleceń Caddy'ego wyjaśnia zachowanie walidacji i przeładowania.

Zweryfikuj pełną ścieżkę, a następnie zachowaj dowody

W przypadku zwykłej automatyzacji certyfikatów publicznych Caddy potrzebuje poprawnego DNS, zewnętrznie osiągalnych portów wyzwania, uprawnień do bindowania swoich nasłuchów oraz trwałego, zapisywalnego magazynu certyfikatów. Wyzwania HTTP i TLS-ALPN używają odpowiednio portów 80 i 443; wyzwanie DNS to osobna konfiguracja. Zobacz wymagania wstępne HTTPS Caddy'ego. Zachowaj dostęp administracyjny podczas przeglądania reguł zapory.

Przykładowy wynik: lokalny endpoint zwraca {"status":"ok"}, zewnętrzne żądanie HTTPS zwraca to samo małe ciało odpowiedzi, a curl zgłasza pomyślną weryfikację certyfikatu. To oczekiwane obserwacje dla tego przykładu, a nie zarejestrowane wyniki z serwera OffVPS. Wykonaj także jedną normalną akcję aplikacji: płytki endpoint zdrowia może przejść, podczas gdy trasa zależna od bazy danych zawiedzie.

Zapisz czas żądania, nazwę hosta, rodzinę adresów i pierwszą warstwę, która zawiodła. Taki zapis jest bardziej użyteczny niż „domena nie działa”. Gdy ścieżka zacznie działać, użyj przewodnika powtarzalnego wydania aby uczynić te same kontrole częścią każdego wdrożenia.