HTTP/2 Parmak İzi Nedir: 2026'da Protokol Seviyesinde Otomasyon Tespiti

HTTP/2 Parmak İzi Nedir ve Neden Önemlidir?

HTTP/2 parmak izi (HTTP/2 fingerprinting), bir istemcinin bağlantı kurarken gönderdiği protokol seviyesi sinyallerini analiz ederek tarayıcı ile otomasyon arasındaki farkı tespit etme yöntemidir. 2026'da anti-bot sistemleri artık sadece User-Agent başlığına veya TLS el sıkışmasına bakmıyor; bağlantının ilk frame'lerinden itibaren istemcinin kim olduğunu protokol seviyesinde çözüyor.

Bir scraping mühendisi veya güvenlik araştırmacısı olarak, eğer HTTP/2 SETTINGS frame'iniz Chrome'un değerleriyle uyuşmuyorsa, daha HTML yüklenmeden bot skoru maksimuma fırlatılıyor. Bu rehber, h2 settings frame'inin nasıl bir parmak izi oluşturduğunu, JA4H ve Akamai'nin compact h2 fingerprint string'ini, TLS ile HTTP/2 arasındaki tutarlılık gereksinimini ve ProxyHat residential proxy'leriyle tutarlı bir Chrome imzası yaymanın pratik yolunu açıklar.

Teknik Bağlam: Protokol Seviyesinde Tespit Neden Var?

HTTP/2, RFC 7540 ile 2015'te standartlaştı ve bağlantıyı çoklama (multiplexing), başlık sıkıştırma (HPACK) ve akış kontrolü (flow control) sundu. Bu özellikler esneklik sağlarken aynı zamanda istemciye özgü bir imza bırakıyor: her tarayıcı, SETTINGS frame'inde farklı parametre değerleri, farklı stream öncelikleri ve farklı pseudo-header sıralamaları gönderir.

Anti-bot sistemleri bu imzayı kullanır çünkü TLS parmak izi (JA3/JA4) artık yetersiz. Bir saldırgan curl-impersonate veya curl_cffi ile Chrome'un TLS el sıkışmasını kopyalayabilir, ama HTTP/2 katmanında farklı SETTINGS değerleri gönderirse iki katman arasında tutarsızlık ortaya çıkar. Bu tutarsızlık, tek başına TLS spoofing'inin neden artık çalışmadığının temel nedenidir.

MDN'in açıkladığı gibi, HTTP/2 binary framing layer'ı üzerine kurulu olduğu için, her frame'in byte seviyesinde incelenmesi mümkündür ve bu da fingerprinting için zengin bir veri kaynağı sağlar.

H2 SETTINGS Frame'i ve Parmak İzi Sinyalleri

HTTP/2 bağlantısı kurulduğunda, istemci hemen bir SETTINGS frame'i gönderir. Bu frame, bağlantının davranışını kontrol eden parametreleri içerir ve her tarayıcı farklı varsayılan değerler kullanır. İşte fingerprinting için kullanılan ana sinyaller:

SETTINGS Parametreleri

Anti-bot sistemleri en az şu dört SETTINGS parametresini inceler:

• HEADER_TABLE_SIZE: HPACK dinamik başlık tablosunun boyutu. Chrome varsayılanı 65536 bayt; httpx varsayılanı ise 4096 bayt. Bu tek fark bile bir bot sinyalidir.
• INITIAL_WINDOW_SIZE: Flow control için ilk pencere boyutu. Chrome 6291456 bayt gönderirken Python'un h2 kütüphanesi genellikle 1048576 veya 65535 kullanır.
• MAX_CONCURRENT_STREAMS: Eşzamanlı stream sayısı. Chrome 1000 gönderir; birçok HTTP/2 kütüphanesi bu parametreyi hiç göndermez veya farklı değer kullanır.
• ENABLE_PUSH: Server push'unun etkinleştirilip etkinleştirilmediği. Chrome 0 gönderir (push'u devre dışı bırakır); bazı kütüphaneler bu parametreyi atlar.

WINDOW_UPDATE Frame'i

SETTINGS frame'inden hemen sonra, istemci genellikle bir WINDOW_UPDATE frame'i gönderir ve connection-level flow control penceresini büyütür. Chrome, 15663105 bayt gibi spesifik bir değer gönderir. Bu değer, tarayıcı sürümüne göre değişir ve anti-bot sistemleri için ek bir fingerprint sinyali sağlar.

Stream Priority (Akış Önceliği)

HTTP/2'de her stream bir öncelik (priority) ve bağımlılık (dependency) ağacı içinde tanımlanır. Chrome, ilk isteği (stream ID 1) weight=256, dependency=0 ile gönderir ve sonraki isteklerde farklı bir öncelik yapısı kullanır. Python h2 kütüphaneleri genellikle varsayılan öncelik değerleri kullanır veya hiç öncelik frame'i göndermez.

