Web Sitesi Aşağı, Ancak Sunucu Ulaşılabilir mi? DNS’den Uygulamaya Kadar Hatayı İzleyin

“SSH Çalışıyor, Site Çalışmıyor” — Doğru Soruyla Başlayın

Uyarılar tetiklenmeye başlıyor, kullanıcılar sitenin öldüğünü söylüyor ve ilk testiniz size garip bir rahatlama hissi veriyor: SSH hala sizi içeri alıyor. O an rahatlatıcı hissettiriyor çünkü sunucu kaybolmamış. Ama aynı zamanda birçok kötü sorun gidermenin başladığı yer, çünkü “hala giriş yapabiliyorum” “web sitesi çalışıyor olmalı” ile aynı şey değil.

Yararlı soru “ilk olarak ne yeniden başlatabilirim?” değil. “Hangi katman ilk olarak başarısız oldu?” sorusudur. Çalışan bir SSH oturumu makinenin port 22 üzerinden erişilebilir olduğunu kanıtlar. Alan adının doğru şekilde çözümlendiğini kanıtlamaz. Şunları kanıtlamaz:

• port 80 ve 443 erişilebilir
• HTTPS sağlıklı
• web sunucusunun arkasındaki uygulama yanıt veriyor

Bu kılavuz bu ayrım etrafında oluşturulmuştur ve tam bir nginx, DNS, TLS, Docker veya veritabanı kılavuzu olmaya çalışmak yerine tanılamaya odaklanmış kalır.

⚠️ Uyarı: Bir olayın ilk dakikalarında nginx, Docker, PHP-FPM veya tüm VPS’yi kör bir şekilde yeniden başlatmak, ihtiyacınız olan ipuçlarını silebilir. Önce bir tur kanıt toplayın, sonra sadece gerçekten başarısız olan katmanı değiştirin.

Bir Dakikalık Triage Haritası

Derinlere inmeden önce, yönünüzü belirleyin. Hatanın şekli, kök nedenini henüz bilmediğiniz zaman bile hangi katmanın önce dikkat alması gerektiğini söyler.

Aşağıdaki tabloyu nihai bir karar değil, bir triage kısayolu olarak kullanın.

Önemli olan ilk bozuk aşamadır. DNS başarısız olursa, sonraki katmanlar gürültüdür. 443 yanıt verirse ancak TLS kırılırsa, uygulama henüz ilk sorunuz değildir. Aşağıdaki zihinsel model, bu sırayı rastgele yerine mantıklı hissettirir.

SSH Web Sitesinin Çalıştığını Kanıtlamaz

SSH ve web trafiği farklı yollar ve farklı görevlerdir. Port 22 üzerindeki SSH, makineye uzaktan yönetim kapısı aracılığıyla ulaşabileceğinizi kanıtlar. Bir web sitesi port 80 ve 443 ile bunların arkasındaki katmanları gerektirir. Bunlar ayrı testlerdir, bu nedenle “sunucu ulaşılabilir” ve “web sitesi ulaşılabilir” birbirinin yerine kullanılamaz.

Bunu görselleştirmenin en kolay yolu bir ofis binası olarak düşünmektir. DNS, ziyaretçinin bina adresini bulmasına yardımcı olur. Port 80 ve 443 halk ziyaretçileri için resepsiyon masasıdır. Web sunucusu isteği kabul eden ve nereye gideceğine karar veren resepsiyonisttir. Uygulama gerçek işi yapan ofistir. Bir veritabanı veya başka bir bağımlılık binanın daha içinde yer alabilir. SSH tamamen farklı bir girişidir. Personel için yararlıdır, ancak resepsiyon masasının açık olduğunu veya ofis devri işinin çalıştığını kanıtlamaz.

Browser
  ↓
DNS lookup
  ↓
IP address
  ↓
Port 80 / 443
  ↓
Web server
  ↓
App / upstream
  ↓
Database / dependency

İnsanlar bir hizmetin “dinlediğini” söylediklerinde, beklenen uç noktada gerçekten bağlantıları kabul ettiğini kastediyorlar. Bu, belirsiz “sunucu çalışıyor” anını izlenebilir bir istek yoluna dönüştüren ayrımdır.

Bu önemlidir çünkü HTTPS uygulama hiç yanıt vermeden önce başarısız olabilir ve proxy veya uygulama hataları ön uç zaten ulaşılabilir olduktan sonra gerçekleşebilir. Bu nedenle sonraki adım her zaman aynıdır: dışarıdan bakın ve isteğin son başarılı aşamasını bulun.

