Production ortamında yönlendirmeleri ve HTTP header'larını debug etmek için küçük bir araç seti

Production ortamında HTTP debug etmenin sorunu

HTTP sorunlarının çoğu tarayıcıda görünmezdir. Bir yönlendirme zinciri sessizce başarısız olur, bir cache header'ı tek bir karakter yüzünden yanlış çalışır, bir CORS politikası isteği açıklama yapmadan engeller. Tarayıcının geliştirici araçları konuşmanın sonucunu gösterir, ancak çoğu zaman soruna neden olan ham alışverişi gizler.

Bu en çok production ortamında önemlidir; çünkü ne değiştiğini görmek için logging ekleyemez veya servisleri yeniden başlatamazsınız. Size gerçek HTTP konuşmasını gösteren araçlara ihtiyacınız vardır: request headers, response headers, status codes, redirect targets, timing. İşte bu işi güvenilir biçimde yapan beş araç ve onları tamamlayan tarayıcı teknikleri.

curl: temel araç

curl, araya tarayıcı yorumu girmeden sunucunun tam olarak ne gönderdiğini gösterdiği için başvurulacak ilk araçtır.

Gövde olmadan response headers görmek için:

curl -I https://example.com

Yönlendirmeleri takip edip her adımı görmek için:

curl -L -v https://example.com

-v flag'i (verbose), tüm header'lar dahil olmak üzere tam request ve response içeriğini gösterir. -L flag'i yönlendirmeleri otomatik olarak takip eder. Birlikte, production sorunlarının çoğunun bulunduğu tüm yönlendirme zincirini gösterirler.

Yalnızca yönlendirme konumlarını görmek için:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Bu, tam header gürültüsü olmadan bir yönlendirme zincirini doğrulamanız gerektiğinde kullanışlıdır. -w flag'i çıktıyı yalnızca status code ve zincirdeki bir sonraki URL'yi gösterecek şekilde biçimlendirir.

curl özel header göndermenize de izin verir; bu, CDN davranışını, kimlik doğrulamayı veya API endpoint'lerini test etmek için gereklidir:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: daha iyi varsayılanlara sahip curl

httpie, curl ile aynı işi yapan, ancak hatırlaması daha kolay bir sözdizimi ve okuması daha kolay bir çıktı sunan bir Python aracıdır. Bir yedek değildir—curl daha güçlüdür ve daha yaygın kurulu gelir—ancak hızlı kontroller için httpie daha hızlıdır.

Header'ları görmek için:

http HEAD https://example.com

Yönlendirmeleri takip etmek için:

http --follow --all https://example.com

--all flag'i yalnızca son response'u değil, yönlendirme zincirindeki her response'u gösterir. Bu, curl -L -v eşdeğeridir; ancak çıktı renklendirilmiştir ve taraması daha kolaydır.

JSON göndermek için:

http POST https://api.example.com name=value

httpie varsayılan olarak JSON kabul eder; bu da API test ederken yazımı azaltır. Ayrıca response'u pretty-print eder; bu da bozuk header'ları veya beklenmeyen değerleri fark etmeyi kolaylaştırır.

Browser DevTools: Network sekmesi

Sorun yalnızca tarayıcıda ortaya çıkıyorsa başlamanız gereken yer tarayıcının Network sekmesidir. Size curl ile aynı bilgileri gösterir, ancak tarayıcının yorumunu da gösterir: bir isteği engelleyip engellemediğini, caching'i nasıl ele aldığını, cookie gönderip göndermediğini.

Tam request ve response header'larını görmek için Network sekmesindeki herhangi bir isteğe tıklayın, ardından Headers bölümüne bakın. "Raw" görünümü, header'ları hiçbir biçimlendirme olmadan, gönderildikleri haliyle gösterir.

Yönlendirme zincirlerini görmek için 3xx status code'a sahip istekleri arayın. Tarayıcı bunları son isteğin altında gruplar, ancak her adımı görmek için genişletebilirsiniz. Yönlendirme döngülerini, eksik Location header'larını veya yanlış domaine işaret eden yönlendirmeleri burada bulursunuz.