Pseudo-Header Sıralaması (m, a, s, p)

HTTP/2'de başlıklar HPACK ile sıkıştırılır ve pseudo-header'ların sırası fingerprinting için kritiktir. Sıralama şu dört pseudo-header'a bakar:

• m: :method
• a: :authority
• s: :scheme
• p: :path

Chrome sıralaması genellikle m, a, s, p şeklindedir. Ancak bazı istemciler m, s, a, p veya m, p, a, s sıralaması kullanır. Akamai ve Cloudflare bu sıralamayı loglar ve beklenen tarayıcı imzasıyla karşılaştırır.

Akamai Compact H2 Fingerprint String

Akamai, HTTP/2 parmak izini tek bir compact string olarak ifade eder. Format yaklaşık şöyledir:

2:1:0:1:0:0:0:0:0:0:0:0:0:0:0:0
# SETTINGS:HEADER_TABLE_SIZE=65536,INITIAL_WINDOW_SIZE=6291456,
# MAX_CONCURRENT_STREAMS=1000,ENABLE_PUSH=0
# WINDOW_UPDATE=15663105
# PRIORITY: weight=256, dependency=0

Bu string, anti-bot sisteminin veritabanında Chrome 148 için beklenen değerle karşılaştırılır. Eğer istemcinin string'i farklıysa, bot skoru anında yükseltilir. Akamai h2 fingerprint formatı, sektörde fiili standart haline gelmiştir ve birçok CDN/bot koruma sağlayıcısı benzer bir yaklaşım kullanır.

JA4H Parmak İzi

JA4 ailesinin bir parçası olan JA4H, HTTP katmanında fingerprinting yapar. JA4H formatı şu yapıyı izler:

JA4H = ge11nn05enus_0000000000_0000000000
# ge = GET isteği, HTTP/2
# 11 = 11 başlık
# nn = küçük harf başlık yok
# 05 = 5 çerez
# en = Accept-Language: en-US
# us = Accept: */*

JA4H, HTTP/2 SETTINGS frame'ini doğrudan kodlamaz, ancak başlık sıralaması ve pseudo-header düzeni JA4H imzasının bir parçasıdır. Bir istemcinin JA4H değeri Chrome 148 için beklenen değerden farklıysa, bu tek başına bot tespiti için yeterli bir sinyal oluşturur.

JA4 ile H2 Settings Uyuşmazlığı: Bot Skoru Nasıl Artar

En kritik hata, TLS katmanında Chrome'u taklit edip HTTP/2 katmanında farklı değerler göndermektir. Somut bir örnek:

Bir geliştirici httpx kütüphanesini kullanır ve TLS el sıkışmasını Chrome'un JA4 imzasıyla eşleşecek şekilde ayarlar. JA4 taraması Chrome 148'i gösterir. Ama bağlantı kurulduğunda, httpx'in arka planındaki h2 kütüphanesi HEADER_TABLE_SIZE=4096 gönderir — Chrome'un 65536 değerinden 16 kat küçük. Benzer şekilde, INITIAL_WINDOW_SIZE 65535 olarak gönderilirken Chrome 6291456 bayt kullanır.

Anti-bot sistemi bu tutarsızlığı şu şekilde değerlendirir:

1. JA4 imzası Chrome 148 diyor → güven skoru yüksek başlar.
2. H2 SETTINGS frame'i inceleniyor → HEADER_TABLE_SIZE 4096, Chrome değil.
3. Sistem: "TLS sahte, HTTP/2 gerçek değil" → bot skoru maksimuma fırlatılıyor.
4. Sonuç: 403 veya sessizce bozuk veri döndürülüyor.

Bu senaryo, TLS spoofing'inin tek başına neden yetersiz olduğunu mükemmel şekilde gösterir. Protokol katmanları arasında tutarlılık şarttır.

TLS (JA3/JA4) ve HTTP/2 Uyumu

TLS el sıkışması (JA3/JA4) ve HTTP/2 SETTINGS frame'i birbirinden bağımsız görünse de, anti-bot sistemleri bunları birlikte değerlendirir. Mantık basit: gerçek bir Chrome tarayıcısı hem TLS'de hem HTTP/2'de Chrome'un imzasını yayar. İkisinden biri farklıysa, bu bir spoofing girişimidir.

Python ekosisteminde en yaygın kaçaklar:

• httpx: H2 kütüphanesi varsayılan SETTINGS değerleri kullanır, Chrome'u taklit etmez.
• aiohttp: HTTP/2 desteği sınırlı, SETTINGS frame'i özelleştirilmez.
• requests: HTTP/2 desteği yok, HTTP/1.1 kullanır — bu da farklı bir fingerprint sinyali yaratır.

