Hosting Sunucu Loglarını Okumayı Öğrenin: Apache ve Nginx ile 4xx–5xx Hatalarını Teşhis Rehberi

Sunucu loglarını anlayamadan sorun çözmek neden bu kadar zor?

Bir web projesinin kapasite planlama toplantısında, genellikle herkes sayılara bakar: günlük ziyaretçi, saniyede istek, CPU ve RAM kullanım oranları. Ancak masada çoğu zaman eksik olan bir veri vardır: sunucu logları. Access ve error loglarını sistematik şekilde okumayı öğrenmediğiniz sürece, yaşadığınız 4xx–5xx hataları hep “tahmin” seviyesinde kalır. “Herhalde cache yüzünden”, “Muhtemelen bir eklenti bozdu” gibi cümleler havada uçuşur; ama elde somut kanıt yoktur.

DCHost olarak gördüğümüz en yaygın sorunlardan biri şu: Loglar mevcut, hatta yıllardır tutuluyor; ama kimse onları karar almak için kullanmıyor. Oysa Apache/Nginx access ve error logları, sitenizde neler olduğunu saniye saniye anlatan birer kara kutu. 404’lerle SEO kaybını, 500 hatalarıyla kaçırılan siparişleri, 503 ile patlayan kampanyaları bu loglara bakarak netleştirmek mümkün. Bu yazıda, bir sistem yöneticisi kadar derine inmeden, ama bir geliştiricinin işini görecek kadar detayla hosting sunucu loglarını okumayı, özellikle de 4xx–5xx hatalarını teşhis etmeyi anlatacağız. Örnek komutlar, gerçekçi senaryolar ve DCHost altyapısında işinizi kolaylaştıracak pratiklerle ilerleyeceğiz.

Hangi log dosyaları nerede? Apache ve Nginx yol haritası

Önce “nerede ne var?” sorusunu netleştirelim. Apache ve Nginx tabanlı bir Linux sunucuda tipik olarak iki ana log türüyle ilgilenirsiniz: access log ve error log.

Access log nedir, ne işe yarar?

Access log, sitenize gelen her HTTP isteğini satır satır kaydeden dosyadır. Her satırda tipik olarak şunlar yer alır:

• İstek yapan IP adresi
• Tarih ve saat
• HTTP methodu (GET, POST vb.)
• İstenen URL
• HTTP durum kodu (200, 301, 404, 500…)
• Cevap boyutu
• Referer (isteğin geldiği sayfa)
• User-Agent (tarayıcı / bot bilgisi)

4xx–5xx hatalarını analiz ederken ilk bakacağınız yer çoğu zaman access log’dur; çünkü hangi URL’lerin ne sıklıkla hata verdiğini buradan çok hızlı görebilirsiniz.

Error log nedir, ne işe yarar?

Error log ise web sunucusunun ve genellikle arkasındaki uygulamanın (PHP-FPM, proxy, upstream vb.) ürettiği hata ve uyarı mesajlarını içerir. Örnekler:

• Dosya bulunamadı (File does not exist)
• Yetki hatası (Permission denied)
• PHP fatal error, parse error
• Upstream timeout (504) veya bad gateway (502) mesajları
• Konfigürasyon hataları

Access log size “ne oldu?”yu söylerken, error log “neden oldu?” sorusunun cevabını verir. İkisini birlikte okumak, özellikle 5xx hatalarında kök neden analizi yapmak için şarttır.

Varsayılan log yolları

Dağıtıma, panele ve kuruluma göre yollar değişebilir; ama sık görülen dizinler şunlardır:

• Apache access log: /var/log/apache2/access.log veya /var/log/httpd/access_log
• Apache error log: /var/log/apache2/error.log veya /var/log/httpd/error_log
• Nginx access log: /var/log/nginx/access.log
• Nginx error log: /var/log/nginx/error.log

cPanel, Plesk, DirectAdmin gibi panelli ortamlarda her domain için ayrı log dosyaları da olabilir. Log saklama politikalarıyla ilgili daha detaylı bir perspektif için hosting ve e-posta altyapısında log saklama süreleri hakkında detaylı rehber yazımıza da göz atabilirsiniz.

