Linux sunucuda internet yok: DNS ve bağlantı hataları nasıl çözülür?

Linux sunucuda internet yok gibi görünüyor; paket güncellenmiyor, bir API'ye erişilemiyor veya alan adı açılmıyor. İlk iş DNS adresini değiştirmek değil, bağlantının hangi aşamada durduğunu bulmaktır. Temporary failure in name resolution, Could not resolve host ve Network is unreachable aynı sorunu anlatmaz.

Bu rehberde Ubuntu sunucuda DNS ve internet bağlantısını kontrol etme, hatayı yorumlama ve doğru işlemi yeniden deneyerek sonucu doğrulama adımlarını bulacaksınız. Amaç yalnız hata mesajını kaldırmak değil, ihtiyaç duyduğunuz bağlantının çalıştığını göstermektir.

Gereken erişim: SSH bağlantısı ve ayar değişikliği gerekiyorsa sudo yetkisi. root olarak bağlıysanız sudo önekini atlayabilirsiniz. SSH'a ulaşamıyorsanız önce bağlantı hataları rehberine ve DCHost müşteri portalındaki sunucu konsoluna bakın. Açık SSH oturumunu koruyun; ağ ayarını değiştirmeden önce konsola erişebildiğinizi doğrulayın.

Görseller Ubuntu 24.04 LTS, curl 8.5.0 ve iproute2 6.1.0 bulunan gerçek bir demo VPS'ten alınmıştır. İlk ekranlar sunucunun çalışan bağlantısını okur. Hata örnekleri ise sunucunun ana ağından ayrılmış, birbirine bağlı geçici bir test ağında üretilir. Sunucunun gerçek DNS'i, ana ağ kartı ve varsayılan rotası bozulmaz. Kendi sunucunuzda teşhis yaparken bilerek bağlantı kesmeniz gerekmez.

1. Sorun DNS'te mi, ağ bağlantısında mı?

Bir HTTPS isteğini beş adım olarak düşünün:

1. Sunucuda uygun IP adresi ve rota vardır; hangi ağ arayüzünden çıkılacağı bellidir.
2. Ad çözümleme, www.example.com gibi bir adı IP adresine çevirir.
3. TCP bağlantısı, hedef IP'nin istenen portuna ulaşır.
4. TLS, HTTPS bağlantısını ve sitenin sertifikasını doğrular.
5. HTTP, sayfa veya API yanıtını getirir.

DNS sorgusunun da çalışan bir ağ yoluna ihtiyacı vardır. Bu yüzden ilk satırdaki “ad çözümlenemedi” mesajı her zaman yanlış DNS adresi yazıldığı anlamına gelmez.

Gördüğünüz sonuç	Önce neyi inceleyin?
Temporary failure in name resolution	Sistem o anda adı çözememiştir. Çözümleyici ayarı, DNS sunucusuna ulaşım ve hatanın yalnız bir alan adında olup olmadığı.
curl: (6) Could not resolve host	İstekteki hedef ad çözümlenememiştir. Yazım hatası, DNS/NSS sonuçları ve kullanılan ad.
Network is unreachable	Kullanılan adres ailesi için uygun rota veya arayüz bulunup bulunmadığı. Hatanın hangi komuttan geldiğini de kaydedin.
curl: (7) Failed to connect / Connection refused	Hedef IP, port, dinleyen servis ve erişim kuralları. Kod 7 tek başına hangi tarafın sorumlu olduğunu söylemez.
curl: (28) ... timed out	İşlemin DNS, bağlantı, TLS veya yanıt bekleme aşamalarından hangisinde süreyi doldurduğu.
Sertifika hatası, örneğin curl 60	Sertifika adı, geçerlilik, güven zinciri ve sunucu saati. SSL hata kontrolüne geçin.
HTTP 403, 404 veya 503	Bir HTTP yanıtı alınmıştır. Uygulama, erişim kuralı veya aradaki vekil sunucunun yanıtını inceleyin.

Yalnız bir sitenin açılamaması bütün sunucunun internetsiz olduğunu göstermez. Kendi siteniz, dış API ve paket deposu farklı hedeflerdir; önce gerçekten sorun yaşadığınız alan adı, port ve işlemi belirleyin.

2. IP adresini, ağ arayüzünü ve rotayı kontrol edin

Aşağıdaki komutlar ağ ayarını değiştirmez:

date -Is
ip -br link
ip -br address
ip -4 route show
ip -6 route show
ip -4 route get 1.1.1.1

Son komut, örnek bir IPv4 hedefi için çekirdeğin seçeceği yolu gösterir. Paket göndermez ve internetin çalıştığını kanıtlamaz. Kendi hedefinizin doğrulanmış IP adresini biliyorsanız onu da aynı biçimde kontrol edin.

Çıktıdaki alan	Nasıl okunur?
eth0, ens3 gibi ad	Ağ arayüzüdür. Başka sunucunun arayüz adını kopyalamayın.
UP	Arayüzün açık olduğunu gösterir; dış bağlantının tamamını doğrulamaz.
IP adresi ve /24 gibi ek	Adres ve ağ önekidir. Hizmete tanımlanan değerlerle karşılaştırın.
default via ... dev ...	Daha özel bir rota yoksa kullanılacak ağ geçidi ve arayüzdür.
src ...	O rota için seçilen kaynak adrestir.
127.0.0.1 / ::1	Sunucunun kendi iç adresidir; tek başına dış ağa çıkış sağlamaz.

Linux terminaliArayüzü ve varsayılan rotayı birlikte kontrol edin

Gerçek VPS üzerinde yalnız okuma yapan başlangıç kontrolü. Adresler ve ağ geçidi yayın için maskelendi.

Gerçek VPS; arayüz ve rota ayarlarında değişiklik yapılmadı.