Node.js tarafında benzer sorunlar var: http2 modülü ve got kütüphanesi, TLS'i spoofing yapabilir ama SETTINGS frame'i Node.js'in varsayılan değerlerini kullanır.

Neden Proxy Hala Gerekli: IP İtibar Puanlaması

Protokol spoofing'i mükemmel olsa bile — TLS, HTTP/2 SETTINGS, pseudo-header sıralaması hepsi Chrome 148 ile birebir eşleşse bile — IP adresinin itibar puanı düşükse bot tespiti tetiklenir. Anti-bot sistemleri şunları kontrol eder:

• IP'nin ASN'i datacenter mı (AWS, GCP, Azure, DigitalOcean)?
• IP daha önce bot aktivitesi için flag'lenmiş mi?
• IP'nin coğrafi konumu ile Accept-Language başlığı tutarlı mı?
• IP'den aynı anda kaç bağlantı geliyor? (100+ eşzamanlı bağlantı = bot sinyali)

Bir datacenter IP'sinden mükemmel Chrome parmak izi göndermek, "bir bot Chrome'u çok iyi taklit ediyor" sinyali verir. Gerçek bir kullanıcı datacenter IP'sinden gezinmez. Bu nedenle, residential proxy'ler protokol spoofing'inin yanında zorunludur.

ProxyHat residential proxy'leri, gerçek ISP IP'leri sağlar ve datacenter tespitini atlatmaya yardımcı olur. ProxyHat konumları arasında 190+ ülke bulunur ve her IP, gerçek bir ISP'den atanır. Bu, IP itibar puanlamasında datacenter flag'ini önler.

Pratik Uygulama: curl_cffi ve ProxyHat ile Tutarlı Chrome Parmak İzi

Protokol seviyesinde Chrome taklidi için en pratik çözüm curl_cffi kullanmaktır. curl_cffi, curl-impersonate'in Python binding'idir ve hem TLS el sıkışmasını hem HTTP/2 SETTINGS frame'ini Chrome ile birebir eşleşecek şekilde gönderir.

Temel Kurulum

pip install curl_cffi

ProxyHat Residential Proxy ile Chrome Taklidi

from curl_cffi import requests

# ProxyHat residential proxy - ABD çıkışı
proxy_url = "http://user-country-US:pass@gate.proxyhat.com:8080"

response = requests.get(
    "https://httpbin.org/headers",
    proxy=proxy_url,
    impersonate="chrome124",
    timeout=30
)

print(f"Status: {response.status_code}")
print(f"Headers: {response.headers}")
print(f"Body: {response.text[:500]}")

Bu kodda impersonate="chrome124" parametresi, curl_cffi'ye hem TLS el sıkışmasını hem HTTP/2 SETTINGS frame'ini Chrome 124'ün değerleriyle göndermesini söyler. ProxyHat residential proxy'si ise IP itibar puanlamasında datacenter tespitini önler.

Sticky Session ile Geo-Targeting

SERP takibi veya fiyat izleme için sticky session kullanmak, aynı IP'den tutarlı istekler göndermenizi sağlar:

from curl_cffi import requests

# Sticky session + Almanya çıkışı
proxy_url = "http://user-country-DE-session-myshop01:pass@gate.proxyhat.com:8080"

urls = [
    "https://example-shop.de/product/123",
    "https://example-shop.de/product/456",
    "https://example-shop.de/product/789",
]

for url in urls:
    response = requests.get(
        url,
        proxy=proxy_url,
        impersonate="chrome124",
        timeout=30
    )
    print(f"{url} → {response.status_code}")
    # Rate limit'e dikkat: istekler arasında 2-5 saniye bekle
    import time
    time.sleep(3)

SOCKS5 ile Düşük Gecikme

Gecikme敏感 uygulamalar için SOCKS5 kullanılabilir:

from curl_cffi import requests

proxy_url = "socks5://user-country-US:pass@gate.proxyhat.com:1080"

response = requests.get(
    "https://httpbin.org/ip",
    proxy=proxy_url,
    impersonate="chrome124",
    timeout=30
)
print(response.json())

Gerçek Tarayıcı ile Playwright + ProxyHat

Eğer curl_cffi bile yeterli değilse (örneğin JavaScript challenge'ları varsa), gerçek Chrome'u Playwright üzerinden ProxyHat'e yönlendirebilirsiniz:

from playwright.sync_api import sync_playwright

proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US",
    "password": "pass"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy=proxy_config
    )
    page = browser.new_page()
    page.goto("https://httpbin.org/headers")
    content = page.content()
    print(content[:500])
    browser.close()

Playwright gerçek Chromium kullandığı için TLS, HTTP/2 SETTINGS, pseudo-header sıralaması ve JavaScript ortamı hepsi gerçek Chrome ile eşleşir. Bu en güvenli yaklaşımdır ama daha yavaştır — her sayfa için ~200ms ekstra gecikme ve daha fazla bellek kullanımı.