Access log formatını okumayı öğrenmek

Access log, başta karmaşık görünür ama bir kez formatı çözdüğünüzde gözünüz alışır. Apache için klasik bir satır örneği:

203.0.113.10 - - [05/Dec/2025:10:15:32 +0300] "GET /urun/123 HTTP/1.1" 404 512 "https://www.example.com/kategori/ayakkabi" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Bu satırı parçalara ayıralım:

• 203.0.113.10: İstek yapan IP adresi. Güvenlik, bot trafiği ve rate limiting için önemli.
• [05/Dec/2025:10:15:32 +0300]: Sunucunun log saat dilimine göre zaman damgası.
• “GET /urun/123 HTTP/1.1”: HTTP methodu, path ve protokol.
• 404: HTTP durum kodu. Burada kritik kısmımız bu.
• 512: Cevap gövdesinin bayt cinsinden boyutu.
• “https://www.example.com/kategori/ayakkabi”: Referer. Kullanıcı bu sayfaya hangi sayfadan gelmiş?
• User-Agent: Tarayıcı ya da bot bilgisi.

Nginx’te de benzer bir “combined” format kullanılır, sadece alanların sırası ve eklenen bazı metrikler (istek süresi, upstream süresi gibi) değişebilir. Konfigürasyonda log_format direktifiyle bu alanları özelleştirmek mümkündür.

Gerçekçi bir senaryo: 404 yağmuru nereden geliyor?

Varsayalım ki SEO ekibiniz, “Son haftada 404 hataları artmış” diyor. Nereden başlayacaksınız?

1. Önce access log’dan 404 kodlarını filtrelersiniz:

   grep " 404 " /var/log/nginx/access.log | head
   

2. Daha sonra en çok hangi URL’lerin 404 verdiğini görmek istersiniz:

   grep " 404 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head 20
   

   Bu örnekte $7 alanı istenen path’i temsil ediyor (formatınıza göre değişebilir).

3. Sonuçta /blog/eski-yazi veya /urun/123 gibi sık tekrarlanan path’ler görürsünüz. Bunlar için 301 yönlendirme mi tanımlamalısınız, yoksa sayfayı yeniden mi yayınlamalısınız? Bu karar artık veriyle alınır.

404 ve diğer durum kodlarının SEO etkisini derinlemesine anlamak isterseniz, HTTP durum kodları ve SEO etkileri yazımız bu yazıyı güzel tamamlar.

Error log ile 4xx ve 5xx kök neden analizi

Access log size “hangi URL hata veriyor?”u söyledi, şimdi sıra “neden?” sorusunda. Bu aşamada error log devreye girer.

404 ve 403 için tipik error log mesajları

Örneğin Apache’de sık gördüğümüz mesajlar:

[Fri Dec 05 10:15:32.123456 2025] [core:error] [pid 12345] [client 203.0.113.10:51234] File does not exist: /var/www/html/urun/123
[Fri Dec 05 10:16:01.654321 2025] [authz_core:error] [pid 12346] [client 198.51.100.5:42311] AH01630: client denied by server configuration: /var/www/html/admin

• File does not exist: Çoğu zaman 404 ile sonuçlanır. Yanlış URL, eksik deploy, silinmiş dosya gibi durumları gösterir.
• client denied by server configuration: Tipik olarak 403 (Forbidden). IP bazlı kısıtlama, dizin yetkisi veya .htaccess ile getirilen yasaklar olabilir.

500, 502, 503, 504 için tipik error log mesajları

5xx kategorisi, sunucu taraflı sorunları işaret eder. Nginx üzerinden bir örnek:

2025/12/05 10:20:11 [error] 1234#1234: *56789 upstream prematurely closed connection while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /odeme HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Bu mesaj, Nginx’in arkasındaki PHP-FPM süreci cevap veremediğinde veya erken kestiğinde ortaya çıkar ve çoğunlukla 502/504 ile sonuçlanır. Nedenleri:

• PHP-FPM max_children sınırına takılması
• Uzun süren yavaş sorgular (veritabanı, harici API çağrıları)
• Kaynak limitleri (CPU, RAM) dolması