Adım 1: Hatayı Sunucunun Dışından Yeniden Oluşturun

İstemci tarafından başlayın, VPS içinden değil. Mümkünse, yerel DNS önbelleğini, eski bir /etc/hosts girişini veya yerel bir güvenlik duvarı/VPN sorununu gerçek bir sunucu kesintisiyle karıştırmamak için önce başka bir ağ veya cihazdan test edin.

İsteğin nereye kadar gittiğini görebilmeniz için ayrıntılı bir harici istek kullanın:

curl -v --connect-timeout 5 --max-time 15 https://example.com/

curl -v burada sadece uzmanlar için bir araç değildir. Bunu bir ilerleme izlemesi olarak okuyun. Adı hiçbir zaman çözmezse, DNS dalındasınız. Bağlanırsa ve ardından Connection refused derse, ana bilgisayar yanıt verdi ancak orada hiçbir şey yararlı trafiği kabul etmiyor. Zaman aşımına kadar askıda kalırsa, filtreleme, yönlendirme veya istek yolunun daha derininde bir askıda kalma düşünün. HTTP yanıtı alırsanız, hata sayfası bile olsa, zaten bağlantı katmanını geçtiniz ve daha yüksek bir dala gittiniz.

💡 İpucu: IPv4 ve IPv6’yı erken karşılaştırın. Unutulmuş bir AAAA kaydı, bazı istemciler IPv6’yı önce tercih ettiği ve diğerleri etmediği için kesintinin tutarsız görünmesini sağlayabilir.

Çift yığın söz konusu olduğunda aynı testi protokol ailesi başına bir kez çalıştırın:

curl -4 -v --connect-timeout 5 --max-time 15 https://example.com/
curl -6 -v --connect-timeout 5 --max-time 15 https://example.com/

IPv4 çalışırsa ve IPv6 başarısız olursa veya tersi olursa, olayı bir hizmet yeniden başlatmasından daha hızlı daraltmış olursunuz. Hata ad çözümlemesinde veya hedef seçiminde başlarsa, DNS kontrol etmek için sonraki temiz daldır.

Adım 2: DNS’i Kontrol Edin ve Doğru Hedefi Onaylayın

nginx’i hata ayıklamadan önce, etki alanının ziyaretçileri gerçekten düşündüğünüz sunucuya gönderip göndermediğini onaylayın. Bu, özellikle göçler, IP değişiklikleri, CDN ayarlamaları veya kısmi kayıt düzenlemelerinden sonra önemlidir.

Önce genel kayıtları kontrol edin:

dig +short A example.com
dig +short AAAA example.com

Bu iki satır çok pratik bir soruyu yanıtlar: İnternet şu anda example.com‘un nerede olduğuna inanıyor? Yaygın bir hata şekli, SSH’nin IP ile yeni VPS’ye ulaşması ancak etki alanının hala eski adresi göstermesidir. Diğeri, A kaydının güncellenmiş olması ancak AAAA kaydının hala eski bir yeri göstermesidir. Bu durumda, trafiğinizin yalnızca bir kısmı başarısız olur.

📝 Not: curl --resolve, olay sırasında genel DNS’i değiştirmekten daha güvenlidir. Genel kayıtlara dokunmadan ana bilgisayar adını ve SNI’yi koruyarak hedeflediğiniz kaynağı test etmenizi sağlar.

Genel kayıtlara dokunmadan beklediğiniz IP’ye karşı bir test zorlamak için curl --resolve kullanın:

curl --resolve example.com:443:203.0.113.10 https://example.com/

Bu çalışırken genel etki alanı hala başarısız olursa, sunucu iyi olabilir ve DNS hala bozuk katman olabilir. Sınırlandırılmış bir CDN notu burada akılda tutmaya değer. Kaynağınız yalnızca CDN IP aralıklarından gelen trafiği kabul etmek için kilitliyse, doğrudan kaynak testi, kaynak kenar trafiğini değil, keyfi genel istekleri beklediği için başarısız olabilir. Hedef onaylandıktan sonra, bir sonraki soru 80 veya 443‘te yararlı bir şeyin yanıt verip vermediğidir.

Adım 3: 80/443 Portlarında Dinleyenleri Doğrulayın

Şimdi sunucuya geçin ve dar bir soru sorun: beklenen portlarda gerçekten web bağlantılarını kabul eden bir şey var mı? Makine canlı olabilir, SSH çalışabilir ve hatta nginx yüklü olabilir. Yine de genel web portlarında hiçbir kullanışlı dinleyici olmayabilir.

Önce dinleyenleri kontrol edin:

sudo ss -ltnp