Yaygın Hatalar ve Edge Case'ler

Hata 1: Sadece TLS Spoofing, H2 Yok

En yaygın hata: tls_client veya benzeri bir kütüphane ile TLS'i spoofing yapmak ama HTTP/2 SETTINGS'i değiştirmemek. Sonuç: JA4 Chrome diyor, h2 settings Python diyor → anında bot tespiti.

Hata 2: Yanlış Pseudo-Header Sıralaması

Bazı kütüphaneler :scheme'i :authority'den önce gönderir. Chrome sıralaması m, a, s, p iken, bu kütüphaneler m, s, a, p gönderir. Akamai bu farkı tespit eder.

Hata 3: Accept-Language ile Geo Uyuşmazlığı

ABD IP'sinden Accept-Language: de-DE göndermek, geo-fingerprint tutarsızlığı yaratır. ProxyHat'in geo-targeting özelliği ile IP coğrafi konumunu seçebilir ve Accept-Language başlığını buna göre ayarlayabilirsiniz.

Hata 4: Çok Yüksek Concurrency

100+ eşzamanlı bağlantı tek IP'den göndermek, residential proxy olsa bile bot sinyali yaratır. Gerçek kullanıcılar aynı anda 2-5 bağlantı açar. Concurrency'i düşük tutun (5-10) ve rate limiting uygulayın.

Hata 5: HTTP/3'ü Atlamak

2026'da birçok site HTTP/3 (QUIC) üzerinden de hizmet veriyor. Chrome, HTTP/3 için ayrı bir fingerprint yayar. Eğer istemciniz HTTP/3'ü desteklemiyorsa veya farklı QUIC parametreleri gönderiyorsa, bu da bir tutarsızlık sinyali olabilir. curl_cffi'nin HTTP/3 desteği sınırlıdır; bu durumda gerçek tarayıcı (Playwright) daha güvenlidir.

Uygun Kullanım: Yetkili İzleme ve Güvenlik Araştırması

Bu teknikler yalnızca yetkili kullanım için uygundur:

• Yetkili izleme: Kendi sitenizin veya izin verilen üçüncü taraf sitelerin SERP performansını takip etmek.
• Güvenlik araştırması: Kendi altyapınızda veya yazılı onay aldığınız sistemlerde penetration testing yapmak.
• Rekabet analizi: Halka açık fiyat verilerini robots.txt ve ToS'a uygun şekilde toplamak.

Bu teknikler şu amaçlar için kullanılmamalıdır: sahte hesap oluşturma, kredi kartı dolandırıcılığı, bilet/sneaker bot'larıyla haksız avantaj sağlama, veya herhangi bir platformun ToS'unu ihlal etme.

ABD'de Computer Fraud and Abuse Act (CFAA) ve AB'de GDPR, izinsiz erişimi ve kişisel verilerin toplamasını ciddi şekilde düzenler. Her scraping projesinde robots.txt'yi kontrol edin, hedef sitenin ToS'unu okuyun ve kişisel veri topluyorsanız GDPR uyumluluğunu sağlayın. Daha fazla bilgi için ProxyHat dokümantasyonuna başvurun.

Önemli Çıkarımlar

HTTP/2 parmak izi, 2026'da bot tespitinin en kritik katmanıdır. TLS spoofing tek başına yetersizdir; protokol seviyesinde tutarlılık şarttır ve residential proxy olmadan IP itibar puanlaması geçilemez.

• HTTP/2 SETTINGS frame'i fingerprinting'in temelidir: HEADER_TABLE_SIZE, INITIAL_WINDOW_SIZE ve MAX_CONCURRENT_STREAMS değerleri tarayıcıya özgüdür.
• Akamai h2 fingerprint string'i ve JA4H, anti-bot sistemlerinin standart araçlarıdır; ikisi de pseudo-header sıralamasını ve SETTINGS değerlerini kodlar.
• TLS ile HTTP/2 tutarlılığı şarttır: JA4 Chrome diyor ama H2 settings Python değerleri gönderiyorsanız, bot skoru anında maksimuma fırlar.
• curl_cffi + ProxyHat residential proxy kombinasyonu, hem protokol tutarlılığı hem IP itibar puanlaması için pratik bir çözümdür.
• Gerçek tarayıcı (Playwright) en güvenli ama en yavaş yaklaşımdır; JavaScript challenge'ları gerektiğinde kullanın.
• Etik ve yasal uyum zorunludur: CFAA, GDPR ve robots.txt kurallarına uyun.

ProxyHat ile başlamak için fiyatlandırma sayfasını inceleyebilir veya web scraping kullanım senaryosunu ve SERP takibi kullanım senaryosunu okuyabilirsiniz.