Paylaşımlı hosting kullanıyorsanız, limitlere takılma konusunu anlamak için cPanel’de kaynak limitleri ve ‘Resource Limit Reached’ hatası yazısı, bu bölümle güzel bir bağ kuracaktır.

4xx hatalarını teşhis etmek: 400, 401, 403, 404, 410

4xx kodları istemci taraflı görünse de, çoğu zaman yanlış yönlendirme, bozuk link, eksik deploy gibi sizin çözebileceğiniz problemlerden kaynaklanır.

404: Bulunamadı (ama SEO kaybı çok rahat bulunur)

404, en masum görünen ama SEO’da en çok zararı veren hatadır. En kritik sorular:

• 404 alan URL’ler gerçekten artık var olmayacak sayfalar mı?
• Bu URL’ler arama motorlarında indexlenmiş mi?
• Bu URL’lere site içi link veriliyor mu?

Access log üzerinden en çok 404 alan ilk 100 URL’i çıkarıp, SEO ekibiyle birlikte “301 mi, 410 mu, yeniden yayın mı?” kararını verebilirsiniz. 410 (Gone) kullanımı, özellikle gerçekten kaldırdığınız sayfalarda arama motorlarına daha net sinyal vermenizi sağlar. Bu kodların hepsinin SEO tarafındaki davranışlarını daha derin okumak isterseniz, yine HTTP durum kodları rehberimiz elinizin altında olsun.

403: Yetkisiz erişim mi yanlış konfigürasyon mu?

403 (Forbidden), iki ana durumda karşınıza çıkar:

1. Bilerek yasakladığınız alanlar (admin panelini IP ile kısıtlamak gibi).
2. Farkında olmadan bozduğunuz yetkiler, .htaccess veya Nginx kuralı.

Error log’da client denied by server configuration veya benzeri mesajlar görüyorsanız, önce ilgili dizinin izinlerini ve konfigürasyon bloklarını kontrol etmeniz gerekir. Siteniz birdenbire 403 vermeye başladıysa, genellikle son yaptığınız değişiklik (yeni güvenlik kuralı, WAF, .htaccess) ile ilgilidir.

400/401: Yanlış istek ve yetkilendirme sorunları

400 (Bad Request) çoğu zaman bozuk bir istek, hatalı header veya reverse proxy katmanındaki uyumsuzluklardan kaynaklanır. 401 (Unauthorized) ise genellikle basic auth, JWT veya uygulama içi login mekanizmalarınızla bağlantılıdır. Bu kodlar için:

• Access log’dan en çok 400/401 alan endpoint’leri çıkarmak
• Error log’da ilgili zaman aralığındaki detay mesajları incelemek
• İstemci tarafında (özellikle API çağrılarında) gönderilen header’ları kontrol etmek

çoğu zaman sorunu netleştirir.

5xx hatalarını teşhis etmek: 500, 502, 503, 504

5xx kodları, “top artık tamamen sunucuda” anlamına gelir. Kullanıcının değil, sunucu tarafı altyapının, uygulamanın veya konfigürasyonun problemi vardır.

500 Internal Server Error: PHP ve uygulama hataları

Genelde PHP uygulamalarında 500 hataları, fatal error veya syntax error kaynaklıdır. Apache error log’da sık görülen örnek:

PHP Fatal error:  Uncaught Error: Call to undefined function get_product_price() in /var/www/html/app/cart.php:120

Bu tip bir hata gördüğünüzde sorunun log satırında dosya ve satır numarasıyla birlikte geldiğini fark edersiniz. Uygulama geliştiriciniz bu bilgiyi kullanarak hızlıca düzeltme yapabilir.

502 Bad Gateway ve 504 Gateway Timeout: Nginx ve upstream sorunları

Nginx, çoğu DCHost VPS ve dedicated kurulumunda genellikle PHP-FPM veya başka bir uygulama sunucusuna (Node.js, Gunicorn, vb.) reverse proxy yapar. 502/504 hatalarının yaygın nedenleri:

• Uygulama sürecinin çökmesi veya hiç başlamamış olması
• Uzun süren sorgularla tıkanan PHP-FPM havuzları
• Nginx proxy_read_timeout / fastcgi_read_timeout sürelerinin çok kısa ayarlanması
• CPU/RAM tükenmesi nedeniyle süreçlerin öldürülmesi

