curl ile Yanıt Başlıklarını Görüntüleme

Buna önem vermemizin nedeni: Biz Geonode olarak proxy satıyoruz ve yanıt başlıkları, müşterilerimizin bize en sık sorduğu soruya — bu bir proxy sorunu mu, değil mi? — cevap vermenin en hızlı yoludur. Engelleme sayfası, hız sınırlaması ve gerçek bir hata, tarayıcıda birbirine tıpatıp benzer görünürken başlıklarda tamamen farklıdır. Retry-After içeren bir 429, çok hızlı ilerlediğiniz anlamına gelir ve bunu hiçbir proxy düzeltemez. Security-vendor başlığı içeren bir 403 ise hedefin sizi tanımladığı anlamına gelir. 407 hatası, proxy'nin kimlik bilgilerini istediği anlamına gelir. Herhangi bir değişiklik yapmadan önce başlıkları okumak, birçok tahminden kurtulmanızı sağlar. Ayrıca, curl'da bu özel durum için bir bayrak vardır — 8.7.0 sürümünde eklenen %{proxy_used} bayrağı, aktarımın bir proxy üzerinden gerçekleştiği takdirde 1 değerini döndürür. Yapılandırmanızın yürürlüğe girip girmediğinden emin olmadığınız durumlarda bu bayrak kullanışlıdır.

Dört Seçenek Bir Bakışta

En önemli satır ikincisidir ve bu alandaki karışıklıkların çoğunun kaynağıdır. Geri kalan her şey, çıktının nereye gönderileceğiyle ilgilidir.

-i

: Başlıklar ve Gövde Birlikte Günlük kullanım için tercih edilen seçenek. curl kılavuzu bunu -i, --show-headers olarak açıklamaktadır: "Çıktıda yanıt başlıklarını göster... Bu seçenek, yanıt başlıklarının verilerle aynı akışta/çıktıda kaydedilmesini sağlar."

curl -i https://example.com

HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 1256
cache-control: max-age=604800
date: Wed, 02 Sep 2026 10:14:22 GMT

<!doctype html>...

Başlıklar, boş bir satır, ardından gövde — kablo formatıyla aynı yapı.

Eski materyalleri okuyanların dikkatini çekecek bir adlandırma notu: uzun biçim artık --show-headers şeklindedir. Eskiden --include idi ve her ikisi de çalışır, ancak güncel belgelerde yeni ad kullanılmaktadır.

Bilmeniz gereken iki ayrıntı var. Çıktı bir terminale gönderildiğinde, curl başlık adlarını kalın olarak biçimlendirebilir ve Location: URL'lerini işaretleyebilir; bu, etkileşimli kullanımda yararlıdır ancak bir iş akışında istenmeyen bir durumdur — --no-styled-output bu özelliği devre dışı bırakır. Ayrıca, başlıklar ve gövde aynı akışı paylaştığı için, -i ile -o file komutları her ikisini de dosyaya yazar; bu ise neredeyse hiçbir zaman istediğiniz bir durum değildir. Bu durumda -D komutunu kullanın.

-I: Yalnızca Başlıklar ve Neden Yanıltıcı Olabilir

-I şu şekilde belgelenmiştir: "Yalnızca başlıkları alır. HTTP sunucuları, bir belgenin başlığından başka hiçbir şey almamak için kullanılan HEAD komutuna sahiptir."

Bunu dikkatlice okuyun. Yanıtı almaz ve gövdeyi atmaz. Farklı bir HTTP yöntemi gönderir.

curl -I https://example.com

Bu bir HEAD isteğidir ve sonuçları gerçektir:

Bazı sunucular HEAD'i farklı şekilde işler. Bir HEAD farklı başlıklar veya farklı bir durum kodu döndürebilir ya da 405 Method Not Allowed ile tamamen reddedilebilir — oysa eşdeğer GET mükemmel şekilde çalışır.

Bazı çerçeveler HEAD isteği için istek gövdesini hesaplamaz; bu nedenle Content-Length, ETag ve Content-Type öğeleri eksik veya hatalı olabilir.

CDN'ler ve önbellekler genellikle HEAD isteğini ayrı bir önbellek anahtarı olarak değerlendirir; bu nedenle önbellek başlıkları, gerçek bir isteğin göreceğinden farklı olabilir.

Bot önleme sistemleri farklı şekilde yanıt verebilir. Olağandışı bir istemciden gelen bir HEAD isteği başlı başına bir işarettir ve aldığınız doğrulama sorusu, GET adresinin üreteceği doğrulama sorusu olmayabilir.