:80 veya :443 için boş çıktı, hiçbir kullanışlı şeyin orada dinlemediği anlamına gelir. 127.0.0.1 üzerinde bir dinleyici, hizmetin yalnızca yerel makineden bağlantıları kabul ettiği anlamına gelir. 0.0.0.0 üzerinde bir dinleyici, IPv4 arayüzlerine bağlı olduğu anlamına gelir. [::] genellikle IPv6 arayüzleri anlamına gelir. IPv6 bağlamasının otomatik olarak ihtiyacınız olan IPv4 yolunu garantilediğini varsaymayın.

Ardından herhangi bir şey değiştirmeden önce küçük bir nginx sağlık paketi kullanın:

sudo systemctl status nginx --no-pager -l
sudo nginx -t
sudo journalctl -u nginx --since '-30 minutes' --no-pager

• systemctl active (running) diyorsa, bu yalnızca hizmet işleminin var olduğunu kanıtlar
• nginx -t yapılandırmanın geçerli olup olmadığını söyler
• journalctl son yeniden yüklemenin başarısız olup olmadığını, bir sertifika dosyasının kaybolup olmadığını veya bir vhost’un başlangıçta kırılıp kırılmadığını gösterir.

Apache okuyucuları için eşdeğer sözdizimi kontrol komutu apachectl configtest komutudur. Bir şeyin dinlediğini öğrendikten sonra, sonraki kanıt daha spesifiktir: dış ağı denklemden çıkardığınızda doğru site yerel olarak yanıt veriyor mu?

💡 İpucu: Önce yapılandırmayı test edin, ardından uygun olduğunda kör bir yeniden başlatmaya tercih ederek reload kullanın. Bir yeniden yükleme yeni yapılandırmayı doğrular ve yeni yapılandırma kötüyse eski çalışanları tutar; kör bir yeniden başlatma bir olayın ortasında çok daha sert olur.

Adım 4: Siteyi Doğru Host ve SNI ile Yerel Olarak Test Edin

Bu, tüm araştırmanın en önemli ayrılma noktasıdır. Düz bir curl 127.0.0.1 yanıltıcı olabilir. Birçok sunucu birden fazla siteyi barındırır ve Host başlığına veya HTTPS için SNI’ye göre yanıt seçer. Siz bir şeyin yerel olarak yanıt verip vermediğini sorgulamıyorsunuz. Doğru site yolunun yerel olarak yanıt verip vermediğini sorgulamıyorsunuz.

Hostname mantığını koruyan yerel testler kullanın:

curl -I http://127.0.0.1/ -H 'Host: example.com'
curl -v --resolve example.com:443:127.0.0.1 https://example.com/

# Only as a one-off diagnostic if you already know the cert is bad:
curl -vk --resolve example.com:443:127.0.0.1 https://example.com/

Anlamlı bir başarı, doğru siteden beklenen sayfa, beklenen yönlendirme veya beklenen uygulama yanıtıdır. Varsayılan nginx host, yanlış sertifika veya genel “HTML döndürdü” değildir. Buradan üç temiz sonuç vardır: yerel başarı, yerel yanlış site veya varsayılan sertifika davranışı veya yerel başarısızlık/zaman aşımı. İyi bir yerel sonuç sizi güvenlik duvarı, sağlayıcı, CDN veya yönlendirme kontrollerine yönlendirir. Kötü bir yerel sonuç sizi yığın içinde, upstream veya TLS dallarında tutar.

Adım 5: Yerel Olarak Çalışıyorsa Ancak Harici Olarak Çalışmıyorsa, Ağ Yolunu İzleyin

Yerel test iyi gittikten sonra, nginx hakkında bir an için şüphe duymayı bırakın. Site stack muhtemelen sunucuda canlıdır ve eksik parça genellikle ziyaretçi ile o çalışan yerel hizmet arasında bir yerdedir. Host güvenlik duvarı ile başlayın çünkü bu, kontrol ettiğiniz en yakın harici sınırdır.

Host tarafı kurallarını sisteminizin gerçekten kullandığı araçla inceleyin ve orada iken kendi kendine neden olunan engelleme için hızlı bir mantık kontrolü yapın:

sudo nft list ruleset

# Or, on systems still using iptables directly:
sudo iptables-save
sudo ip6tables-save

# Fast sanity check for self-inflicted blocking:
sudo fail2ban-client status