01Yakından bakın

1. adım: Arayüzün durumunu okuyun

1. 1Arayüzün durumunu okuyun

   eth0 satırında UP görünüyor. Bu, arayüzün etkin olduğunu gösterir; karşı uçtan yanıt alındığı anlamına gelmez.

2. 2Varsayılan rotayı bulun

   default via … dev eth0 satırı, daha özel bir rota yoksa kullanılacak IPv4 çıkış yolunu gösteriyor.

UP durumu ve bir varsayılan rota, tek başına internet erişimini kanıtlamaz. Sonraki kontrollerde DNS, bağlantı ve uygulama yanıtını ayrı ayrı doğrulayın.

Bu ilk ekran gerçek sunucunun çalışan ağını gösterir. IPv4 ve IPv6 adresleri ile IPv4 rota bilgisi okunur; özel hizmet bilgileri gizlenmiştir. Sonraki hata ekranlarındaki örnek IP'ler bu gerçek adreslerin yerine kullanılacak ayarlar değildir.

Varsayılan rota görünmüyorsa hemen ip route add default çalıştırmayın. Hedefe özel rotalar veya politika kuralları olabilir. Önce hizmetinize ait ağ geçidi, önek ve yapılandırmayı karşılaştırın. Gerekirse ip rule show ile kural listesini de okuyun; başka müşterinin ağ geçidini kullanmayın.

IPv4 çalışırken IPv6 bağlantısı hata verebilir mi?

Evet. Aşağıdaki örnekte kendi hedefinizi yazın:

CHECK_NAME=www.example.com
curl -q -4 --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 15 "https://${CHECK_NAME}/"
printf 'IPv4 curl exit=%s\n' "$?"
curl -q -6 --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 15 "https://${CHECK_NAME}/"
printf 'IPv6 curl exit=%s\n' "$?"

IPv6 denemesi için hedefin uygun IPv6 kaydı ve sunucunun çalışan IPv6 yolu gerekir. IPv4 başarılı, IPv6 başarısızsa bunu bütün internetin kesildiği şeklinde yorumlamayın. IPv6 adresi, rota ve hedefin AAAA kaydını inceleyin. -4 bu komutla sınırlı bir tanı denemesidir; sistem genelinde IPv6'yı kapatmak çözümün ilk adımı değildir.

-q, kişisel .curlrc ayar dosyasının bu çağrıda okunmasını önler; örneğin oradaki bir --fail veya --insecure seçeneği testi değiştirmez. Komutlar yine proxy ortam ayarlarından etkilenebilir. Bir proxy üzerinden çıkıyorsanız bağlantı ve ad çözümleme yolu farklı olabilir; curl: (5) hedef sitenin değil proxy adının çözümlenemediğini belirtir. Proxy adresini paylaşırken kullanıcı adı ve parolayı gizleyin.

3. Ubuntu hangi DNS sunucusunu kullanıyor?

readlink -f /etc/resolv.conf
sed -n '1,25p' /etc/resolv.conf
resolvectl status --no-pager
getent ahostsv4 www.example.com
printf 'getent exit=%s\n' "$?"

www.example.com yerine kontrol ettiğiniz adı yazın. getent ahostsv4, sistemin ad çözümleme kuralları üzerinden IPv4 adreslerini sorar. Sonuçta aynı IP'yi STREAM, DGRAM ve RAW satırlarında görmek üç farklı DNS kaydı olduğu anlamına gelmez; bunlar farklı soket türleridir.

getent, yalnız dış DNS sunucusuna soru sormaz. /etc/nsswitch.conf sırası ve /etc/hosts gibi kaynaklar da sonucu etkileyebilir. Boş sonuçla birlikte çıkış kodu 2, istenen girdinin bulunamadığını bildirir; nedenini tek başına açıklamaz.

Ubuntu'da /etc/resolv.conf dosyasının /run/systemd/resolve/stub-resolv.conf bağlantısı olması ve içinde nameserver 127.0.0.53 yazması olağandır. Bu, systemd-resolved hizmetinin yerel çözümleyicisidir. “DNS yanlış, dış IP olmalı” diyerek dosyanın üzerine yazmayın. Gerçekte kullanılan DNS sunucularını ve ilgili arayüzü resolvectl status içinde okuyun.

Linux terminaliÇözümleyici yöneticisini ve gerçek sorguyu doğrulayın

Önce resolv.conf dosyasını yöneten yapıyı belirleyin, ardından sistemin ad çözümleme yolunu sınayın.

Gerçek VPS; resolver dosyası ve DNS ayarları yalnız okundu.

01Yakından bakın

1. adım: Dosyanın hangi yapı tarafından yönetildiğini görün

1. 1Dosyanın hangi yapı tarafından yönetildiğini görün

   resolv.conf hedefi /run/systemd/resolve/stub-resolv.conf ve mod stub. Kalıcı değişiklik düşünmeden önce etkin yöneticiyi belirleyin.

2. 2Sistem çözümleme testinin sonucunu okuyun

   System resolver exit=0, example.com için yapılan getent ahostsv4 sorgusunun başarılı olduğunu gösteriyor. Adres çıktısı bu kontrolde bastırıldı.

Bu kontrolde example.com için getent ahostsv4 başarılı oldu. DNS başarısı, hedef uygulamanın portunun veya HTTPS yanıtının çalıştığını tek başına göstermez.

Bu ekran da gerçek sunucunun salt okunur kontrolüdür. Çözümleyici dosyasının bağlantısı, resolvectl status bilgileri ve başarılı getent sorgusu okunur. resolvectl bulunmuyorsa veya servis çalışmıyorsa sunucunuz başka bir çözümleyici kullanıyor olabilir; sırf bu komut çalışsın diye DNS hizmetini değiştirmeyin.