Nginx error log’da upstream timed out, upstream prematurely closed connection gibi mesajlar görürseniz, bir sonraki adımınız uygulama logları ve sistem kaynak kullanımını incelemektir.

503 Service Unavailable: Kapasite ve bakım sinyali

503 genellikle iki durumda karşınıza çıkar:

1. Sunucuyu bilinçli olarak bakıma almışsınızdır.
2. Kapasite yetmediği için süreçler yeni bağlantıları reddediyordur.

Yoğun kampanya dönemlerinde e-ticaret sitelerinde sık gördüğümüz durum, kısa süreli ama tekrarlayan 503’lerdir. Bu noktada yoğun trafikli kampanyalar için hosting ölçeklendirme rehberi ve kaynak planlama yazılarımızla birlikte düşünmek gerekir; çünkü bu artık yalnızca bir konfigürasyon değil, aynı zamanda kapasite tasarımı problemidir.

Konsoldan log okuma ve filtreleme: Pratik komutlar

Logları okumayı öğrenmenin ikinci ayağı, onları komut satırından hızlıca filtreleyebilmektir. İşinize en çok yarayacak birkaç temel komutu toparlayalım.

tail ile canlı log izleme

tail -f /var/log/nginx/access.log

Bu komut, access log’a yeni satır eklendikçe canlı olarak görmenizi sağlar. Özellikle deploy sonrası veya bir hatayı tekrar üretirken çok işe yarar.

grep ile durum kodu veya URL filtreleme

# 500 hatalarını bul
grep " 500 " /var/log/nginx/access.log

# Belirli bir URL için tüm istekler
grep "/odeme" /var/log/nginx/access.log

Grep ile çıktıyı başka komutlara pipe ederek daha gelişmiş analizler yapabilirsiniz.

En çok hata üreten IP ve URL’leri bulmak

# En çok 404 üreten ilk 10 IP
grep " 404 " /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head 10

# En çok 500 üreten ilk 20 URL
grep " 500 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head 20

Bu iki komut bile, güvenlik (şüpheli IP’ler), SEO (bozuk linkler) ve uygulama hataları açısından size kuvvetli ipuçları verir.

Sıkıştırılmış eski logları incelemek: zgrep

Birçok sistemde eski loglar .gz olarak sıkıştırılır. Eski bir sorunu geçmişe dönük incelemek için:

zgrep " 500 " /var/log/nginx/access.log.1.gz | head

komutunu kullanabilirsiniz.

E-ticaret ve SaaS senaryoları: 4xx–5xx ile kaybolan geliri bulmak

E-ticaret sitelerinde 4xx–5xx hataları çoğu zaman doğrudan kaybedilen sipariş anlamına gelir. Sepetten ödemeye giden funnel’ı loglar üzerinden analiz etmek, “Nerede düşüyoruz?” sorusunu netleştirir.

• /sepet endpoint’inde 200 oranı yüksek ama /odeme endpoint’inde 5xx artıyorsa, ödeme adımında uygulama veya entegrasyon sorunu vardır.
• Belirli kampanya URL’lerinden gelen trafikte 404 artışı varsa, bozuk link veya eksik yönlendirme söz konusudur.
• Belirli bir IP aralığından gelen isteklerde 403/429 oranları yüksekse, WAF veya rate limiting ayarları aşırı agresif olabilir.

Bu konuyu pratik alarm kurallarıyla birlikte ele aldığımız e-ticaret sepet ve ödeme adımlarını loglarla izlemek yazısı, burada bahsettiğimiz yaklaşımı bir adım ileri taşıyıp otomasyona dönüştürmek için iyi bir kaynak olacaktır.

Log saklama, KVKK ve operasyonel pratikler

Log okumayı öğrendikten sonra gelen bir sonraki soru şudur: Bu logları ne kadar süre saklamalıyız? Cevap; teknik ihtiyaçlar, yasal zorunluluklar ve gizlilik politikalarınızın kesişiminde bulunur.