Bu çıktı yalnızca konuk işletim sistemi katmanını gösterir. Sağlayıcı tarafı filtrelemeyi, güvenlik gruplarını veya VPS dışında yaşayan panel tarafı güvenlik duvarı kurallarını göstermez. Örneğin, bir AlexHost VPS’de, makine güvenlik duvarı ve herhangi bir panel düzeyinde ağ kontrolü ayrı sorulardır. Yerel testler çalışıyorsa ancak genel ziyaretçiler yine de başarısız oluyorsa, her ikisi de önemlidir.

⚠️ Uyarı: Docker, konağında bağlantı noktaları yayınlarsa, UFW çıktısının tüm hikayeyi söylediğini varsaymayın. Docker, yayınlanan konteyner trafiğini UFW’nin olağan zincirlerinden önce NAT aracılığıyla yönlendirebilir. Bu, “UFW iyiye benziyor” anlamına gelmez, paket yolu iyiye benziyor.

CDN’ler ve yük dengeleyiciler burada da kendi dallarını hak ediyor. Orijin sağlıklı olabilir ve yine de doğrudan erişilemez çünkü yalnızca kenar IP aralıklarının onunla konuşmasına izin verilir. Paketlerin hiç gelip gelmediğine dair kanıta ihtiyacınız olduğunda, tcpdump‘ı evet-veya-hayır aracı olarak kullanın:

📝 Not: CDN izin listesi arkasında başarısız doğrudan orijin testi, genellikle ölü bir orijine değil, kenar politikasına işaret eder. Bu kurulumda, orijin CDN yoluna güvenmek için tasarlanmıştır, her doğrudan ziyaretçiye değil.

sudo tcpdump -ni any 'tcp port 80 or tcp port 443'

Hiç SYN paketi görmüyorsanız, trafik sunucuya ulaşmıyor. SYN’ler geliyorsa ve SYN-ACK çıkmıyorsa, sunucu veya güvenlik duvarı yolu hala el sıkışmayı engelliyor. Her iki desen de engelleyici görünmüyorsa, kalan başarısızlıklar genellikle ön uçta yukarı akış el sıkışmasının arkasında oturuyor.

Adım 6: Frontend Yanıt Veriyorsa Ancak Site Hala Bozuksa, Upstream’i Takip Edin

Bu dalda, web sunucusuna ulaşılabilir, ancak arkasındaki bir sonraki hop isteği tamamlamak için yeterince sağlıklı değildir. Burada “upstream”, nginx’in isteği sonra ilettiği hizmeti ifade eder: bir uygulama süreci, bir soket tarafından desteklenen runtime, bir konteyner veya başka bir dahili bağımlılık.

Statik sayfalar çalışırken giriş, arama, ödeme veya API rotaları başarısız olması, frontend’in mevcut olduğunun ve arızanın arkasındaki devir noktasında başladığının güçlü bir göstergesidir.

📝 Not: 502‘yi “bir sonraki hop kötü yanıt verdi” ve 504‘ü “bir sonraki hop çok yavaş yanıt verdi” olarak değerlendirin. Her ikisi de upstream yolunu takip etmenin, frontend’de durmak yerine işaretleridir.

Aktif devir noktasını inceleyin, ardından upstream’i doğrudan test edin:

sudo nginx -T

# Direct HTTP upstream example
curl -i http://127.0.0.1:3000/

# Unix-socket-backed HTTP example
curl --unix-socket /run/app.sock http://localhost/

nginx çıktısında proxy_pass, fastcgi_pass veya uwsgi_pass gibi yönergeleri arayın. nginx’in doğru hedefi, doğru protokolü, doğru portu veya soketi gösterip göstermediğini kontrol ediyorsunuz. Konteynerler söz konusuysa, tahmin etmek yerine kısa bir konteyner sağlık kontrolü ekleyin:

docker ps
docker logs --tail 50 <container_name>
docker inspect --format '{{json .State.Health}}' <container_name>
docker port <container_name>

Doğrudan uygulama testi başarısız olursa, sorun web sunucusunun arkasındadır. Doğrudan çalışırsa ancak nginx üzerinden başarısız olursa, devir config’i incelenecek daldır. Veritabanı erişilebilirliği burada ayrı bir derin inceleme olarak değil, yalnızca bir bağımlılık kontrolü olarak önemlidir. Bu upstream-arızası deseni tekrar tekrar devam ederse, bir olayı tahminlere uzatmak yerine özel bir sorun giderme kılavuzuna geçmek doğru zamandır.

Adım 7: TLS ve Sertifika Hatalarını İzole Edin