dig ile sistemin kullandığı çözümleme aynı şey mi?

Her zaman değil. dig kuruluysa DNS yanıtını ayrıca inceleyebilirsiniz:

dig +time=2 +tries=1 www.example.com A
dig +time=2 +tries=1 www.example.com AAAA

ANSWER içindeki adresi, yanıtın status alanını ve sorgulanan SERVER bilgisini birlikte okuyun. NXDOMAIN adı bulunamadığını, SERVFAIL sorgunun başarısız işlendiğini bildirir; ikisi de “ağ kablosu kopuk” anlamına gelmez. dig +short tek başına bu ayrıntıları gizler.

dig @DNS_IP ... belirttiğiniz DNS sunucusunu doğrudan sorgular. Bu sonuç /etc/hosts, VPN'e özel alan adları ve sistemin normal sorgu sırasıyla aynı olmayabilir. İnternet yokken ilk adımı yeni paket kurmaya bağlamayın; kurulu getent ve mevcut çözümleyici araçlarıyla başlayın.

4. Görsellerdeki kontrollü test ortamını tanıyın

Hataları gerçek müşteri bağlantısına zarar vermeden göstermek için iki geçici network namespace kullanılır. Bunlar ayrı ağ arayüzü, rota ve kendi localhost alanı olan küçük test ortamlarıdır. İnceleme yaptığımız gerçek sunucunun ana bağlantısı çalışmaya devam eder.

Lab bilgisi	Bu rehberdeki değer
Test istemcisi	192.0.2.10
Test ağ geçidi	192.0.2.20
Yalnız lab içinde çalışan DNS	192.0.2.53
Test web hizmeti	203.0.113.20
Test alan adı	web.demo.test
HTTPS portu	8443

Bu IP blokları ve .test adı örnek/test kullanımı içindir; internette erişeceğiniz DCHost hizmet adresleri değildir. Ekrandaki lab yardımcılarını kendi sunucunuza kopyalamanız gerekmez. İzole hata ve düzelme örnekleri IPv4 üzerindedir; gerçek sunucuda IPv6 bilgisi okunması, labda bir IPv6 onarımı yapıldığı anlamına gelmez.

Linux terminaliİzole demoda çalışan başlangıç durumunu kaydedin

Bu noktadan sonraki hata deneyleri ayrı bir ağ ad alanında yapılır. Demo adı ve TEST-NET adresleri yalnız bu ortama aittir.

İzole demo ağı; gerçek VPS ağ ayarları değişmedi.

01Yakından bakın

1. adım: Demo adının çözüldüğünü doğrulayın

1. 1Demo adının çözüldüğünü doğrulayın

   Demo çözümleyicisi 192.0.2.53. getent çıktısı web.demo.test adını 203.0.113.20 adresine çözüyor.

2. 2Uygulama ve TLS sonucunu birlikte okuyun

   HTTP=200, bu /health isteğinin başarılı yanıtını gösterir. TLS-verify=0, verilen demo sertifikasıyla doğrulamanın başarılı olduğunu belirtir.

curl, --cacert ile yalnız demo sertifikasına güvenir. TLS-verify=0 bu çağrıdaki sertifika doğrulamasını gösterir; demo sertifikasının genel güvenilirliğini göstermez.

Sağlıklı başlangıçta lab adı çözülür, hedefe rota bulunur ve HTTPS isteği beklenen yanıtı verir. Labın kendi sertifikası yalnız o komutta --cacert ile doğrulanır; işletim sisteminin güven deposu değiştirilmez. Genel internet sitelerine giderken normal sertifika doğrulaması kullanılır. --insecure / -k bu rehberin çözüm adımı değildir.

5. Temporary failure in name resolution ve curl 6 hatasını ayırın

Lab istemcisinin DNS ayarı, yalnız bu ayrı ortamda, DNS hizmeti bulunmayan kendi 127.0.0.1 adresine yönlendirilir. Böylece DNS hatasının nasıl göründüğü incelenir. Gerçek sunucunun /etc/resolv.conf dosyası değişmez.

Linux terminaliAd çözümleme hatasını bağlantı hatasından ayırın

Yalnız izole demonun DNS adresi, üzerinde DNS dinleyicisi olmayan 127.0.0.1 olarak ayarlandı. Hata bu kontrollü durumda kaydedildi.

İzole demo ağı; gerçek VPS çözümleyicisi değiştirilmedi.

01Yakından bakın

1. adım: Ping mesajındaki aşamayı tanıyın

1. 1Ping mesajındaki aşamayı tanıyın

   Temporary failure in name resolution, adın çözülemediğini söyler. Bu mesajı hedefin ICMP yanıtı vermemesiyle karıştırmayın.

2. 2curl hata kodunu aynı aşamayla eşleştirin

   curl (6) Could not resolve host bildiriyor ve ardından curl exit=6 yazdırılıyor. DNS çözümlemesini inceleyerek devam edin.

Bu hata, hedef uygulamaya bağlantı kurulmadan önce ad çözümleme aşamasında oluştu. Buradaki 127.0.0.1 ayarı yalnız demo hatasıdır; üretim için öneri değildir.

Gerçek lab kaydında ping web.demo.test, Temporary failure in name resolution mesajıyla 2; curl ise Could not resolve host: web.demo.test mesajıyla 6 döndü. Bunlar iki farklı programın çıkış kodlarıdır; birbirinin yerine okunmaz. getent de adres yazmadan başarısız dönebilir, ancak çıktısız kalması tek başına nedeni açıklamaz.

Çıkış kodunu hemen sonraki satırda kaydedin; araya başka komut koyarsanız $? artık o komutun sonucudur.

DNS'i atlayarak aynı HTTPS hedefine nasıl bakılır?