Timing'i görmek için herhangi bir isteğin Timing sekmesine bakın. Bu, tarayıcının DNS lookup, TCP connection, TLS handshake ve sunucuyu bekleme aşamalarında ne kadar zaman harcadığını gösterir. Bir yönlendirme yavaşsa, timing sekmesi sorunun ağ gecikmesi mi yoksa sunucu işleme süresi mi olduğunu söyler.

Bir sınırlama: tarayıcı güvenlik nedenleriyle bazı header'ları gizler. Set-Cookie header'ları görünürdür, ancak gerçek cookie değerleri maskelenir. Authorization header'ları bazen tamamen gizlenir. Bunları görmeniz gerekiyorsa curl kullanın.

mitmproxy: araya giren proxy

mitmproxy, tarayıcınız ile sunucu arasında duran ve her request ile response'u gerçek zamanlı gösteren bir Python aracıdır. curl'den daha karmaşıktır, ancak tarayıcının otomatik olarak eklediği header'lar dahil, tarayıcının gerçekte ne gönderdiğini gösteren tek araçtır.

Başlatmak için:

mitmproxy

Ardından tarayıcınızı HTTP proxy olarak localhost:8080 kullanacak şekilde yapılandırın. mitmproxy, her isteği terminal arayüzünde gösterecektir. Header'ları inceleyebilir, istekleri gönderilmeden önce düzenleyebilir veya istekleri farklı parametrelerle yeniden oynatabilirsiniz.

Bu, yalnızca tarayıcıda ortaya çıkan sorunları debug etmek için kullanışlıdır: CORS preflight requests, cookie handling veya belirli header'lar mevcut olduğunda başarısız olan istekler. Ayrıca sitenizin kurumsal bir proxy veya VPN arkasında nasıl davrandığını test etmek için de kullanışlıdır; çünkü mitmproxy bu ortamları simüle edebilir.

Dezavantajı kurulum karmaşıklığıdır. mitmproxy'nin HTTPS trafiğini yakalayabilmesi için bir root certificate yüklemeniz ve tarayıcınızı proxy kullanacak şekilde yapılandırmanız gerekir. Hızlı kontroller için curl daha hızlıdır. Derinlemesine debug için mitmproxy kurulum süresine değer.

WebPageTest: production perspektifi

WebPageTest, sayfanızı farklı konumlardaki gerçek tarayıcılardan yükleyen ve tam HTTP konuşmasını gösteren ücretsiz bir servistir. curl'den daha yavaştır, ancak CDN davranışı, DNS çözümlemesi ve TLS negotiation dahil olmak üzere gerçek kullanıcıların ne deneyimlediğini gösterir.

"Request Headers" ve "Response Headers" görünümleri, tarayıcının tam olarak ne gönderip ne aldığını gösterir. "Waterfall" görünümü, yönlendirmeler dahil her isteğin timing bilgisini gösterir. Belirli bölgelerde veya belirli ağlarda ortaya çıkan sorunları burada bulursunuz.

WebPageTest ayrıca ana belge için yönlendirme zincirini gösterir; çoğu yönlendirme sorunu burada yaşanır. Siteniz http:// adresinden https:// adresine, ardından www. adresinden non-www. adresine, sonra da / adresinden /en/ adresine yönlendiriyorsa WebPageTest üç adımı da ve her birinin ne kadar sürdüğünü gösterir.

Bu HTTP temellerini doğrulamanıza ve optimize etmenize yardımcı olan araçlar için Wux Webtools çeşitli yardımcı araçlar sunar; header analiz araçları ve yönlendirme denetleyicileri dahil olmak üzere tamamen tarayıcınızda çalışırlar ve her şeyi client-side işleyerek gizliliğinize saygı duyarlar.

Header'lar yanıltıcı olduğunda

