Bir isteği DNS'ten uygulamanıza kadar takip edin.

Beklediğiniz rotayı yazın

Bu kılavuz, yönettiğiniz bir Linux VPS, çalışan bir SSH oturumu, zararsız bir /healthz uç noktasına sahip bir uygulama ve kontrol ettiğiniz bir alan adının yetkili DNS ayarlarına erişiminiz olduğunu varsayar. Örnek uygulama şurada dinler: 127.0.0.1:3000, Caddy genel ters proxy'dir. Uygulamanız farklı bir gözetleyici veya proxy kullanıyorsa, tanılama sırasını koruyun ve onun belgelerini kullanın.

api.example.com ve 203.0.113.10 bunlar belge yer tutucularıdır, canlı bir hizmet değildir. Kendi sisteminize karşı kontroller çalıştırmadan önce her ikisini de değiştirin. Gerçek ana bilgisayar adını, amaçlanan IP adresini, uygulama bağlantı noktasını ve hizmet adını tek bir yerde not edin. Yapılandırıcıda bir VPS ana bilgisayar adı ayarlamak, genel bir DNS kaydı oluşturmaz.

1. DNS, amaçlanan adresi döndürür.
2. Bağlantı, amaçlanan sunucuya ve bağlantı noktasına ulaşır.
3. TLS, istenen ana bilgisayar adının kimliğini doğrular.
4. Proxy, isteği doğru upstream'e iletir.
5. Uygulama beklenen yanıtı döndürür.

Her iki adres ailesini de kontrol edin

VPS dışındaki bir makineden, yayımlamayı düşündüğünüz kayıtları sorgulayın. dig BIND'in DNS araçlarına aittir; paket adları değişir. Bu komutlar, kayıt türünü, adresi ve kalan önbellek ömrünü görebilmeniz için yanıt bölümünü ister. Bakınız BIND dig başvurusu.

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

Döndürülen her adresi amaçlanan hedefinizle karşılaştırın. Bir AAAA kaydını yalnızca IPv6 yönlendirme, dinleme ve filtreleme o adres için çalışıyorsa yayımlayın. Eski bir AAAA kaydı, bazı istemcileri A kaydından farklı bir yere gönderebilir. Bilinçli olarak bir CDN veya DNS proxy kullanıyorsanız, adresleri doğru olabilir; VPS'nin görünmesi gerektiğini varsaymak yerine bu ek atlamayı kaydedin.

Boş bir yanıt, tam dig yanıta daha yakından bakmayı gerektirir: bu, o türde kayıt olmadığı, var olmayan bir ad veya bir çözümleme sorunu anlamına gelebilir. Düzenlemeden önce hangi DNS hizmetinin yetkili olduğunu kontrol edin. Eski değeri ve TTL'yi kaydedin, amaçlanan değişikliği orada yapın, ardından mevcut önbellekler eskidikten sonra yeni sonuçları karşılaştırın. Tekrarlanan ilgisiz düzenlemeler zaman çizelgesini anlamayı zorlaştırır.

Bağlantı hatalarını sertifika hatalarından ayırın

Küçük uç noktayı sunucunun dışından isteyin. Uygulamanızın HEAD'i uyguladığını varsaymak yerine GET kullanın. Curl'ün zaman aşımı seçenekleri kontrolü sınırlar; ayrıntılı çıktısı bağlantı ve TLS ilerlemesini gösterir. Curl bu seçenekleri ve sertifika doğrulamayı belgeler.

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

Bir çözümleme hatası DNS'e işaret eder. Reddedilen bir bağlantı, bağlantının etkin olarak reddedildiği anlamına gelir; bir zaman aşımı yönlendirme veya filtrelemeyi içerebilir ve hangi güvenlik duvarının buna neden olduğunu tanımlamaz. Bir sertifika hatası, beklenen güvenli bağlantının kurulmadığı anlamına gelir. Sertifika kontrollerini devre dışı bırakmayı kalıcı düzeltmeniz yapmayın.

TLS isteğinde ana bilgisayar adını korurken belirli bir kaynağı karşılaştırmak için curl'ün adres geçersiz kılma özelliğini kullanın:

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

Bu, normal istek başarısız olurken başarılı olursa DNS'i ve varsa aracıları karşılaştırın. Bu geçersiz kılma DNS'i düzenlemez. Hem A hem de AAAA kayıtları varsa, normal isteği --ipv4 ve --ipv6 ilgili ağı gerçekten destekleyen bir istemciden yineleyin.

Bağlantının sunucu ucunu inceleyin

VPS üzerinde, dinleyen TCP soketlerini inceleyin ve uygulamayı doğrudan sorgulayın:

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

ss dinleyicileri ve yeterli izinlerle süreçlerini gösterir. Bir loopback dinleyicisine yerel olarak erişilebilir; varlığı tek başına dış erişim hakkında hiçbir şey söylemez. Başvurun upstream ss kılavuzu. Doğrudan uygulama isteği başarısız olursa, süreç teşhis kılavuzu DNS'i değiştirmeden önce ilerleyin.

Bu tek uygulamalı düzen için ilgili Caddyfile bloğu:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Ana bilgisayar adı ve upstream uygulamanızla eşleşmelidir. Caddy'nin reverse proxy yönergesi istekleri yapılandırılmış upstream'e iletir; buraya rastgele bir alan adı koymak size onun kontrolünü vermez. Düzenlemeden önce mevcut yapılandırmayı koruyun. Paketlenmiş servis ve bu dosya yolu ile önce doğrulayın, ardından yalnızca doğrulama başarılı olduktan sonra yeniden yükleyin:

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

Komutların farklı amaçları vardır: doğrulama yapılandırma yüklemesini kontrol eder, yeniden yükleme ise değişikliği uygular. Kurulu servisin gerçek dosya yolunu ve izinlerini kontrol edin. Caddy'nin komut referansı doğrulama ve yeniden yükleme davranışını açıklar.

Tam yolu doğrulayın, ardından kanıtları saklayın

Olağan genel sertifika otomasyonu için Caddy'nin doğru DNS'e, dışarıdan erişilebilir doğrulama bağlantı noktalarına, dinleyicilerini bağlama iznine ve kalıcı yazılabilir sertifika depolamasına ihtiyacı vardır. HTTP ve TLS-ALPN doğrulamaları sırasıyla 80 ve 443 numaralı bağlantı noktalarını kullanır; DNS doğrulaması ayrı bir kurulumdur. Bkz. Caddy'nin HTTPS ön koşulları. Güvenlik duvarı kurallarını gözden geçirirken yönetici erişimini koruyun.

Örnek sonuç: yerel uç nokta {"status":"ok"}döndürür, harici HTTPS isteği aynı küçük gövdeyi döndürür ve curl başarılı sertifika doğrulaması bildirir. Bunlar bu örnek için beklenen gözlemlerdir, bir OffVPS sunucusundan kaydedilmiş sonuçlar değildir. Ayrıca bir normal uygulama eylemini deneyin: sığ bir sağlık uç noktası geçerken veritabanına bağlı bir rota başarısız olabilir.

İstek zamanını, ana bilgisayar adını, adres ailesini ve ilk başarısız katmanı kaydedin. Bu özet, "alan adı bozuk" demekten daha faydalıdır. Yol çalıştığında, tekrarlanabilir sürüm kılavuzu aracılığıyla aynı kontrolleri her dağıtımın parçası haline getirin.