Hedefin doğru IP adresi önceden doğrulanmışsa, curl ile yalnız o istekte adı IP'ye eşleyebilirsiniz. Aşağıdaki örnek doğrudan hedefe bağlantıya izin verilen ağlar içindir; --noproxy yalnız yazdığınız alan adı için proxy kullanımını atlar. Değerleri kendi alan adınız ve doğru sunucu IP'nizle değiştirin:

CHECK_NAME=www.example.com
CHECK_IP=203.0.113.20
curl -q --noproxy "$CHECK_NAME" --resolve "${CHECK_NAME}:443:${CHECK_IP}" \
  --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 15 \
  --write-out 'HTTP=%{http_code}\n' "https://${CHECK_NAME}/"
printf 'curl exit=%s\n' "$?"

Bu örnekte 203.0.113.20 dokümantasyon adresidir; gerçek testte hizmetinize ait doğrulanmış IP gerekir. Alan adı ve port, URL ile birebir eşleşmelidir. --resolve DNS'i düzeltmez; yalnız curl'ün bu istek için kullanacağı adresi belirler.

URL'de alan adı kalır. Böylece HTTP site adı, TLS içindeki SNI ve sertifikanın alan adı doğrulaması korunur. https://IP_ADRESI açmak veya yalnız Host: başlığı eklemek HTTPS için eşdeğer test değildir; farklı sertifika ya da farklı siteye gidebilirsiniz.

Linux terminaliDNS’yi tek istek için atlayarak karşılaştırın

Demo DNS ayarı hâlâ hatalıyken aynı HTTPS hedefi --resolve ile sınandı. Bu seçenek yalnız bu curl çağrısı için ad, port ve adres eşlemesi sağlar.

İzole demo ağı; DNS ayarı bu karşılaştırma sırasında hâlâ 127.0.0.1.

01Yakından bakın

1. adım: Ad, port ve adres eşlemesini okuyun

1. 1Ad, port ve adres eşlemesini okuyun

   --resolve yalnız web.demo.test:8443 için 203.0.113.20 adresini kullanıyor. Aynı sunucunun başka portunu veya sistemin DNS ayarını değiştirmiyor.

2. 2DNS atlandığında alınan yanıtı karşılaştırın

   Aynı hedef HTTP=200 ve TLS-verify=0 döndürüyor. Bu karşılaştırma, önceki ad çözümleme hatasını bu isteğin bağlantı ve TLS aşamalarından ayırır.

--resolve kalıcı DNS onarımı değildir. URL’de alan adı korunduğundan HTTPS adı ve sertifika doğrulaması da korunur; bu demoda güven --cacert ile sağlanır.

Lab örneğinde web.demo.test:8443 için doğrulanmış hedef kullanıldı ve lab sertifikası --cacert ile kontrol edildi. Sonuç HTTP 200, sertifika doğrulama sonucu 0 idi; labın yanlış nameserver 127.0.0.1 ayarı hâlâ yerindeydi. Böylece --resolve ile aynı hedefin yolu, TCP ve HTTPS çalışırken normal ad çözümlemesinin bozuk kalabildiği görüldü. Bütün DNS hizmetlerinin veya diğer sitelerin sağlıklı olduğu sonucu çıkarılmaz.

Proxy veya başka alan adına yönlendirme varsa istek yolu değişebilir. Lab istekleri doğrudan hedefe gider. Ağınız proxy gerektiriyorsa bu doğrudan bağlantı örneğini kullanmayın; proxy'nin ad çözümleme ve erişim yolunu ayrıca inceleyin. Bu örnek yönlendirmeleri otomatik izlemez.

Linux terminaliDNS düzeltmesinden sonra normal yolu yeniden sınayın

İzole demonun DNS ayarı düzeltildikten sonra getent, rota seçimi ve --resolve kullanmayan HTTPS isteği tekrarlandı.

İzole demo ağı; yalnız demo çözümleyici dosyası düzeltildi.

01Yakından bakın

1. adım: Sistem çözümleme yolunu tekrar kullanın

1. 1Sistem çözümleme yolunu tekrar kullanın

   getent artık web.demo.test için 203.0.113.20 sonucunu veriyor. Bu HTTPS denemesinde --resolve kullanılmıyor.

2. 2HTTP, TLS ve çıkış kodunu birlikte doğrulayın

   HTTP=200, TLS-verify=0 ve curl exit=0 aynı doğrulamada görülüyor. DNS sonucunu gerçek uygulama yanıtıyla tamamlayın.

Bu kayıt düzeltme sonrasındaki doğrulamadır. DNS ayarını değiştiren işlem karede veya kısa videoda gösterilmiyor.

Yalnız labın DNS ayarı 192.0.2.53 olarak geri alındı. getent, 203.0.113.20 adresini gösterdi; rota 192.0.2.20 üzerinden bulundu. Aynı HTTPS isteği --resolve olmadan HTTP 200, sertifika doğrulama sonucu 0 ve curl çıkış kodu 0 ile tamamlandı. DNS için asıl son kontrol budur: geçici IP eşlemesi olmadan normal sorgu ve beklenen yanıt birlikte çalışmalıdır.

6. Network is unreachable hatasında rotayı inceleyin

Bu ikinci örnekte DNS ayarı doğrudur. Yalnız lab istemcisinden 203.0.113.20 hedefine giden rota geçici olarak kaldırılır. Böylece ad çözümleme ile hedefe ulaşımın farklı şeyler olduğu görülür.

Linux terminaliSayısal hedefte rota eksikliğini ayırt edin

Yalnız izole demonun 203.0.113.20 hedef rotası kaldırıldı. Doğrudan bağlı 192.0.2.0/24 ağı listede kalıyor.

İzole demo ağı; gerçek VPS rotalarına dokunulmadı.