En zor HTTP sorunları, sunucunun birbiriyle çelişen header'lar gönderdiği durumlardır. Bir Cache-Control header'ı no-cache derken, bir Expires header'ı kaynağın bir yıl boyunca geçerli olduğunu söyler. Bir Location header'ı relative URL'ye işaret ederken, Content-Location header'ı başka bir yere işaret eder. Tarayıcı hangisine güveneceğini tahmin etmek zorunda kalır ve farklı tarayıcılar farklı tahminlerde bulunur.

Bu olduğunda, ham header'ları sunucunun gönderdiği sırayla görmeniz gerekir. curl -v bunu yapar. mitmproxy de yapar. Tarayıcının DevTools'u bazen okunabilirlik için header'ları yeniden sıralar; bu da sorunu gizler.

Başka bir yaygın sorun: uygulamanız tarafından değil, bir CDN veya load balancer tarafından eklenen header'lar. Bir caching sorununu debug ediyorsanız Cache-Control header'ının uygulamanızdan mı yoksa CDN'den mi geldiğini bilmeniz gerekir. curl size nihai sonucu gösterir, ancak her header'ın nereden geldiğini söylemez. Bunun için CDN'i bypass etmeniz (origin server'a doğrudan giderek) ve header'ları karşılaştırmanız gerekir.

Yönlendirme döngüsü sorunu

Yönlendirme döngüleri production ortamındaki en yaygın HTTP sorunudur. İki sunucu bir URL'nin nereye işaret etmesi gerektiği konusunda anlaşamadığında ortaya çıkarlar: CDN origin'e yönlendirir, origin tekrar CDN'e yönlendirir. Ya da load balancer HTTP'yi HTTPS'ye yönlendirir, ancak uygulama X-Forwarded-Proto header'ını görmediği için HTTPS'yi tekrar HTTP'ye yönlendirir.

Bunu debug etmek için her adımda Location header'ı dahil olmak üzere tüm yönlendirme zincirini görmeniz gerekir. curl -L -v bunu yapar, ancak sonsuz döngüleri önlemek için 50 yönlendirmeden sonra durur. Bu sınıra ulaşıyorsanız bir yönlendirme döngünüz vardır.

Çözüm genellikle bir yapılandırma değişikliğidir: uygulamaya X-Forwarded-Proto header'ına güvenmesini söylemek veya CDN'e zaten HTTPS olan istekleri yönlendirmeyi bırakmasını söylemek. Ancak döngüyü görmeden düzeltemezsiniz ve tarayıcı pes etmeden önce size birkaç yönlendirmeden fazlasını göstermez.

İlk olarak ne kontrol edilmeli

Production ortamında bir şey bozulduğunda, şunları sırayla kontrol edin:

1. Status code: Beklediğiniz değer mi? 301 kalıcıdır, 302 geçicidir, 307 HTTP metodunu korur. Yanlış code görüyorsanız sorun yönlendirme yapılandırmanızdadır.

1. Location header: Doğru yere mi işaret ediyor? Absolute URL mi, relative URL mi? Relative URL'ler mevcut URL'ye göre çözümlenir; bu da base URL düşündüğünüz gibi değilse beklenmeyen sonuçlar üretebilir.

1. Cache headers: Tarayıcı yönlendirmeyi cache'liyor mu? 301 yönlendirmesi varsayılan olarak cache'lenir; bu da hatalı yapılandırılmış bir yönlendirmenin, düzelttikten sonra bile sitenizi saatlerce bozabileceği anlamına gelir. Tarayıcının yönlendirmeyi ne kadar süre hatırlayacağını görmek için Cache-Control ve Expires header'larını kontrol edin.

1. CORS headers: İstek cross-origin ise sunucu doğru Access-Control-Allow-Origin header'ını gönderiyor mu? Göndermiyorsa tarayıcı isteği engeller ve konsolda bir CORS hatası görürsünüz. Bunu düzeltebileceğiniz tek yer sunucunun response header'larıdır—tarayıcıda bunun etrafından dolaşamazsınız.

1. Timing: İstek ne kadar sürdü? Yavaşsa, sorun ağ gecikmesi mi yoksa sunucu işleme süresi mi? Tarayıcının DevTools'u ve WebPageTest, zamanın nereye gittiğini söyleyen timing breakdown'ları gösterir.

