HTTP durum kodları: yaygın hatalar için pratik rehber

Sunucu logunu açtın ve status sütunu, hiçbiri "200" olmayan sayılarla dolu. Müşteri arıyor: "Site açılmıyor", ama site açılıyor; sadece onun tarayıcısı bir 403 almış ve sen PHP sorununu arıyorsun. Bu makale tam o an için: HTTP durum kodunun sana tam olarak ne söylediğini ayırt etmek ve hangisini kodda, hangisini Nginx veya DNS'te düzeltmen gerektiğini anlamak için.

Önce durum kodunu tahmin etmek yerine nereden göreceğini bil

Herhangi bir analizden önce sunucunun ham yanıtını al. Tarayıcı çok şeyi gizler; curl gizlemez:

curl -sSI https://example.com/old-page | head -n 20
curl -sS -o /dev/null -w "%{http_code} %{time_total}s %{redirect_url}\n" https://example.com/

-I bayrağı yalnızca başlıkları alır, -L eklersen yönlendirme zincirini takip eder ve tam orada arka arkaya üç 301 aldığını anlarsın. -w çıktısı da nihai kodu ve toplam süreyi yazdırır. Gördüğün sayı tarayıcıda gördüğünden farklıysa, muhtemelen CDN veya aradaki önbellek yanıtı değiştirmiştir ve cf-cache-status veya x-cache başlığına da bakmalısın.

Durumları yüksek hacimde görmek için erişim logunu doğrudan sayarım:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Logunun dokuzuncu sütunu durum kodu değilse, log formatı özeldir ve önce Nginx'te log_format'ı kontrol etmelisin. Bu sayım on saniye içinde sorunun sistemik mi yoksa belirli bir yola mı ait olduğunu söyler.

301'e karşı 302: hangisini koda koymalısın

Her ikisi de kalıcı yönlendirmedir ve her ikisi de SEO ağırlığını aktarır. Gerçek farkları tarayıcı önbelleğinde ve istek metodundadır. 301 "bu adres kalıcı olarak değişti" demektir ve tarayıcılar yanıtı önbelleğe alma iznine sahiptir; 302 "şimdilik buraya gitme, oraya git" demektir ve önbelleğe alınmaz. Pratikte farkı, yanlış bir yönlendirme yaptığında ve geri almak istediğinde görürsün: 301 ile siteyi daha önce görmüş kullanıcılar, tarayıcı önbelleğini temizleyene kadar yanlış hedefe gitmeye devam eder. 302 ile bu derdi yaşamazsın.

Benim tercihim: URL yapısının kalıcı değişimi için 301 koy. Test için, kampanyanın geçici yönlendirmesi için ve yarın değişebilecek her şey için 302. Şüphedeysen 302 koy; maliyeti her istekte fazladan bir başlıktır, o kadar.

Çoğu kişiyi yere seren teknik bir nokta: 301 ve 302'de tarayıcı POST metodunu GET'e dönüştürebilir. Bir formu 301 ile yönlendiriyorsan, istek gövdesi kaybolur. Metodu korumak için 307 veya 308 vermelisin. Burada hata yapıyorlar: bir ödeme formunu 301 ile teşekkür sayfasına gönderiyorlar ve sonra POST verisinin ulaşmadığını görüyorlar, oysa log yalnızca sağlıklı bir 301 gösteriyor.

Nginx'te yönlendirmeyi rewrite yerine return ile yaz; daha okunaklıdır ve yönlendirme döngüsünü önler:

location = /old-page { return 301 /new-page; }
location = /promo     { return 302 https://example.com/campaign; }

401 ve 403: birbirine karıştırılan iki tamamen farklı hata

401 "kimliğini kanıtlamadın" demektir. 403 "seni tanıyorum ama iznin yok" demektir. Bu fark sorun gidermede kritiktir, çünkü çözüm yolları birbirinden ayrılır. Log 401 ile doluysa sorun kimlik doğrulamadadır: süresi dolmuş token, kaybolmuş çerez veya aradaki proxy'nin sildiği Authorization başlığı. 403 ile doluysa kullanıcı giriş yapmıştır ve sorun erişim yetkisi seviyesindedir.

Sık gördüğüm tekrarlayan bir kalıp: sitenin statik dosyaları 403 veriyor ama ana sayfa sağlam. Nedeni neredeyse her zaman diskteki dosya izinleridir, uygulama kodu değil:

namei -l /var/www/example.com/wp-content/uploads/2024/05/image.jpg

namei -l tüm yolu kökten gösterir ve tam orada aradaki bir dizinin 700 iznine sahip olduğunu ve www-data kullanıcısıyla çalışan Nginx'in içine giremediğini görürsün. Burada hata yapıyorlar: o dizinin iznini düzeltmek yerine bir çırpıda chmod -R 777 çekiyorlar. Sonuç şu oluyor: hata birkaç saatliğine kayboluyor ve sonra geri geliyor, çünkü bir sonraki yükleme betiği yine doğru izni ayarlıyor. Dizinler için doğru izin 755, dosyalar için 644'tür.

Uygulama tarafında 403'ü bilinçli olarak ve net bir mesajla döndür. "403" ile "404" arasındaki fark son kullanıcı için önemlidir: bir sayfa varsa ama kullanıcının izni yoksa, 404 döndürmek yalnızca kafa karışıklığı yaratır ve logda da iz bırakmaz.

503: neden neredeyse her zaman senin sunucunun suçu değil

503, sunucunun isteği geçici olarak işleyemediği ve sorunun kullanıcının isteğinde değil altyapı tarafında olduğu anlamına gelir. Bu kodu her yerden çok CDN ve yük dengeleyicide görürsün, backend yanıt vermediğinde veya kapasite tükendiğinde. 500'den farkı tam da bu "geçici" olmasıdır: 500 uygulamanın hata verdiği, 503 ise uygulamanın yanıt verme fırsatını bile bulamadığı anlamına gelir.

Kendi siten 503 veriyorsa ve önünde CDN yoksa, genellikle PHP-FPM worker sayısının tükendiği anlamına gelir. Şu iki komutla doğrula:

systemctl status php8.2-fpm --no-pager
grep -E "pm.max_children|pm.max_requests" /etc/php/8.2/fpm/pool.d/www.conf

FPM logunda server reached pm.max_children setting, consider raising it satırını gördüysen sorun tam da budur. pm.max_children'ı yükseltmek işe yarar ama bedava değildir: her worker bellek alır ve sayıyı hesapsız yükseltirsen sunucu swap'e vurur ve her şey yavaşlar. Doğru sayıyı tahminden değil, boş bellekten hesapla. Linux hosting üzerindeysen ve kaynak sınırına dayanıyorsan, plan yükseltmeyi düşünmen gereken nokta burasıdır.

Bu durumu izlemek için "site açılmadı" üzerine değil, durum kodu üzerine alarm kur. Site uptime izleme rehberi tam da bunu kapsıyor: her kısa yeniden başlatmanın sahte bir mesaj üretmesini engelleyerek nasıl alarm alırsın.

Hızlı karar tablosu

Yukarıdaki tabloda yaygın bir tuzak: 404'ü 410 ile karıştırma. 410, kaynağın kalıcı olarak gittiği ve bir daha dönmeyeceği anlamına gelir; silinmiş ürün sayfaları için 404 değil bunu koy. Farkı, 410'un tarayıcıya artık onu aramamasını söylemesidir.

Bu kodların gerçek hız üzerinde ne kadar etkisi olduğunu anlamak istiyorsan, önce hangi isteklerin yavaş olduğunu bilmelisin. Site hız testi rehberi sonuçları yorumlama yöntemini açıklıyor ve yavaş bir 301 ile gerçek bir 503 arasındaki farkı ayırt etmene yardımcı oluyor. WordPress siteleri için de WordPress hız optimizasyonu daha iyi bir başlangıç noktasıdır, çünkü bu kodların yarısı yönlendirme eklentilerinden gelir.

Sık sorulan sorular

301 ile 302 arasındaki fark SEO açısından ne kadar önemli?

Her ikisi de sayfanın ağırlığını aktarır, yani sıralama açısından belirgin bir fark yoktur. Asıl fark tarayıcı önbelleği davranışındadır: 301 önbelleğe alınır ve geri almak daha zordur, 302 alınmaz. Değişimin kalıcı olduğundan eminsen 301 koy, yoksa 302.

Sitem neden 403 veriyor ama ben kendim açabiliyorum?

Çünkü sen yönetici hesabıyla giriş yapmışsın ve diğerleri o hesap olmadan istek gönderiyor. Bu neredeyse her zaman, misafir kullanıcı için erişim kuralının veya dosya izninin doğru ayarlanmadığı anlamına gelir. Gizli bir pencere veya çerezsiz curl ile test et, aynı hatayı göreceksin.

503 hatasını hosting'e mi bildirmeliyim yoksa kendim mi çözmeliyim?

Sitenin önünde CDN varsa ve 503 ondan geliyorsa, önce backend durumunu kontrol et. Backend sağlamsa sorun CDN tarafındadır. Backend yanıt vermiyorsa ve FPM worker'ları dolmuşsa sorun kaynaklardadır ve ya ayarları düzeltmelisin ya da planı yükseltmelisin.

Durum kodu 200 ama sayfa boş; bu da bir hata mı?

Evet ve en kötü türüdür, çünkü hiçbir izleme aracı bunu yakalayamaz. Sunucu her şeyin yolunda olduğunu söyler ve kullanıcı beyaz sayfa görür. Bu durum için yalnızca kodu değil, yanıt içeriğini de kontrol etmelisin; yanıt gövdesinin uzunluğunu kontrol eden basit bir betik yeterlidir.

Sonraki adım: şu anda o tek awk komutunu erişim logunda çalıştır. İsteklerinin yüzde beşinden fazlası 403 veya 503 ise, sitenin gerçek sorunu budur, şimdiye kadar aradığın şey değil.