01Yakından bakın

1. adım: Seçilecek rotayı sorgulayın

1. 1Seçilecek rotayı sorgulayın

   ip -4 route get 203.0.113.20, Network is unreachable döndürüyor. Hedef için kullanılabilir bir IPv4 yol bulunamıyor.

2. 2Sayısal ping hatasını karşılaştırın

   Sayısal hedefe ping de connect: Network is unreachable diyor. Bu kontrol, ad çözümlemesini denklemden çıkarır.

Hedef sayısal IP olduğundan bu iki kontrol DNS çözümlemesi yapmaz. Rota hatasını ad çözümleme hatası olarak ele almayın.

Labdaki hedef rotası kaldırılınca ip route get 203.0.113.20 ve sayısal adrese yapılan ping Network is unreachable, çıkış kodu 2 verdi. Bu ping komutu alan adı kullanmadığı için DNS'e başvurmaz. Bir adın IP'si bulunabiliyor ama sayısal hedef için rota sorgusu başarısız oluyorsa önce rota/arayüz tarafını inceleyin. DNS değiştirmek eksik yolu oluşturmaz.

Çıktının hangi adres ailesine ait olduğunu da kontrol edin; IPv6 yolunun olmaması IPv4 yolunun da olmadığı anlamına gelmez.

Linux terminaliRota geri geldikten sonra uygulamaya kadar doğrulayın

İzole demonun hedef rotası geri yüklendikten sonra rota seçimi, sayısal ping ve HTTPS isteği tekrarlandı.

İzole demo ağı; yalnız demo hedef rotası geri yüklendi.

01Yakından bakın

1. adım: Hedef için seçilen yolu doğrulayın

1. 1Hedef için seçilen yolu doğrulayın

   203.0.113.20 hedefi yeniden 192.0.2.20 üzerinden lab0 arayüzüne yönleniyor. Sayısal ping de bir yanıt aldı.

2. 2Ping sonucunu HTTPS ile tamamlayın

   HTTPS kontrolünde HTTP=200 ve TLS-verify=0 görülüyor. Yalnız ICMP yanıtını uygulamanın çalıştığına kanıt saymayın.

0,124 ms yalnız aynı demo ortamındaki tek ping ölçümüdür; internet gecikmesi veya hizmet performansı vaadi değildir.

Yalnız labın bilinen doğru rotası geri yüklendi. Rota sorgusu doğru /32 hedef yolunu, sayısal ping 1/1 yanıtı, normal HTTPS isteği HTTP 200 ve sertifika doğrulama sonucu 0 gösterdi. Ekrandaki kısa ping süresi yalnız bu yerel labın ölçümüdür; internet gecikmesi veya hizmet taahhüdü değildir.

Kendi VPS'inizde ekrandaki örnek geçidi kullanmayın. Hizmetinize ait adres, ağ geçidi, ağ öneki ve yapılandırma yöneticisini esas alın.

ping yardımcı bir kontroldür; bazı ağlar ICMP yanıtlarını sınırlar. Ping başarısızken TCP/443 çalışabilir. Tersi de mümkündür: ping yanıtı geliyor diye HTTPS hizmeti, sertifika veya uygulama sağlıklı kabul edilmez.

7. DNS çözülüyor ama bağlantı kurulamıyor

Connection refused / curl 7

Linux terminaliKapalı porta yapılan bağlantı denemesini tanıyın

Çalışan 8443 yerine üzerinde dinleyici olmayan demo portu 8444 sınandı. İsim çözülse bile hedef portta bağlantı kurulamadı.

İzole demo ağı; kapalı demo portuna sınırlı tek istek.

01Yakından bakın

1. adım: İstekteki hedef portu kontrol edin

1. 1İstekteki hedef portu kontrol edin

   URL bu denemede web.demo.test:8444/health. Çalışan önceki /health kontrolünde 8443 portu kullanılmıştı.

2. 2Bağlantı hatasını HTTP yanıtından ayırın

   curl (7) Failed to connect bildiriyor. Altındaki HTTP=000, bir HTTP durum kodu alınmadığını gösterir.

curl 7 genel bir bağlantı hatasıdır; tek başına nedenini kanıtlamaz. Bu kontrollü deneyde portun kapalı olduğu biliniyor. HTTP=000 gerçek bir HTTP yanıt kodu değildir.

Labda DNS ve rota korunurken dinleyen hizmet bulunmayan 8444 portuna istek yapıldı. Sonuç curl 7 ve HTTP 000 idi. Böyle bir sonuçta portun doğru olup olmadığını, hizmetin hangi adreste dinlediğini ve erişim kurallarını kontrol edin. Başarılı 8443 isteği ile başarısız 8444 isteği farklı port testleridir.

Hedef sunucu da sizin yönetiminizdeyse orada sudo ss -ltnp ile dinleyen TCP soketlerini okuyabilirsiniz. Servisin yalnız 127.0.0.1 üzerinde dinlemesi dış erişime açık olduğunu göstermez. Başkasının sunucusuna veya bir dış API'ye erişirken kendi sunucunuzdaki dinleyicileri değiştirmek karşı taraftaki sorunu çözmez.

Connection refused, bir reddetme yanıtı alındığını gösterir; çoğu zaman portta dinleyici yoktur, ancak erişim kuralı da reddedebilir. Genel curl 7 kodunu her zaman “servis kapalı” diye çevirmeyin. Güvenlik duvarını tümüyle kapatmak yerine ilgili yön, kaynak, hedef ve port kuralını inceleyin.

Zaman aşımı / curl 28

Linux terminaliZaman aşımında hangi aşamaların tamamlandığını ölçün

Demo /slow uç noktası yanıtı geciktirirken toplam süre --max-time 1 ile sınırlandı. Ek zaman alanları, hatanın hangi aşamadan sonra geldiğini gösterir.