• Performans ve hata analizi için genellikle son 30–90 gün kritik önemdedir.
• Güvenlik olayları için daha uzun saklama süreleri gerekebilir.
• KVKK ve GDPR kapsamında IP gibi kişisel veriler içeren loglar için, saklama sürelerini politikalarınızda açıkça tanımlamanız gerekir.

Bu dengeyi kurarken, hem log saklama süreleri hakkında detaylı rehber yazımızı hem de KVKK ve GDPR uyumlu hostingte loglama yaklaşımı yazımızı birlikte okumanızı öneririz. Böylece sadece teknik açıdan değil, hukuki açıdan da sağlam bir zeminde kalırsınız.

DCHost altyapısında log yönetimi ve merkezi izleme

Tek bir VPS’te SSH ile log okumak nispeten kolaydır. Ancak birkaç VPS, staging/canlı ortamı, belki ayrı veritabanı ve cache sunucuları devreye girdiğinde log yönetimi hızla karmaşıklaşır. Bu noktada iki yaklaşım öne çıkar:

1. Yerel log okuma: Her sunucuya SSH ile bağlanıp tail, grep komutlarını kullanmak.
2. Merkezi loglama: Tüm sunuculardaki logları tek bir platformda toplayıp arama, filtre ve dashboard üzerinden görmek.

DCHost olarak, özellikle VPS ve dedicated sunucu müşterilerimize ikinci yaklaşımı öneriyoruz. Örneğin Grafana Loki + Promtail gibi çözümlerle access ve error loglarınızı tek yerde toplayıp, 4xx–5xx artışlarını grafikler üzerinden anlık takip etmek mümkün. Bunu adım adım anlattığımız VPS log yönetimini merkezi hale getirmek rehberi, bu yazıyı pratik bir mimariye dönüştürmek için iyi bir başlangıç.

DCHost üzerinde yönetilen (managed) çözümler kullanıyorsanız, belirli log analizi ve alarm kurallarını birlikte tasarlayarak, kritik 4xx–5xx artışlarında hem sizin ekibinizi hem de bizim operasyon ekibini haberdar eden bir yapı kurmak mümkün.

Özet ve sonraki adımlar

Hosting sunucu loglarını okumayı öğrenmek, ilk bakışta “sistemci işi” gibi görünebilir. Oysa bir ürün yöneticisinden SEO uzmanına, backend geliştiriciden e-ticaret operasyon sorumlusuna kadar herkes için son derece değerli bir beceridir. Apache/Nginx access log’ları sayesinde hangi URL’lerin ne sıklıkla 4xx–5xx ürettiğini, error log’lar sayesinde de bu hataların kök nedenlerini görebiliyorsunuz. Böylece “tahmin” yerine veriyle konuşmaya başlıyorsunuz.

Buradan sonra atabileceğiniz pratik adımlar:

• Access ve error log yollarınızı netleştirip bir kenara not edin.
• 404, 500, 502, 503 ve 504 için sık kullandığınız grep/awk komutlarının küçük bir “şablon” dosyasını oluşturun.
• En çok 404 veren ilk 100 URL’i çıkarıp SEO ekibiyle birlikte aksiyon planı hazırlayın.
• E-ticaret veya SaaS projeniz varsa, sepet → ödeme funnel’ını loglarla takip edecek küçük bir rapor akışı tasarlayın.
• Bir sonraki adım olarak da, çoklu sunucu yapınız varsa merkezi loglama için yukarıda link verdiğimiz Loki/Promtail rehberini değerlendirin.

Eğer altyapınız DCHost üzerinde çalışıyorsa ve log analizi, alarm kuralları veya ölçeklendirme konusunda daha yapılandırılmış bir yol haritasına ihtiyacınız varsa, destek taleplerinizde log örneklerini bizimle paylaşmanız teşhis sürecini çok hızlandırır. Henüz DCHost altyapısında değilseniz, projeleriniz için uygun hosting, VPS, dedicated sunucu veya colocation kurgusunu birlikte planlarken log yönetimini en baştan mimarinin bir parçası yapmanızı tavsiye ederiz. Çünkü loglarınız, hem bugünkü hatalarınızın hem de yarınki büyüme planlarınızın en temiz aynasıdır.