Tarayıcı davranışının gizlilik ve header'lar etrafında nasıl değiştiğine daha derinlemesine bakmak için 2026'da cookie'ler için ne değişti ve bu konuda ne yapmalı yazısına bakın; bu yazı son tarayıcı güncellemelerinin header ve consent etkilerini ele alır.

Önemli çıkarımlar

• curl -L -v, tarayıcı yorumu olmadan tüm yönlendirme zincirini ve tüm header'ları gösterir
• Tarayıcının Network sekmesi, caching ve CORS kararları dahil olmak üzere tarayıcının response ile ne yaptığını gösterir
• mitmproxy, tarayıcının otomatik eklediği header'lar dahil olmak üzere tarayıcının ne gönderdiğini gösterir
• WebPageTest, CDN davranışı ve bölgesel farklılıklar dahil olmak üzere gerçek kullanıcıların ne deneyimlediğini gösterir
• Yönlendirme döngüleri ve çelişkili header'lar en yaygın production sorunlarıdır ve ham HTTP incelemesi olmadan görünmezdir

FAQ

Q: curl neden tarayıcıdan farklı header'lar gösteriyor?

A: Çünkü tarayıcı header'ları otomatik olarak ekler (User-Agent, Accept, Cookie) ve caching ile CORS için kendi kurallarını izler. curl yalnızca sizin göndermesini söylediğiniz şeyleri gönderir. Tarayıcının gerçekte ne gönderdiğini görmek için mitmproxy veya tarayıcının DevTools'unu kullanın.

Q: Yalnızca bazı kullanıcılar için gerçekleşen bir yönlendirmeyi nasıl debug ederim?

A: Yönlendirmenin kullanıcının gönderdiği header'lara bağlı olup olmadığını kontrol edin: User-Agent, Accept-Language, Cookie veya IP address (X-Forwarded-For aracılığıyla). Kullanıcının gönderdiği aynı header'ları göndermek için curl kullanın veya sayfayı kullanıcının konumundan yüklemek için WebPageTest kullanın.

Q: 301 ve 302 yönlendirmeleri arasındaki fark nedir?

A: 301 kalıcıdır ve tarayıcıya yönlendirmeyi cache'lemesini söyler (bazen sonsuza kadar). 302 geçicidir ve tarayıcıya bunu cache'lememesini söyler. Hangisini kullanacağınızdan emin değilseniz 302 kullanın—daha sonra her zaman 301'e çevirebilirsiniz.

Q: Yönlendirmem curl'de çalışırken tarayıcıda neden çalışmıyor?

A: Muhtemelen tarayıcı eski bir yönlendirmeyi cache'liyordur veya tarayıcı yönlendirmeyi CORS ya da mixed content kuralları nedeniyle engelliyordur. Hatalar için tarayıcının DevTools konsolunu kontrol edin ve tarayıcının cache'lenmiş response kullanıp kullanmadığını görmek için Cache-Control header'larını kontrol edin.

Q: Bir CDN'in eklediği header'ları nasıl görürüm?

A: CDN URL'sine istek atmak için curl kullanın, ardından origin server'a doğrudan istek atmak için (CDN'i bypass ederek) tekrar curl kullanın. Header'ları karşılaştırın. Yalnızca ilk response'ta görünenler CDN'den gelmiştir.

<!-- tool-cta:start -->

💡 Bunu deneyin: Yönlendirme sorunlarının peşine düşerken, Redirect Checker tüm zinciri izler ve her atlamadaki durum kodlarını ve başlıkları gösterir.

<!-- tool-cta:end -->

Sources

• curl documentation — curl command-line seçenekleri ve davranışı için resmi referans
• HTTPie documentation — httpie sözdizimi ve özellikleri için kılavuz
• MDN Web Docs: HTTP redirections — HTTP redirect status code'ları ve davranışları hakkında kapsamlı açıklama
• WebPageTest documentation — WebPageTest sonuçlarını ve header'larını yorumlama