İzole demo ağı; gecikmeli yanıta sınırlı tek HTTPS isteği.

01Yakından bakın

1. adım: Tamamlanan aşamaları okuyun

1. 1Tamamlanan aşamaları okuyun

   DNS 0,002398 s, TCP 0,003770 s ve TLS 0,038182 s. Bu istekte bağlantı ve TLS aşamaları tamamlanmış.

2. 2İlk yanıt gelmeden toplam sınırın dolduğunu görün

   FIRST_BYTE sıfır kalmış ve toplam süre 1,002190 s olmuş. HTTP=000 bir HTTP kodu değildir; curl 28 ile bu isteği zaman aşımında bitirmiş.

DNS, TCP ve TLS alanları başlangıçtan ilgili aşamaya kadar geçen toplam sürelerdir; bağımsız aşama süreleri değildir. Değerler yalnız bu kontrollü demo isteğine aittir.

Labın /slow yolu yanıt vermeden önce 3 saniye bekleyecek şekilde hazırlanmıştır. İstemciye --max-time 1 sınırı verildiğinde istek 1002 milisaniyede, 0 bayt alınmışken curl 28 ve HTTP 000 ile bitti. Yalnız hata koduna bakmak yerine aynı isteğin aşama süreleri de kaydedildi:

Ölçüm	Bu istekteki sonuç
DNS / TCP / TLS	0.002398 / 0.003770 / 0.038182 saniye. Ad çözümleme ve TCP/TLS bağlantısı tamamlanmıştı.
FIRST_BYTE	0.000000. Bu ölçümde yanıtın ilk baytı alınmadı; “sıfır gecikmeyle yanıt geldi” demek değildir.
TOTAL	1.002190 saniye. İlk yanıt baytı gelmeden toplam süre sınırı doldu.

Bu sayılar yalnız kontrollü lab isteğine aittir; sunucu performans ölçütü değildir. Kendi hatanızda DNS, bağlantı veya yanıt bekleme aşamalarını ayrıca ayırın.

Kendi hedefiniz için süreleri birlikte kaydedin:

CHECK_NAME=www.example.com
curl -q --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 15 \
  --write-out 'HTTP=%{http_code}\nDNS=%{time_namelookup}\nTCP=%{time_connect}\nTLS=%{time_appconnect}\nFIRST_BYTE=%{time_starttransfer}\nTOTAL=%{time_total}\n' \
  "https://${CHECK_NAME}/"
printf 'curl exit=%s\n' "$?"

Bu zamanlar isteğin başlangıcına göre birikimli ölçümlerdir; her satır bağımsız bir aşamanın süresi değildir. --connect-timeout, DNS ve TCP/TLS bağlantı aşamasını sınırlar; --max-time işlemin toplam süresini sınırlar. HTTP=000, bir HTTP durum kodu alınamadığını belirtir; sunucunun gönderdiği “000 hatası” değildir.

Bekleme sınırını artırmak bazı yavaş işlemlere zaman tanır, ancak nedeni giderdiğini göstermez. Aynı hedefin normal yanıt süresini, uygulama kayıtlarını, kaynak kullanımını ve gerekiyorsa yüksek CPU incelemesini birlikte değerlendirin.

8. HTTP 503 ile bağlantı hatası aynı şey değildir

Linux terminaliHTTP durumunu curl çıkış kodundan ayrı okuyun

Aynı kontrollü /unavailable uç noktası iki istekte de HTTP 503 döndürür. İkinci isteğe --fail eklendi.

İzole demo ağı; aynı uç noktadan bilinçli üretilen HTTP 503 yanıtları.

01Yakından bakın

1. adım: Varsayılan davranışta HTTP 503 ve exit 0 olabilir

1. 1Varsayılan davranışta HTTP 503 ve exit 0 olabilir

   İlk istekte HTTP=503 görünmesine rağmen curl exit=0. curl varsayılan olarak HTTP hata durumunu her zaman işlem hatasına dönüştürmez.

2. 2--fail ile çıkış kodunu da denetleyin

   İkinci istek --fail kullanıyor. Aynı HTTP=503 yanıtı bu kez curl exit=22 ile sonuçlanıyor.

HTTP yanıtı alınması DNS, bağlantı ve TLS aşamalarının bu istekte geçildiğini gösterir. HTTP 503 ise uygulama veya aracı hizmet katmanında incelenmelidir.

curl, varsayılan kullanımda HTTP 503 yanıtını alıp çıkış kodu 0 ile bitebilir. Aktarım tamamlanmıştır, fakat uygulama beklediğiniz başarı yanıtını vermemiştir. --fail eklendiğinde bu labın 503 yanıtı çıkış kodu 22 olur. Bu yüzden hem HTTP kodunu hem komutun çıkış kodunu okuyun.

Sonuç	Ne söyler?
curl 0 ve HTTP 200	Bu istek aktarılmış ve HTTP 200 yanıtı alınmıştır. Yanıt içeriğini yine doğrulayın.
curl 0 ve HTTP 503	HTTP yanıtı gelmiştir; uygulama veya aradaki hizmet kullanılamadığını bildirmiştir.
--fail ile curl 22, HTTP 503	Aynı HTTP hata yanıtı curl'ün hata sonucuna dönüştürülmüştür.
curl 6, HTTP 000	Hedef adı çözümlenememiş; bir HTTP yanıtına ulaşılamamıştır.
curl 7 veya 28, HTTP 000	Bağlantı ya da süre sınırı sorunu vardır; ayrıntılı mesaj ve aşama bilgisi gerekir.