Bu nedenle -I, hızlı kontroller için mükemmeldir — bu URL aktif mi, nereye yönlendiriyor, dosya ne kadar büyük — ancak GET adresinin neden garip davrandığını hata ayıklamak için güvenilir değildir. Gerçek bir isteği teşhis ederken, gerçek yöntemi kullanın:

curl -sS -o /dev/null -D - https://example.com

Bu komut, normal bir GET işlemi gerçekleştirir, istek gövdesini /dev/null adresine yönlendirir ve başlıkları standart çıktıya yazdırır. İsteği değiştirmeden, -I adresinin size sunduğu bilgileri sağlar.

Özellikle bir POST isteğinin başlıklarına ihtiyacınız varsa, aynı yöntem geçerlidir:

curl -sS -o /dev/null -D - -X POST -H "Content-Type: application/json" \
     -d '{"a":1}' https://api.example.com/items

-D ve -v: Akışları Ayırma ve İstekleri Görüntüleme

-D, başlıkları ayrı bir hedefe yazar. Kullanım kılavuzu: "Alınan protokol başlıklarını belirtilen dosyaya yazın... stdout'a yazılması için dosya adı olarak '-' (tek bir eksi işareti) belirtin." Ayrıca, başlık alınmazsa bu seçeneğin "boş bir dosya oluşturduğu" da belirtilmektedir — ki bu da başlı başına bir tanılama bilgisidir.

curl -D headers.txt -o body.html https://example.com

Komut dosyalarında istediğiniz şey olan net bir ayrım. -D - başlıkları stdout'a gönderirken, gövde -o'un işaret ettiği yere gider ve bu kombinasyon yukarıdaki modelin temelini oluşturur.

-v komutu da isteği gösterir; bu, genellikle gerçekten ihtiyacınız olan kısımdır. Kılavuzda önekler şu şekilde açıklanmaktadır:

Ayrıntılı çıktı satırlarının başında harfler bulunur: > curl tarafından gönderilen başlık, < curl tarafından alınan başlık, } curl tarafından gönderilen veriler, { curl tarafından alınan veriler, * curl tarafından sağlanan ek bilgiler.

curl -v https://example.com 2>&1 | grep '^>'

Bu, curl'ün tam olarak ne ilettiğini gösterir — ki bu genellikle sizin yapılandırdığınız şey değildir, çünkü kütüphaneler, varsayılan ayarlar ve .curlrc dosyaları başlıkları ekler ve geçersiz kılar. "Sunucu başlığımı yok sayıyor" şeklindeki pek çok sorun burada çözülür.

Ayrıntılı çıktının stderr'e gittiğine dikkat edin; bu nedenle, boruya aktarımdan önce 2>&1 komutunun kullanılması gerekir. Bu kasıtlıdır: stdout'taki gövdeyi temiz tutar.

Kılavuzda ayrıca, curl 8.10'dan itibaren -v komutunun tekrarlanmasının izleme düzeyini artırdığı belirtilmektedir. Gerçekten düşük seviyeli çalışmalar için, --trace-ascii komutu "açıklayıcı bilgiler dahil olmak üzere tüm gelen ve giden verilerin tam bir izleme dökümünü" verir; okunabilir kalması için onaltılık değerler çıkarılır.

Kılavuzda yer alan ve tekrar edilmeye değer bir uyarı: izleme ve ayrıntılı çıktı "kullanıcı adları, kimlik bilgileri veya gizli veri içeriği dahil olmak üzere hassas veriler içerebilir. İzleme günlüklerini başkalarıyla paylaşırken dikkatli olun ve özen gösterin." Bir URL'de aktarılan proxy kimlik bilgileri, ayrıntılı çıktıda görünür. Bir sorun izleme sistemine yapıştırmadan önce bu bilgileri gizleyin.

%{header_json}

ile Makine Tarafından Okunabilir Başlıklar Çoğu kişinin hiç görmediği, curl 7.83.0 sürümünde eklenen bu seçenek, başlık metnine yönelik bir düzenli ifade yazmak üzere olduğunuzda her zaman doğru cevaptır.

Kılavuzda bu özellik şöyle açıklanmaktadır: "Son aktarımdaki tüm HTTP yanıt başlıklarını içeren bir JSON nesnesi. Değerler, birden fazla başlık olması durumunda birden fazla değer olabileceğinden, diziler halinde sağlanır." Başlık adları "küçük harflerle, ağ üzerinden göründükleri sırayla listelenir"; yinelenenler ise "o başlığın ilk geçtiği yerde gruplandırılır ve her değer JSON dizisinde sunulur".

curl -s -o /dev/null -w '%{header_json}' https://example.com | jq

{
  "content-type": ["text/html; charset=UTF-8"],
  "cache-control": ["max-age=604800"],
  "set-cookie": ["a=1; Path=/", "b=2; Path=/"]
}

Bu, aynı anda üç sorunu çözer. Adlar küçük harfe dönüştürülür, böylece büyük/küçük harf duyarlı eşleştirme sorunu ortadan kalkar. Set-Cookie gibi tekrarlanan başlıklar, sessizce birleştirilmek yerine diziler halinde gelir. Ayrıca çıktı, bir ayrıştırıcı yazmaya gerek kalmadan ayrıştırılabilir.

Tek bir başlığı çıkarmak çok kolay hale gelir:

curl -s -o /dev/null -w '%{header_json}' "$URL" | jq -r '.["retry-after"][0] // "none"'

Bununla iyi eşleşen diğer -w değişkenleri:

curl -s -o /dev/null -w 'status=%{response_code} redirects=%{num_redirects} proxy=%{proxy_used} ip=%{remote_ip}\n' "$URL"

response_code son aktarımın durumudur, num_redirects takip edilen yönlendirmeleri sayar, redirect_url -L kullanmadığınızda bir yönlendirmenin nereye gideceğini gösterir, remote_ip aslında bağlanılan adrestir ve proxy_used bir proxy söz konusuysa 1 değerini döndürür. Sonuncusu, bir NO_PROXY kalıbının ana bilgisayarınızı sessizce hariç bırakmış olabileceği durumlarda gerçekten kullanışlıdır.

Yönlendirme Zincirlerini Takip Etme

-L

seçeneği kullanılmadığında, curl ilk yönlendirmede durur ve yalnızca o yanıtı görürsünüz. -L

seçeneği ile curl, zincirdeki her yanıtın başlıklarını gösterir:

curl -sSL -o /dev/null -D - https://example.com

HTTP/2 301
location: https://www.example.com/

HTTP/2 200
content-type: text/html

Her blok bir atlamadır. Bir URL'nin üç kez yönlendirme yaptığını, bir atlamada düz HTTP'ye geçtiğini veya bir yönlendirmede çerezin kaybolduğunu bu şekilde öğrenebilirsiniz.

Hatırlamaya değer iki örnek:

curl -sSL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' "$URL"

Tek satırda sayı ve nihai hedef. Yönlendirmenin nereye gittiğini takip etmeden görmek istediğinizde:

curl -s -o /dev/null -w '%{redirect_url}\n' "$URL"

Yönlendirme zincirlerini genellikle düşünülenden daha sık incelemek faydalıdır. Her atlama bir gidiş-dönüş yolculuğudur; dört atlamadan oluşan bir zincir gerçek gecikmeye neden olur ve farklı bir ana bilgisayardan geçen beklenmedik bir atlama, genellikle çerez veya CORS sorunlarının nedenidir.

Proxy Üzerinden Başlıklar

Resme eklenen iki unsur var; her ikisi de ilk bakışta kafa karışıklığına neden oluyor.

CONNECT yanıtları ayrıntılı çıktıda görünür. HTTP proxy üzerinden HTTPS için, curl önce bir tünel kurmak üzere CONNECT komutunu verir ve bu veri alışverişinin kendine özgü başlıkları vardır:

curl -v -x http://proxy.example.com:8080 https://example.com

CONNECT 'i, proxy'den gelen bir HTTP/1.1 200 Connection established 'i ve ancak ondan sonra gerçek isteği göreceksiniz. Bu ilk blok, hedef değil, proxy'nin ilettiği bilgilerdir. Bunları karıştırmak, başlangıçta sıkça yapılan bir hatadır. Yalnızca hedefin yanıtıyla ilgileniyorsanız, --suppress-connect-headers komutu bunları çıktından kaldırır.

%{http_connect} , proxy'nin yanıt kodunu özellikle CONNECT isteğine ilişkin olarak, hedefin durumundan ayrı bir şekilde bildirir. Bir şey başarısız olduğunda ve hangi aşamanın reddedildiğini bilmediğinizde, tam da bu ayrım size gereklidir:

curl -s -o /dev/null -x "$PROXY" \
  -w 'connect=%{http_connect} status=%{response_code} proxy=%{proxy_used}\n' \
  https://example.com

connect=200 status=403 , proxy'nin çalıştığı ancak hedefin sizi reddettiği anlamına gelir. connect=407 ise proxy'nin kimlik bilgilerini istediği ve hedefe hiç ulaşamadığı anlamına gelir. Bu iki durumun çözümleri tamamen farklıdır ve bu ayrım yapılmazsa, uygulama açısından birbirinin aynısı gibi görünürler.

Ayrıca, bir tünel üzerinden yapılan HTTPS bağlantılarında proxy'nin başlık ekleyemeyeceğini veya okuyamayacağını unutmayın — proxy yalnızca şifrelenmiş baytları iletir. Bir HTTPS yanıtında beklenmedik başlıklar görürseniz, bunlar proxy'den değil, hedef sunucudan veya onun önündeki bir CDN'den gelmiştir.

Başlıklar Aslında Size Neler Anlatıyor?

Bütün bunların amacı budur. Bunları doğru bir şekilde okumak, tahmin etmeyi tanıya dönüştürür.

Önce durum satırı. 200 başarılı oldu. 301/302 yönlendirildi. 403 reddedildi. 429 hız sınırlamasına uğradı. 407 proxy kimlik doğrulaması. 502/503 kaynak sunucuda sorun var.

Retry-After, 429 ve 503 ile birlikte görünür ve tam olarak ne kadar beklemeniz gerektiğini belirtir. Bu süreye uymak hem doğru hem de çalışır duruma dönmenin en hızlı yoludur. Bunu göz ardı edip hemen yeniden denemek, geçici bir sınırlamanın daha uzun süreli bir sınırlamaya dönüşmesine neden olur.

Content-Type size gerçekte ne aldığınızı gösterir. Bir API uç noktasında text/html hatası, JSON değil bir hata sayfası aldığınız anlamına gelir ve bu, ayrıştırma hatalarının büyük bir kısmının nedenidir.

Content-Length ile gelen verinin karşılaştırılması. Bildirilen uzunluğu büyük olan kısa bir gövde, kesilme olduğunu gösterir.

Önbellek başlıkları — Cache-Control, ETag, Last-Modified — yeniden veri almanın önlenip önlenemeyeceğini gösterir. Sonraki isteklerde If-None-Match ve If-Modified-Since değerlerinin görülmesi, tam bir aktarımın 304 haline gelmesini sağlar; bu da bant genişliği kısıtlamalı bağlantılarda doğrudan tasarruf anlamına gelir.

Set-Cookie, sunucunun hangi oturum durumunu kurduğunu gösterir; beklediğiniz yerde bunun bulunmaması, birçok kimlik doğrulama sorununu açıklar.

Server ve satıcıya özgü başlıklar, kaynağın önünde ne olduğunu belirler. Bir güvenlik satıcısının başlıklarını içeren ve 403 ile başlayan bir yanıt, engellemenin uygulamadan ziyade bir koruma katmanından geldiğini gösterir — bu, farklı bir yanıt gerektiren farklı bir sorundur.

Standart dışı başlıklar. Hız sınırlama kotaları, istek tanımlayıcıları ve API'ye özgü meta veriler genellikle x-önekli başlıklar olarak görünür ve çoğu zaman yanıt içindeki en yararlı bilgilerdir. Destek ekibi, istek kimliğini soracaktır.

Sık Sorulan Sorular

curl ile yanıt başlıklarını nasıl görebilirim?

curl -i URL komutu, başlıkların ardından istek gövdesini gösterir. curl -D - URL komutu, başlıkları stdout’a ayrı olarak yazdırır. curl -v URL komutu ise hem istek hem de yanıt başlıklarını gösterir. Gerçek bir isteği hata ayıklarken -I komutunu kullanmaktan kaçının, çünkü bu komut GET yerine HEAD isteği gönderir.

curl'da -i ve -I arasındaki fark nedir?

-i, gerçek isteğinizin gövdesinin yanı sıra yanıt başlıklarını da içerir. -I ise bunun yerine bir HEAD isteği gönderir; dolayısıyla bu, potansiyel olarak farklı sonuçlar verebilecek farklı bir istektir. Hata ayıklamayı yaptığınız isteğin başlıklarına ihtiyacınız olduğunda -i veya -o /dev/null -D - komutlarını kullanın.

Gövdeyi hariç tutarak yalnızca başlıkları nasıl görebilirim?

curl -sS -o /dev/null -D - URL. Bu komut normal bir GET isteği gerçekleştirir, gövdeyi atar ve başlıkları görüntüler. HTTP yöntemini değiştirmeden -I adresinin sunduğu bilgileri size sağlar; bu önemlidir çünkü bazı sunucular HEAD isteğine farklı şekilde yanıt verir veya bu isteği doğrudan reddeder.

curl'un gönderdiği istek başlıklarını nasıl görebilirim?

curl -v URL adresine gidin ve > ile başlayan satırları arayın; bunlar curl'un gönderdiği başlıklardır. Ayrıntılı çıktı stderr'e gönderilir, bu yüzden filtrelemek istiyorsanız 2>&1 ile boru bağlantısı yapın. Bu şekilde, yapılandırdığınız başlığın gerçekten iletildiğini doğrulayabilirsiniz.

Curl başlıklarını JSON olarak nasıl alabilirim?

curl -s -o /dev/null -w '%{header_json}' URL. Curl 7.83.0 sürümünde eklenen bu özellik, tüm yanıt başlıklarını küçük harfli adlara ve dizi değerlerine sahip bir JSON nesnesi olarak gönderir; böylece Set-Cookie gibi tekrarlanan başlıklar, birleştirilmek yerine korunur. Alanları ayıklamak için jq komutuna yönlendirin.

Proxy kullanırken neden iki ayrı başlık grubu görüyorum?

HTTP proxy üzerinden HTTPS bağlantısı kurulurken, curl önce bir tünel açmak için CONNECT komutunu gönderir ve proxy'nin buna verdiği yanıt, hedefin yanıtından önce görünür. Bunu gizlemek için --suppress-connect-headers komutunu, proxy'nin durum kodunu hedefinkinden ayrı olarak okumak için ise %{http_connect} komutunu kullanın.

Her yönlendirme için başlıkları nasıl görebilirim?

-L ekleyerek curl'ün yönlendirmeleri takip etmesini sağlayın ve -D - veya -i kullanın — curl, zincirdeki her yanıtın başlıklarını, her atlama için bir blok halinde yazdırır. %{num_redirects} ve %{url_effective} komutları, sayıyı ve son URL'yi tek bir satırda gösterir.

Yanıt başlıkları, engellenip engellenmediğimi gösterir mi?

Çoğu zaman evet, üstelik yanıt gövdesi kadar güvenilir bir şekilde. 429 adresinde Retry-After ifadesinin bulunması, hız sınırlaması olduğunu gösterir. Bir güvenlik sağlayıcısının başlıklarını taşıyan 403 adresi, bir koruma katmanıdır. Bir API uç noktasında 200 adresinde Content-Type: text/html ifadesinin bulunması, bir kimlik doğrulama veya oturum açma sayfasıdır. Her biri farklı bir çözüm gerektirir ve bunları birbirinden ayıran tek şey başlıklardır.

Sonuç

Dört seçenek ve yaygın bir tuzak. Günlük denetimler için -i, başlıkları gövdeden ayrı görmek istediğinizde -D -, gönderdiğiniz verilerin yanı sıra geri gelenleri de görmeniz gerektiğinde -v ve yalnızca hızlı çalışırlık kontrolleri için -I — çünkü bu komut bir HEAD isteği gönderir ve sunucular bir HEAD isteğine bir GET isteğinden farklı şekilde yanıt verme hakkına sahiptir.

Buradan tek bir şey çıkaracaksanız, benimsemeye değer seçenek şudur: %{header_json}. Şu anda başlık metnini düzenli ifadeyle ayrıştıran herhangi bir komut dosyası bunun yerine bunu kullanmalıdır: küçük harfli adlar, tekrarlanan başlıklar için diziler ve jq'ın okuyabileceği çıktı. %{response_code}, %{num_redirects} ve %{proxy_used} ile birlikte kullanıldığında, başlık incelemesini gözle kontrol etmek yerine doğrulayabileceğiniz bir şeye dönüştürür.

Bir istek ters gittiğinde ise, herhangi bir değişiklik yapmadan önce başlıkları okuyun. Durum kodu, Retry-After, Content-Type ve bunların arasındaki herhangi bir satıcı başlığı genellikle sorunu doğrudan belirtir — bu, bir şey çalışana kadar ayarları değiştirip durmaktan daha iyidir ve yaklaşık on saniye sürer.