Urmăriți o singură cerere de la DNS la aplicația dvs.

Notați ruta pe care o așteptați

Acest ghid presupune un VPS Linux pe care îl administrați, o sesiune SSH funcțională, o aplicație cu un endpoint /healthz inofensiv și acces la setările DNS autoritative pentru un domeniu pe care îl controlați. Aplicația exemplu ascultă pe 127.0.0.1:3000; Caddy este proxy-ul invers public. Dacă aplicația dvs. folosește alt supervisor sau proxy, păstrați ordinea de diagnosticare și consultați documentația acestuia.

api.example.com și 203.0.113.10 sunt substituenți de documentație, nu un serviciu live. Înlocuiți-i pe amândoi înainte de a rula verificări pe sistemul dvs. Notați numele real de gazdă, adresa IP dorită, portul aplicației și numele serviciului într-un singur loc. Setarea unui nume de gazdă VPS în configurator nu creează o înregistrare DNS publică.

1. DNS returnează adresa dorită.
2. Conexiunea ajunge la serverul și portul dorite.
3. TLS autentifică numele de gazdă solicitat.
4. Proxy-ul redirecționează cererea către upstream-ul corect.
5. Aplicația returnează răspunsul așteptat.

Verificați ambele familii de adrese

De pe o mașină din afara VPS-ului, interogați înregistrările pe care intenționați să le publicați. dig aparține instrumentelor DNS ale BIND; numele pachetelor variază. Aceste comenzi solicită secțiunea de răspuns pentru a vedea tipul înregistrării, adresa și durata de viață rămasă în cache. Consultați referința BIND dig.

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

Comparați fiecare adresă returnată cu destinația dorită. Publicați o înregistrare AAAA doar când rutarea, ascultarea și filtrarea IPv6 funcționează pentru acea adresă. O înregistrare AAAA veche poate trimite unii clienți într-un loc diferit de înregistrarea A. Dacă folosiți intenționat un CDN sau un proxy DNS, adresele acestuia pot fi corecte; înregistrați acel hop suplimentar în loc să presupuneți că VPS-ul trebuie să apară.

Un răspuns gol necesită o examinare mai atentă a întregului dig răspuns: poate însemna nicio înregistrare de acel tip, un nume inexistent sau o problemă de rezoluție. Verificați ce serviciu DNS este autoritativ înainte de editare. Înregistrați valoarea veche și TTL-ul, faceți modificarea dorită acolo, apoi comparați rezultatele noi după expirarea cache-urilor existente. Editările repetate fără legătură fac cronologia mai greu de înțeles.

Separați eșecurile de conexiune de eșecurile de certificat

Solicitați endpoint-ul mic din afara serverului. Folosiți GET în loc să presupuneți că aplicația dvs. implementează HEAD. Opțiunile de timeout ale Curl delimitează verificarea; ieșirea sa detaliată arată progresul conexiunii și TLS. Curl documentează aceste opțiuni și verificarea certificatelor.

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

O eroare de rezoluție indică înapoi spre DNS. O conexiune refuzată înseamnă că conexiunea a fost respinsă activ; un timeout poate implica rutare sau filtrare și nu identifică ce firewall a cauzat-o. O eroare de certificat înseamnă că conexiunea securizată așteptată nu a fost stabilită. Nu faceți dezactivarea verificărilor de certificat soluția dvs. permanentă.

Pentru a compara o origine specifică păstrând numele de gazdă în cererea TLS, utilizați suprascrierea adresei din curl:

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

Dacă aceasta reușește în timp ce cererea obișnuită eșuează, comparați DNS-ul și orice intermediar. Această suprascriere nu editează DNS-ul. Când există atât înregistrări A, cât și AAAA, repetați cererea obișnuită cu --ipv4 și --ipv6 de la un client care acceptă efectiv rețeaua corespunzătoare.

Inspectați capătul serverului al conexiunii

Pe VPS, inspectați socketurile TCP în ascultare și interogați aplicația direct:

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

ss afișează procesoarele în ascultare și, cu permisiuni suficiente, procesele acestora. Un proces în ascultare pe loopback este accesibil local; prezența sa singură nu spune nimic despre accesul extern. Consultați manualul upstream ss. Dacă cererea directă către aplicație eșuează, treceți la ghidul de diagnosticare a proceselor înainte de a modifica DNS-ul.

Pentru această configurație cu o singură aplicație, blocul relevant din Caddyfile este:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Numele de gazdă și upstream-ul trebuie să corespundă aplicației dvs. Directiva reverse proxy a Caddy redirecționează cererile către upstream-ul configurat; introducerea unui domeniu arbitrar aici nu vă oferă control asupra lui. Păstrați configurația existentă înainte de editare. Cu serviciul din pachet și această cale de fișier, validați mai întâi, apoi reîncărcați numai după ce validarea reușește:

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

Comenzile au scopuri diferite: validarea verifică încărcarea configurației, în timp ce reîncărcarea aplică modificarea. Verificați calea reală a fișierului și permisiunile serviciului instalat. Referința de comenzi a Caddy explică comportamentul de validare și reîncărcare.

Verificați calea completă, apoi păstrați dovezile

Pentru automatizarea obișnuită a certificatelor publice, Caddy are nevoie de DNS corect, porturi de provocare accesibile extern, permisiunea de a-și lega procesoarele în ascultare și stocare persistentă și inscriptibilă pentru certificate. Provocările HTTP și TLS-ALPN folosesc porturile 80 și, respectiv, 443; o provocare DNS este o configurație separată. Consultați prerechizitele HTTPS ale Caddy. Mențineți accesul administrativ intact când revizuiți regulile de firewall.

Rezultat ilustrativ: endpoint-ul local returnează {"status":"ok"}, cererea externă HTTPS returnează același corp mic, iar curl raportează verificarea cu succes a certificatului. Acestea sunt observații așteptate pentru acest exemplu, nu rezultate înregistrate de la un server OffVPS. De asemenea, exercitați o acțiune normală a aplicației: un endpoint superficial de stare poate trece în timp ce o rută dependentă de baza de date eșuează.

Înregistrați timpul cererii, numele de gazdă, familia de adrese și primul strat care eșuează. Acel rezumat este mai util decât „domeniul este stricat”. Odată ce calea funcționează, folosiți ghidul de lansare repetabilă pentru a face aceleași verificări parte din fiecare implementare.