Bu dal daha dar: 443 numaralı bağlantı noktasında bir şey yanıt veriyor, ancak tarayıcı yine de temiz, güvenilir bir HTTPS oturumunu tamamlayamıyor. 443 numaralı bağlantı noktasına başarılı bir TCP bağlantısı, sertifika, ana bilgisayar eşleşmesi veya el sıkışma yolunun sağlıklı olduğunu kanıtlamaz.

Gerçekte hangi sertifikanın sunulduğunu inceleyin:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -brief

Burası yaygın hata şekillerini yakalamanız gereken yerdir: yanlış ana bilgisayar adı, süresi dolmuş sertifika, eksik zincir veya temiz bir şekilde tamamlanmayan yenileme. Basit bir deyişle, SNI sunucuya hangi ana bilgisayar adını kastettiğinizi söyler. -verify_hostname, sunduğu sertifikanın bu ana bilgisayar adıyla eşleşip eşleşmediğini kontrol eder. Kurtarma sonrasında, bunun bir sonraki kesinti olmaması için yenileme yolunu doğrulayın:

⚠️ Uyarı: Sertifika yenileme için HTTP-01 doğrulamasına güveniyorsanız, gelen 80 numaralı bağlantı noktasına ulaşılabilir olmalıdır. 80 numaralı bağlantı noktasını engelleyen bir güvenlik duvarı veya sağlayıcı kuralı, kullanıcılar HTTPS’nin ölü göründüğünü bildirmeden çok önce yenilemeleri sessizce bozabilir.

sudo certbot renew --dry-run

Adım 8: Kaynakları Çağırmadan Önce Kontrol Edin

Bazı olaylar aslında erişilebilirlik arızası değildir. Yol teknik olarak bozulmamış olabilir, ancak sunucu çok açlık çekiyor, engelleniyor veya aşırı yüklenmiş olup zamanında yanıt veremez. Bu durumda bir site bir açıdan “kısmen canlı” görünebilir ve yine de kullanıcılara ölü gibi gelebilir.

Küçük bir ilk geçiş kaynak paketini çalıştırın:

df -h
df -i
free -h
uptime
vmstat 1 5
sudo journalctl -k -g 'oom|out of memory|killed process'

Sonuçları izolasyon içinde değil, desenler halinde okuyun.

• df -h sıradan disk doluluğunu gösterir.
• df -i inode doluluğunu yakalar; burada alan var gibi görünse de dosya sistemi daha fazla giriş oluşturamaz.
• free -h kullanılabilir bellek çöktüğünde ve swap aktivitesi arttığında en önemlidir.
• uptime CPU tam kapasite olmasa bile yüksek yükü gösterebilir; bu genellikle görevlerin disk veya bellek baskısı nedeniyle beklemede olduğu anlamına gelir, aktif işlem değil.
• OOM olayları hakkında çekirdek günlük satırları, sistemin hayatta kalmak için işlemleri öldürmeye başlayıp başlamadığını söyler.

Sağlayıcı grafikleri zaman çizelgesini doğrulayabilir. Bir AlexHost VPS’de, RAM, disk veya I/O’daki artışların kesinti ile uyumlu olup olmadığını kontrol etmek için faydalı olabilirler. Ancak terminal kanıtları yine de tanıyı yönlendirmelidir. Bu bölüm bir ayarlama kılavuzu değildir; sitenin yönlendirme başarısızlığı yerine baskı altında başarısız olabileceğini söyleyen daldır.

Katmanlar Halinde Düşün, Panik Halinde Değil

SSH çalışırken website açılmıyorsa, zinciri kısa ve tekrarlanabilir tutun:

1. hatayı dışarıdan yeniden oluştur
2. son başarılı aşamayı belirle
3. DNS ve hedefi onayla
4. 80/443 üzerinde gerçek bir dinleyici doğrula
5. doğru siteyi yerel olarak test et
6. ağ yolu, upstream, TLS veya kaynaklar içine dallan

💡 İpucu: Son çalışan SSH oturumunuzu kapatmayın; yeni bir girişin hala çalıştığını ve sağlayıcı konsol erişimi gibi bir yedek erişim yolunuz olduğunu doğrulayana kadar. Canlı bir olay sırasında, kontrolü korumak ilk semptom düzeltmek kadar önemlidir.

Alışkanlıkları hafif tutun: dışarıdan izle, günlükleri tut ve sertifikaları certbot renew –dry-run ile test et. Erişimi yedekler ve konsol yolu ile güvenli hale getir. Sağlayıcı araçları — firewall, grafikler, konsol (AlexHost dahil) — sorun gidermeyi desteklemeli, yerine geçmemelidir. İlk kırık katmanı düzeltmeye odaklan; böylece her olay daha net kanıtlarla ve daha az panikle ele alınır.