OffVPSOFFSHORE VPSOndersteuning

Aanvraagpad

Volg één verzoek van DNS naar je app.

Volg hetzelfde verzoek door elke laag en stop bij het eerste onverwachte resultaat. Een werkend proces bewijst niet dat zijn openbare hostnaam werkt, en een DNS-wijziging kan een applicatie die nooit is gestart niet repareren.

OffVPS veldgids · Beoordeeld · 5 min leestijd

Schrijf de route op die je verwacht

Deze walkthrough gaat uit van een Linux VPS die je beheert, een werkende SSH-sessie, een applicatie met een onschadelijk /healthz endpoint, en toegang tot de gezaghebbende DNS-instellingen voor een domein dat je beheert. De voorbeeldapp luistert op 127.0.0.1:3000; Caddy is de openbare reverse proxy. Als je app een andere supervisor of proxy gebruikt, houd dan de diagnostische volgorde aan en gebruik de documentatie ervan.

api.example.com en 203.0.113.10 zijn documentatie-placeholders, geen live service. Vervang beide voordat je controles tegen je eigen systeem uitvoert. Noteer de echte hostnaam, het beoogde IP-adres, de app-poort en de servicenaam op één plek. Het instellen van een VPS-hostnaam in de configurator maakt geen openbaar DNS-record aan.

  1. DNS retourneert het beoogde adres.
  2. De verbinding bereikt de beoogde server en poort.
  3. TLS authenticeert de opgevraagde hostnaam.
  4. De proxy stuurt het verzoek door naar de juiste upstream.
  5. De applicatie retourneert de verwachte respons.

Controleer beide adresfamilies

Vraag vanaf een machine buiten de VPS de records op die je wilt publiceren. dig hoort bij BIND's DNS-tools; pakketnamen variëren. Deze commando's vragen het answer-gedeelte op, zodat je het recordtype, adres en resterende cachelevensduur kunt zien. Zie de BIND dig-referentie.

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

Vergelijk elk geretourneerd adres met je beoogde bestemming. Publiceer alleen een AAAA-record wanneer IPv6-routering, luisteren en filteren voor dat adres werken. Een oud AAAA-record kan sommige clients ergens anders heen sturen dan het A-record. Als je bewust een CDN of DNS-proxy gebruikt, kunnen de adressen daarvan correct zijn; noteer die extra hop in plaats van aan te nemen dat de VPS moet verschijnen.

Een leeg antwoord vraagt om een nadere blik op de volledige dig respons: het kan betekenen dat er geen record van dat type is, dat de naam niet bestaat of dat er een resolutieprobleem is. Controleer welke DNS-service gezaghebbend is voordat je bewerkt. Noteer de oude waarde en TTL, maak de beoogde wijziging daar en vergelijk daarna nieuwe resultaten nadat bestaande caches verlopen zijn. Herhaalde ongerelateerde wijzigingen maken de tijdlijn moeilijker te begrijpen.

Scheid verbindingsfouten van certificaatfouten

Vraag het kleine endpoint op vanaf buiten de server. Gebruik GET in plaats van aan te nemen dat je applicatie HEAD implementeert. Curl's timeout-opties begrenzen de controle; de uitgebreide uitvoer toont voortgang van verbinding en TLS. Curl documenteert deze opties en certificaatverificatie.

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

Een resolutiefout wijst terug naar DNS. Een geweigerde verbinding betekent dat de verbinding actief is afgewezen; een timeout kan met routering of filtering te maken hebben en identificeert niet welke firewall het heeft veroorzaakt. Een certificaatfout betekent dat de verwachte beveiligde verbinding niet tot stand is gekomen. Maak het uitschakelen van certificaatcontroles niet je permanente oplossing.

Om een specifieke origin te vergelijken terwijl je de hostnaam in het TLS-verzoek behoudt, gebruik je curl's adresoverride:

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

Als dit slaagt terwijl het gewone verzoek mislukt, vergelijk dan DNS en eventuele tussenliggende partijen. Deze overschrijving bewerkt DNS niet. Wanneer zowel A- als AAAA-records bestaan, herhaal dan het gewone verzoek met --ipv4 en --ipv6 vanaf een client die het overeenkomstige netwerk daadwerkelijk ondersteunt.

Inspecteer de serverzijde van de verbinding

Inspecteer op de VPS de luisterende TCP-sockets en bevraag de app rechtstreeks:

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

ss toont luisteraars en, met voldoende rechten, hun processen. Een loopback-listener is lokaal bereikbaar; de aanwezigheid ervan zegt niets over externe toegang. Raadpleeg de upstream ss-manual. Als het directe app-verzoek mislukt, ga dan naar de handleiding voor procesdiagnose voordat u DNS wijzigt.

Voor deze indeling met één app is het relevante Caddyfile-blok:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

De hostnaam en upstream moeten overeenkomen met uw applicatie. Caddy's reverse proxy-richtlijn stuurt verzoeken door naar de geconfigureerde upstream; een willekeurig domein hier plaatsen geeft u er geen controle over. Behoud de bestaande configuratie voordat u bewerkt. Valideer met de pakketdienst en dit bestandspad eerst en herlaad pas nadat de validatie is geslaagd:

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

De opdrachten hebben verschillende doelen: validatie controleert het laden van de configuratie, terwijl herladen de wijziging toepast. Controleer het werkelijke bestandspad en de rechten van de geïnstalleerde service. Caddy's opdrachtenreferentie legt validatie- en herlaadgedrag uit.

Verifieer het volledige pad en bewaar het bewijs

Voor gewone openbare certificaatautomatisering heeft Caddy correcte DNS, extern bereikbare challenge-poorten, toestemming om zijn listeners te binden en permanente beschrijfbare certificaatopslag nodig. De HTTP- en TLS-ALPN-challenges gebruiken respectievelijk poorten 80 en 443; een DNS-challenge is een aparte opzet. Zie Caddy's HTTPS-vereisten. Houd beheerderstoegang intact bij het beoordelen van firewallregels.

Illustratief resultaat: het lokale eindpunt retourneert {"status":"ok"}, het externe HTTPS-verzoek retourneert dezelfde kleine body, en curl meldt succesvolle certificaatverificatie. Dit zijn verwachte observaties voor dit voorbeeld, geen geregistreerde resultaten van een OffVPS-server. Oefen ook één normale applicatieactie: een oppervlakkig health-eindpunt kan slagen terwijl een database-afhankelijke route mislukt.

Noteer de verzoektijd, hostnaam, adresfamilie en eerste falende laag. Die samenvatting is nuttiger dan “het domein is stuk.” Zodra het pad werkt, gebruik de reproduceerbare release-handleiding om dezelfde controles onderdeel te maken van elke deployment.

Gebruikte documentatie

Primaire referenties voor deze pagina. Controleer de documentatie voor de versie die in uw eigen omgeving is geïnstalleerd.