Kendi siteniz 503 veriyorsa uygulama ve web sunucusu günlüklerini kontrol edin. Dış API 503 veriyorsa API hizmetinin durumunu ve yanıtını inceleyin. Her HTTP hata kodunda VPS'in DNS ayarını değiştirmek uygun değildir.

9. Kalıcı düzeltmeyi doğru yerde yapın

Teşhis tamamlandıktan sonra yalnız bulguyla ilgili ayarı değiştirin. Aşağıdaki adımlar, görsellerdeki labı kopyalamak için değil, kendi Ubuntu sunucunuzda değişikliğin sınırını belirlemek içindir.

1. Konsola erişin ve mevcut durumu kaydedin. IP'leri, rotaları, DNS arayüz ayarlarını ve ilgili yapılandırma dosyalarının yedeğini koruyun. Yapılandırmalar özel bilgi içerebilir; yedeği web köküne koymayın.
2. Ağı kimin yönettiğini bulun. Netplan, systemd-networkd, NetworkManager, DHCP ve cloud-init farklı roller üstlenebilir. /etc/netplan/ dosyalarındaki uyarıları ve seçilen renderer bilgisini okuyun. Bir servisin etkin olması tek başına o arayüzün sahibi olduğunu kanıtlamaz.
3. Doğru değerleri hizmet bilgileriyle karşılaştırın. DNS sunucusu, geçit ve ağ öneki tahmin edilmez. VPN veya şirket içi alan adları özel DNS ve arama alanları gerektirebilir. Rastgele genel DNS yazmak bunları bozabilir.
4. Yönetilen dosyayı körlemesine değiştirmeyin. /etc/resolv.conf bir bağlantıysa üzerine yazmak ayar zincirini bozabilir; geçici resolvectl ayarı da kalıcı Netplan/DHCP yapılandırmasının yerine geçmez.
5. Netplan kullanılan sistemde doğrulayarak uygulayın. Mevcut dosyayı doğru değerlerle düzenledikten sonra sudo netplan generate yapılandırmayı üretip doğrular; tek başına çalışan ağa uygulamaz. Hata varsa önce onu çözün. Ardından konsol açıkken sudo netplan try --timeout 120 ile kontrollü deneme yapılabilir. Bağlantıyı doğrulamadan onaylamayın.

Netplan'ın bu arayüzü yönettiği doğrulanmışsa mevcut arayüzün nameservers bölümündeki addresses alanını DNS hizmet bilgileriyle karşılaştırın. Statik varsayılan rota kullanılıyorsa routes listesindeki to: default kaydının via değeri ilgili adres ailesinin ağ geçidini belirtir. Bütün dosyayı başka bir sunucunun örneğiyle değiştirmeyin; mevcut IP, önek, diğer rotalar ve arama alanlarını koruyun. Geçit veya DNS DHCP/cloud-init üzerinden geliyorsa kalıcı düzeltmeyi bu ayarı üreten kaynakta ele alın; aynı arayüze gereksiz ikinci statik rota eklemeyin.

netplan try onay gelmezse geri dönmeyi amaçlar, ancak belgelerinde geri alma sınırlamaları da vardır. Konsol erişiminin veya dosya yedeğinin yerine geçmez. Süre dolduğunda hem çalışan ağı hem diskteki dosyaları kontrol edin. DHCP/cloud-init tarafından üretilen ayarlarda kalıcılığı o kaynağın yönetim şekline göre ele alın.

DNS önbelleğini temizlemek, erişilemeyen DNS sunucusunu veya eksik rotayı düzeltmez. Yapılandırma doğruysa ve gerçekten eski önbellek sonucu inceleniyorsa sudo resolvectl flush-caches sonrasında yeniden sorgu yapılabilir. Bunu her hatanın ilk çözümü olarak kullanmayın.

10. Aynı bağlantıyı yeniden deneyerek doğrulayın

Düzeltmeden sonra aynı alan adı, adres ailesi, port ve yolu test edin. Sorun HTTPS ise yalnız ping başarısını son kontrol saymayın.

• getent veya kullanılan çözümleyici, hedefi beklenen adrese çözümlüyor mu?
• O sayısal hedef için uygun rota bulunuyor mu?
• Geçici --resolve eşlemesi olmadan normal HTTPS isteği çalışıyor mu?
• Sertifika doğrulaması açık mı; HTTP kodu ve içerik beklenen sonucu veriyor mu?
• Başlangıçta başarısız olan API çağrısı, güncelleme veya uygulama işlemi artık tamamlanıyor mu?
• Mevcut SSH erişimi ve diğer gerekli hizmetler çalışmaya devam ediyor mu?

Linux terminaliDemo temizliğinden sonra gerçek sunucuyu yeniden kontrol edin

Geçici demo kaynakları kaldırıldıktan sonra gerçek VPS üzerinde rota, sistem çözümleyicisi, dış HTTPS isteği ve SSH durumu yeniden okundu.

Gerçek VPS; izole demo kaynakları kaldırıldıktan sonraki salt okunur kontrol.

01Yakından bakın

1. adım: Gerçek dış HTTPS yanıtını doğrulayın

1. 1Gerçek dış HTTPS yanıtını doğrulayın

   example.com için normal sertifika doğrulamasıyla HTTP=200 ve TLS-verify=0 alındı. Bu istekte demo sertifikası veya --resolve kullanılmadı.

2. 2Çıkış kodunu ve yönetim erişimini kontrol edin

   curl exit=0 ve SSH için active görünüyor. Başarısız systemd birimi sorgusu bu kontrolde satır döndürmedi.

Bu, temizlik sonrası anlık doğrulamadır. Uygulamanızın kendi alan adını ve gerçek kullanıcı isteğini ayrıca sınayın; tek dış hedef bütün internet yollarını temsil etmez.

Son gerçek host ekranında IPv4 rotası, başarılı sistem çözümlemesi ve HTTP 200 / TLS doğrulama 0 / curl çıkış kodu 0 sonucu görülür. SSH active, başarısız systemd birimi listesi boştur. Lab kapatılırken yalnız bu demo için oluşturulan iki ağ ortamı, geçici hizmet ve dosyalar kaldırıldı; gerçek sunucunun rota ve DNS ayarlarının başlangıçla aynı kaldığı ayrıca doğrulandı. Bu, laboratuvarın kapanış kontrolüdür; kendi uygulamanızın asıl işlemini ayrıca doğrulayın.

Adım adım videoDNS düzeltmesi sonrası izole demoyu doğrulama

DNS düzeltmesinden sonra alınan yaklaşık 18 saniyelik gerçek doğrulama kaydı. Demo DNS ayarı, ad çözümleme, rota, HTTPS ve çıkış kodu okunuyor. Kayıt 1× hızda; orijinal olay zamanlaması korunmuştur.

Adımları kendi hızınızda takip etmek için videoyu duraklatabilirsiniz.

Videonun yazılı anlatımını okuyun↓

Kaydın yazılı anlatımı

Bu kayıt, yalnız izole labın DNS ayarı düzeltildikten sonraki doğrulamayı gösterir. DNS dosyasını değiştirme işlemi videoda yapılmaz. Ekrandaki $LAB_CA, yalnız bu demo için hazırlanmış sertifika dosyasını belirtir; kendi sunucunuzda hazır bir değişken olması beklenmez.

1. Lab istemcisinde düzeltilmiş DNS ayarı okunur: nameserver 192.0.2.53.
2. getent ahostsv4 web.demo.test, test adı için 203.0.113.20 sonucunu verir.
3. ip -4 route get 203.0.113.20, yolu 192.0.2.20 üzerinden gösterir.
4. --resolve kullanılmadan yapılan HTTPS isteği HTTP=200 TLS-verify=0 ile, hemen ardından okunan curl çıkış kodu da 0 ile doğrulanır.

Sorun sürerse destek talebine hizmet numarasını, saat ve saat dilimini, etkilenen alan adı/portu, komutu, tam hata mesajını ve exit/HTTP kodunu ekleyin. Başka hedefte başarılı sonuç varsa onu da belirtin. Özel anahtar, erişim belirteci, proxy parolası veya tüm ortam değişkenlerini paylaşmayın.

Sık sorulan sorular

VPS internete bağlanmıyor; ilk hangi komutu çalıştırmalıyım?

Önce ip -br address ve ip -4 route show ile adres ve rotayı okuyun. Sonra gerçekten erişemediğiniz alan adını getent ile sorgulayın ve aynı hedefin HTTPS isteğini deneyin. SSH da çalışmıyorsa DCHost müşteri portalındaki konsoldan başlayın.

Temporary failure in name resolution kesin DNS ayarı yanlış mı demektir?

Hayır. Sistem adı o anda çözememiştir. DNS sunucusuna giden yol, yerel çözümleyici, geçici yanıt sorunu veya alan adının kendisi etkili olabilir. resolvectl status, rota ve farklı hedef denemelerini birlikte değerlendirin.

127.0.0.53 yerine genel DNS yazmalı mıyım?

Tek başına bu adres hata değildir; Ubuntu'da yerel systemd-resolved stub'ı olabilir. /etc/resolv.conf bağlantısını ve arayüzün kullandığı DNS'i kontrol edin. Değişiklik gerekiyorsa ağı yöneten yapılandırmada, o ağa uygun DNS değerlerini kullanın.

IP'ye ping gidiyor ama alan adı açılmıyor. DNS mi bozuk?

Olasılıklardan biridir; kesin sonuç değildir. Ping yalnız ICMP'yi dener. Alan adını sorgulayın, doğru portu kontrol edin ve doğrulanmış IP ile curl --resolve denemesini değerlendirin. HTTPS'i doğrudan IP adresiyle açmak aynı sertifika ve siteyi test etmeyebilir.

curl 6, 7 ve 28 arasındaki fark nedir?

6 hedef adının çözümlenemediğini, 7 bağlantının kurulamadığını, 28 süre sınırına ulaşıldığını belirtir. Tam mesaj ve hangi aşamada kalındığı önemlidir. Kodlar tek başına bir hizmeti yeniden başlatma veya DNS değiştirme gerekçesi değildir.

curl başarılı bittiği hâlde neden HTTP 503 görüyorum?

curl varsayılan olarak aktarımı tamamlamayı başarı sayabilir. HTTP 503 uygulama katmanının hata yanıtıdır. HTTP kodunu ayrıca kontrol edin; bu tür durumlarda --fail kullanımı curl'ün de hata koduyla bitmesini sağlar.

Alan adının DNS kaydını değiştirince sunucunun interneti düzelir mi?

Sunucunun dış adları çözmek için kullandığı DNS hizmeti ile alan adınızın yetkili DNS bölgesindeki A/AAAA kayıtları farklıdır. Sorun sitenizin yanlış IP'ye yönlenmesi ise DNS kayıtları rehberini izleyin. VPS'in eksik ağ rotası, alan adına A kaydı ekleyerek düzelmez.

Kaynaklar ve ilgili rehberler

• Ubuntu Server: ağ ve DNS yapılandırması
• Ubuntu 24.04: getent ve sistem ad çözümleme kuralları
• iproute2: rota sorguları ve ayrı ağ ortamları
• curl: komut seçenekleri ve çıkış kodları, HTTPS için doğru ad/IP eşlemesi
• Netplan: kontrollü deneme ve geri alma sınırlamaları

Sonraki adımı bulduğunuz hataya göre seçin: SSH erişim hataları, SSL/HTTPS sorunları, Linux güncellemeleri veya sunucu kaynak kontrolü.