Puppeteer kullanırken sık karşılaşılan hata deseni şöyledir: ilk birkaç istek sorunsuz gider, ama sonrasında 403 ya da 429 hataları almaya, zaman aşımına uğramaya ya da doğrulama sayfasına yönlendirilmeye başlarsınız. Buna rağmen birçok rehber, proxy rotasyonunu sanki iki satırlık bir ayar değişikliğiymiş gibi anlatır.
Aslında o kadar basit değil. "--proxy-server bayrağını ekleyin" örneğiyle, gerçekten uzun süre dayanan bir sistem kurmak tamamen farklı şeyler. Bu rehber; tarayıcı başına tam rotasyon, kimlik doğrulama gerektiren gateway’ler, tarayıcı sharding veya harici yönlendiriciler, tutarlı tarayıcı profilleri, üretim seviyesinde hata yönetimi ve proxy yönetiminin kendisinden ne zaman tamamen vazgeçmeniz gerektiğine dair dürüst bir değerlendirmeyi bir arada ele alıyor.
Dönen Proxy Nedir ve Puppeteer Neden Buna İhtiyaç Duyar?
Proxy, Puppeteer örneğiniz ile istek gönderdiğiniz site arasına girer. Site, sizin bilgisayarınızı değil, proxy’nin outbound IP’sini görür. Dönen proxy, bu outbound IP’yi sürekli değiştirir. Bazen her istekte, bazen her oturumda değiştirerek, trafiğin tek bir istemcinin sunucuya art arda yüzlerce kez yüklendiği gibi görünmesini engeller.
Puppeteer’ın özellikle bu yönteme ihtiyaç duymasının nedeni açık: tek bir IP’den art arda yüzlerce istek gönderen headless Chrome, tam olarak anti-bot sistemlerinin yakalamak üzere tasarlandığı örüntüdür. Cloudflare’ın resmi dokümantasyonuna bakarsanız, birden fazla tespit katmanının aynı anda çalıştığını görürsünüz: kural tabanlı değerlendirme, JavaScript fingerprint kontrolleri, makine öğrenmesi modelleri ve davranışsal anomali tespiti. IP rotasyonu bu katmanlardan yalnızca birine dokunur. Sadece bir tanesine.
Bilmeniz gereken üç proxy türü var ve bunlar birbirinin yerine geçmez.
- Datacenter proxy’ler — ucuz, hızlı ve hosting şirketlerinden gelir. ASN’leri (ağ blokları) açıkça veri merkezi olarak sınıflandırıldığı için sitelerin fark etmesi kolaydır.
- Residential proxy’ler — gerçek tüketici ISP’leri üzerinden geçtiği için, gerçek bir ev interneti gibi görünür. Daha yavaş ve daha pahalıdır ama çok daha inandırıcıdır.
- Mobile proxy’ler — operatör ağı IP’leridir. Genellikle en pahalısıdır, ama gerçek bir mobil ağ kimliğine ihtiyaç duyduğunuzda işinize yarar.
Residential çıkışlar, yalnızca ASN sınıflandırmasına bakıldığında datacenter çıkışlarından daha az şüpheli görünebilir, ama hiçbir kategori engellenmeye karşı bağışık değildir. Evrensel bir tespit oranı diye bir şey yoktur. Sonuç; hedef siteye, çıkışın itibarına, konumuna, oturum geçmişine, tarayıcı profiline ve istek desenine göre değişir.
İnsanların sık karıştırdığı bir başka ayrım daha var. Kendi yönettiğiniz sabit bir listeyi döndürmek (havuzu siz yönetirsiniz, bir sonraki IP’yi siz seçersiniz, arızaları da siz ele alırsınız) ile backconnect/gateway proxy (tek bir uç noktaya bağlanırsınız, sağlayıcı arka planda çıkış IP’lerini değiştirir) aynı şey değildir. İkisi de geçerli yaklaşımlardır, sadece karmaşıklığın nerede yaşandığı değişir.
Puppeteer’da Neden Dönen Proxy Kurulur? Yaygın Kullanım Senaryoları
Açıkçası, gerçekten ihtiyaç duyana kadar rotasyonu hiç kullanmayabilirsiniz. Ama tam da ihtiyaç duyduğunuz an, neredeyse acil bir durum gibi hissettirir.
| Kullanım Senaryosu | Rotasyon Neden Önemli? |
|---|---|
| Ürün kataloglarında fiyat takibi | Tek IP’den gelen tekrarlanan katalog istekleri hız limiti ve itibar sinyalleri biriktirebilir |
| Lead zenginleştirme / iletişim verisi çıkarma | Tek IP’den yapılan tekrarlanan profil ziyaretleri gezinme değil scraping gibi görünür ve davranış motorları tarafından işaretlenebilir |
| SERP scraping | Arama motorları IP tabanlı hız kısıtlama ve CAPTCHA engelleme konusunda en agresif sistemler arasındadır |
| Rakip istihbaratı | Aynı alan adını günler boyunca tekrar tekrar scrape etmek, IP’niz ve çerez geçmişinizle ilişkilenen bir parmak izi oluşturur |
| İçerik toplama | Yüksek sayfa hacmi, sayfa başına düşük değer — bot tespitinin özellikle yakalamaya ayarlı olduğu trafik tipi budur |
"Amazon 51. istekte engelliyor" gibi güvenip kullanabileceğiniz sabit bir sayı yoktur. Siteler global eşiklerini yayınlamaz ve kontrol yöntemleri de uç noktaya, hesap durumuna, ASN itibarına ve trafik desenine göre değişebilir. Bu yüzden en düşük istek hızıyla başlayın, yalnızca durum koduna değil gerçek içeriğe de bakın. Rotasyonu yalnızca ölçtüğünüz davranış ve hedef sitenin politikası gerçekten gerektirdiğinde ekleyin.
Puppeteer’da Üç Proxy Rotasyon Stratejisi: Hangisine İhtiyacınız Var?
Çoğu eğitim burada işi kısa geçer, ya da daha kötüsü, yalnızca en kaba yöntemi gösterir. Gerçekte üç farklı seviye vardır ve yanlış seçim yaparsanız ya zaman kaybedersiniz ya da tam tersine çok basit bir sorunu gereksiz yere karmaşıklaştırırsınız.
| Rotasyon Stratejisi | Ayrıntı Seviyesi | Tarayıcı Yeniden Başlatma Gerekir mi? | Karmaşıklık | En Uygun Olduğu Durum |
|---|---|---|---|---|
Tarayıcı başına (--proxy-server) | Tarayıcı örneği başına 1 proxy | Evet | Düşük | Basit, düşük hacimli scraping |
Gateway yönetimli (proxy-chain + backconnect uç noktası) | Sağlayıcı/oturum politikası | Hayır | Orta | Kimlik doğrulamalı dönen gateway’ler |
| Tarayıcı parçalama veya harici aktarıcı | Her tarayıcı parçası ya da aktarıcı kuralı başına 1 proxy | Tek işlem içinde doğrudan değişim yok | Yüksek | Kontrollü eşzamanlılık ve ince ayrıntılı yönlendirme |
Seçim yapmadan önce belirtilmesi gereken bir nokta var. Puppeteer’ın network interception dokümantasyonu, setRequestInterception ile istek başına temiz bir şekilde proxy değiştirmenin mümkün olmadığını açıkça belirtir. Interception edilen her istek, siz açıkça devam ettirene, bir yanıt verene veya iptal edene kadar askıda kalır. Gerçek istek bazlı proxy routing genellikle interception handler’ın içinde doğrudan iletimi değiştirmek yerine, isteği yerel, programlanabilir bir gateway (örneğin proxy-chain) üzerinden geçirmek şeklinde yapılır. Aşağıdaki Method 3’e geçmeden önce bunu aklınızda tutun.
Puppeteer’da Dönen Proxy Nasıl Kurulur: Adım Adım Kılavuz
Zorluk: Orta
Süre: Üç yöntemin tamamı için yaklaşık 30-45 dakika
Gerekenler: Node.js 18+, npm, proxy listesi veya sağlayıcı hesap formatı (protocol://user:pass@host:port) ve puppeteer, proxy-chain, puppeteer-extra paketleri
Ön Koşullar: Başlamadan Önce İhtiyacınız Olanlar
Temel paketleri kurun.
npm install puppeteer proxy-chain puppeteer-extra puppeteer-extra-plugin-stealth
Sağlayıcınızdan bir proxy listesi alın, ya da en azından gerçek istek hacmine geçmeden önce kodunuzu doğrulayacak birkaç test proxy’si hazırlayın. Gerçek bir üretim ortamı düşünüyorsanız residential proxy daha iyidir. Kimlik bilgilerini ortam değişkenlerinde saklayın, asla kodun içine gömmeyin. URL’nin içine koymaktan da kaçının ve loglara sızmasına izin vermeyin.
Yöntem 1: --proxy-server ile Tarayıcı Başına Proxy Rotasyonu
Bu yöntem herkesin ilk başladığı temel yaklaşımdır ve bunun iyi bir nedeni var: öngörülebilir olması. Puppeteer’ın LaunchOptions dokümantasyonu, Chrome komut satırı bayraklarını iletmek için args kullanımını desteklenen bir yöntem olarak açıklar ve --proxy-server Chromium’un yerleşik bir bayrağıdır.
import puppeteer from 'puppeteer';
const proxyPool = [
'http://proxy1.example:8080',
'http://proxy2.example:8080',
'http://proxy3.example:8080',
];
let proxyIndex = 0;
async function scrapeWithRotation(url) {
const proxy = proxyPool[proxyIndex % proxyPool.length];
proxyIndex++;
const browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${proxy}`],
});
const page = await browser.newPage();
// Proxy kimlik doğrulaması gerekiyorsa, bu adım herhangi bir yönlendirmeden önce çalışmalı
await page.authenticate({
username: process.env.PROXY_USER,
password: process.env.PROXY_PASS,
});
await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30_000 });
const content = await page.content();
await browser.close(); // proxy değiştirmeden önce kapatın
return content;
}
page.authenticate() fonksiyonunun Puppeteer içinde sessizce request interception’ı devreye soktuğunu da unutmayın — resmi dokümantasyona göre durum bu. Performans açısından büyük bir maliyeti yok, ama özellikle işler beklediğinizden yavaş gittiğinde bilmekte fayda var.
Beklenen sonuç: Her çağrıda farklı bir proxy’ye bağlı yeni bir tarayıcı açılır. Değiştirmek için tarayıcıyı kapatıp yeniden başlatmanız gerekir — bundan kaçış yok. 50 sayfa scrape etmeniz gerekiyorsa, yalnızca tarayıcı açma süresi bile bu yöntemi diğer iki yöntemden belirgin şekilde yavaş yapar.
Ne zaman kullanılır: Düşük eşzamanlılıklı scriptlerde, tek seferlik scrape işlerinde, hızdan çok debug kolaylığının önemli olduğu durumlarda.
Yöntem 2: proxy-chain ile Kimlik Doğrulamalı Dönen Gateway
Chrome, proxy URL’sinin içindeki user:pass@host biçimindeki kimlik bilgilerini doğrudan kabul etmez. proxy-chain paketi (Apify tarafından yönetilir), kimlik doğrulama gerektiren upstream’e giden anonim bir yerel proxy başlatarak bu sorunu çözer. Upstream, sağlayıcının dönen ya da backconnect gateway’iyse, sağlayıcının oturum politikasına göre o tek uç noktanın arkasındaki outbound IP değişir. proxy-chain’in kendisi zaten açık olan bir Puppeteer page’ine başka bir proxy’yi zorla enjekte edemez.
import puppeteer from 'puppeteer';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
async function scrapeThroughGateway(upstreamProxyUrl, targetUrl) {
const localProxy = await anonymizeProxy(upstreamProxyUrl);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`],
});
const page = await browser.newPage();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true); // her zaman temizleyin
}
}
Bu finally bloğu süs değil. Temizlenmeyen yerel proxy sunucuları port sızıntısına yol açar, ve anonimleştirilmiş proxy’yi kapatmamak, scraper’ın gece boyunca sessizce file descriptor tüketmesi gibi gerçek bir soruna da yol açabilir. proxy-chain, hata sınıflandırması için özellikle kullanışlı kodlar da sunar: DNS sorunları için 593, bağlantı reddi için 594, kimlik doğrulama hatası için 597. Bu konuya birazdan geri döneceğiz.
Ne zaman kullanılır: Rotasyonun sağlayıcı uç noktası veya oturum parametreleri tarafından kontrol edildiği, kimlik doğrulamalı residential/datacenter gateway’lerde. Aynı anda birden fazla sabit proxy kimliği kullanmanız gerekiyorsa, browser sharding’i ya da bu amaca uygun tasarlanmış harici bir yönlendirici kullanın. Yerel Puppeteer, page bazında proxy ayarını varsayılan olarak desteklemez.
Yöntem 3: İstek Bazlı Yönlendirme İçin Harici Bir Aktarıcı Gerekir
Bu en ince ayrıntılı seçenektir. Teoride, sayfa içindeki her görsel, script ve API çağrısı için farklı bir outbound kullanabilirsiniz. Ama gerçekte Puppeteer’ın request interception’ı, isteğe göre ağ iletimini değiştirmek için değil, istekleri filtrelemek ve ele almak için tasarlanmıştır — bu yüzden en kırılgan ve en az belgelenmiş yaklaşımdır.
import puppeteer from 'puppeteer';
async function inspectRequests(url) {
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on('request', async (request) => {
// Pratikte gerçek istek bazlı proxy değişimi, tarayıcının taşımasını
// uçuş sırasında değiştirmek yerine yerel bir aktarıcı (proxy-chain)
// üzerinden yönlendirme gerektirir — Chrome bunu desteklemez.
// Üretim kurulumlarının çoğu bu handler’ı kaynak türlerini filtrelemek/
// iptal etmek için kullanır ve bunu tarayıcı parçalama veya gateway ile eşleştirir.
if (['image', 'font', 'stylesheet'].includes(request.resourceType())) {
request.abort();
} else {
request.continue();
}
});
await page.goto(url, { waitUntil: 'networkidle2' });
await browser.close();
}
Dürüst değerlendirme: Puppeteer içinde istek başına IP değiştirmek setRequestInterception() ile çözülmez. Gerçekten bu seviyede ayrıntılı kontrole ihtiyacınız varsa, Chrome’u programlanabilir harici bir yönlendiricinin arkasına koyun ya da proxy session’ı merkeze alan bir scraping framework kullanın. Çoğu projede, browser shard başına bir proxy ya da sağlayıcı tarafından yönetilen dönen bir gateway, işletmesi ve izlemesi çok daha kolaydır.
Tam Anti-Tespit Yığını: Sadece Dönen Proxy’ler Yasaklanmanızı Önlemez
En yaygın şikayet şu: "Proxy kullanmama rağmen sürekli engelleniyorum." Ama IP adresi, modern bot sistemlerinin görebildiği sinyallerden yalnızca biri. Diğer tüm sinyaller aynı kalırken sadece IP’yi değiştirmek, aslında daha büyük bir anomaliye yol açabilir. Windows Chrome’muş gibi davranırken client hints, saat dilimi ve yerel ayarları tamamen farklı olan bir tarayıcı, bunun tipik bir örneğidir.
Katman 1: Dönen Residential Proxy’ler
Daha önce açıklandığı gibi, residential çıkışlar genellikle datacenter çıkışlarından daha güvenilir görünür. Ama minimum pool size gibi evrensel bir kriter yok. Pool size’ı rastgele bir IP sayısına göre değil, gerçek istek hacmine, oturum süresine, bekleme süresine ve sağlayıcının yeniden kullanım desenine göre belirleyin.
Katman 2: Headless Chrome Sinyallerini Gizlemek İçin Stealth Eklentisi
puppeteer-extra-plugin-stealth, bilinen bazı headless izlerini yamar. Örneğin navigator.webdriver, WebGL vendor string’i, eksik Chrome runtime nesneleri ve birkaç CDP sızıntısı gibi noktaları ele alır. Gerçekten oldukça kullanışlı bir uyumluluk katmanı. Ama projenin README’sinin de açıkça belirttiği gibi, bu bir kedi-fare oyunu ve tam koruma muhtemelen mümkün değil. Bunu bir garanti değil, temel bir savunma seviyesi olarak görün.
Katman 3: Tutarlı Tarayıcı Profilleri ve Ölçülü İstek Hızı
User-agent string’i, tarayıcının bildirdiği diğer tüm değerlerle içsel olarak tutarlı olmalıdır. Chrome’un User-Agent Client Hints özelliği yapılandırılmış platform verisi sağladığından, elle yazılmış bir user-agent string’i gerçek platformla çelişebilir. Paketlenmiş Chrome sürümünün verdiği user-agent’ı kullanın, oturum içinde viewport/locale/timezone değerlerini sabit tutun ve her sayfada yeni bir fingerprint uydurmaya çalışmak yerine istek hızını dikkatle ayarlayın.
Aşağıda bu üç katmanı tek bir başlangıç kurulumunda birleştiren bir örnek var.
import puppeteer from 'puppeteer-extra';
import StealthPlugin from 'puppeteer-extra-plugin-stealth';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
puppeteer.use(StealthPlugin());
function boundedDelay(minMs = 800, maxMs = 1800) {
return new Promise((r) => setTimeout(r, minMs + Math.random() * (maxMs - minMs)));
}
async function stableProfileScrape(targetUrl, upstreamProxy) {
const localProxy = await anonymizeProxy(upstreamProxy);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`, '--lang=en-US'],
});
const page = await browser.newPage();
await page.setViewport({ width: 1366, height: 768 });
await boundedDelay();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true);
}
}
Bu, diğer rehberlerin neredeyse hiç göstermediği bir kısım. Proxy, stealth ve fingerprint randomization’ı tek seferde bir araya getiren, doğrudan kullanabileceğiniz bir örnek.
Üretime Hazır Hata Yönetimi ve Proxy Sağlık Kontrolleri
Çoğu eğitim happy path’te sona erer. Gerçek scraping ise sürekli başarısız olur: proxy’ler ölür, kimlik bilgilerinin süresi dolar, hedef site çalışma sırasında hız sınırı koyar. Bu, sadece umut ederek çözülecek bir şey değil.
Üstel Geri Çekilme ve Jitter ile Yeniden Deneme Mantığı
function backoffMs(attempt, base = 1000, cap = 30_000) {
const exponential = Math.min(cap, base * 2 ** attempt);
return Math.floor(exponential * (0.5 + Math.random() * 0.5)); // jitter, senkron saldırıyı önler
}
async function withRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
if (attempt === maxRetries) throw err;
const delay = backoffMs(attempt);
console.warn(`Deneme ${attempt + 1} başarısız oldu: ${err.message}. ${delay}ms sonra yeniden deneniyor`);
await new Promise((r) => setTimeout(r, delay));
}
}
}
Başarısız Proxy’leri Otomatik Kara Listeye Alma
const proxyStats = new Map(); // proxyUrl -> { success, failure }
function recordResult(proxyUrl, success) {
const stats = proxyStats.get(proxyUrl) || { success: 0, failure: 0 };
success ? stats.success++ : stats.failure++;
proxyStats.set(proxyUrl, stats);
}
function isHealthy(proxyUrl) {
const stats = proxyStats.get(proxyUrl);
if (!stats) return true;
const total = stats.success + stats.failure;
if (total < 5) return true; // henüz yeterli veri yok
return stats.failure / total < 0.5; // hata oranı %50’yi aşarsa kara liste
}
function getHealthyProxy(pool) {
const healthy = pool.filter(isHealthy);
if (healthy.length === 0) throw new Error('Havuzda sağlıklı proxy kalmadı');
return healthy[Math.floor(Math.random() * healthy.length)];
}
Yalnızca başarı/başarısızlığa değil, hata türüne de bakın. 407 (yanlış kimlik bilgileri) ile 429 (hız sınırı) tamamen farklı tepkiler gerektirir. Kimlik doğrulaması başarısız olan bir proxy’yi hızlıca tekrar denemek sadece zaman kaybıdır. Çözüm daha hızlı bir rotasyon değil, kimlik bilgilerini kontrol etmektir.
Puppeteer’da Yaygın Dönen Proxy Hatalarını Giderme
| Hata | Muhtemel Neden | Çözüm |
|---|---|---|
ERR_PROXY_CONNECTION_FAILED | Proxy kapalı veya erişilemez | Havuzdan çıkarın, bir sonraki proxy ile yeniden deneyin |
407 Proxy Authentication Required | Yanlış kimlik bilgileri veya desteklenmeyen kimlik doğrulama | page.authenticate() bilgilerini doğrulayın; URL içine gömülü auth için proxy-chain kullanın |
TimeoutError | Yavaş proxy veya hedefin engellemesi | Timeout’u artırın; residential proxy’ye geçin |
403 Forbidden | IP veya parmak izi işaretlenmiş | Proxy değiştirin + stealth etkinleştirin + user-agent’ı rastgeleleştirin |
ERR_TUNNEL_CONNECTION_FAILED | HTTPS tünel sorunu | CONNECT yöntem desteğini kontrol edin; proxy-chain ile yerel tünellemeyi deneyin |
Tabloya tam oturmayan önemli bir nokta daha var: 200 durum kodu başarı anlamına gelmez. Soft block’lar genellikle normal bir durum koduyla birlikte, tamamen render edilmiş bir HTML sayfası da döndürebilir — login duvarları ya da challenge ekranları buna örnek. Bu yüzden yalnızca yanıt koduna değil, gerçek içeriğe de bakmanız gerekir. Takıldığınızda, Puppeteer’ın debug rehberi headless: false ile çalıştırmanızı, slowMo eklemenizi ve ayrıntılı protokol logları için NODE_DEBUG="puppeteer:*" ayarlamanızı önerir. Ama bu loglar hassas istek verisi içerebileceğinden, üretim kimlik bilgileriyle çalıştırırken açıkta bırakmayın.
Kendi Yönettiğiniz Proxy Rotasyonu vs. Proxy Gateway vs. AI Extract API
| Kriter | Kendi Yönettiğiniz Liste Rotasyonu | Backconnect Gateway (Bright Data, Oxylabs, Decodo) | AI Extraction API (Thunderbit) |
|---|---|---|---|
| Maliyet (düşük hacim) | Düşük–Orta | GB başına Orta–Yüksek | Düşük (ücretsiz plan, sonra birim bazlı) |
| Güvenilirlik | Sağlık kontrollerinize bağlı | Yüksek (sağlayıcı yönetimli) | Yüksek (yönetilen altyapı) |
| Anti-tespit | Kendiniz kurarsınız | Kısmi (yalnızca IP rotasyonu) | Yerleşik |
| Yapılandırılmış çıktı | Hayır (ham HTML) | Hayır (ham HTML) | Evet (şemaya göre JSON) |
| Kurulum süresi | Saatler | Dakikalar | Dakikalar |
| Kontrol | Tam | Sağlayıcının API’siyle sınırlı | Şema modeliyle sınırlı |
2026-08-07 itibarıyla kontrol edilen güncel vendor fiyatları, gateway seçeneklerinin maliyet eğrisini gösteriyor. Bright Data’nın residential fiyatlandırması, promosyonlara göre değişebilen kullanım bazlı ücretlendirme ve kapasite planları sunuyor. Oxylabs, 5 GB’de GB başına 6 dolar, 1 TB’de GB başına 2,50 dolar öneriyor. Decodo (eski adıyla Smartproxy), 3 GB’de GB başına 3,75 dolar, 100 GB’de GB başına 2,75 dolar ve kullanım bazlı ücretlendirmede GB başına 4 dolar sunuyor. Decodo ayrıca 115M+ IP havuzu ve %99,92 başarı oranı iddiasında bulunuyor — ancak bu yalnızca vendor’ın kendi iddiası, bağımsız olarak tekrarlanmış bir benchmark değil.
Gerçekte kullandığım karar kriteri şu: Sayfayla etkileşime girmeniz mi gerekiyor? Tıklama, kaydırma, form doldurma, oturum durumunu koruma gerekiyor mu? O zaman Puppeteer ve proxy kullanırım. Yalnızca sayfada zaten bulunan veriyi mi almanız gerekiyor? O zaman proxy altyapısı kurmadan önce extraction API’ye bakarım.
Puppeteer + Proxy Ne Zaman Gereğinden Fazla: Bunun Yerine API ile Yapılandırılmış Veri Çekin
Bir projede, tek yapmam gereken ürün fiyatlarını bir spreadsheet’e taşımakken üçüncü kez proxy health check sistemini yeniden yazarken bunu fark ettim. Bu altyapının çoğu, aslında geliştiricinin asıl hedefi olmayan bir sorunu çözmek için var: sayfadan ham HTML almak. Gerçek hedef structured data’dır. HTML sadece can sıkıcı bir ara biçim.
Thunderbit’in Open API’si, extraction’ı tarayıcı otomasyonunun bir yan ürünü değil, asıl iş olarak ele alır. POST /extract, bir URL ve JSON Schema alır, buna uygun structured data döndürür. JS render etme, anti-bot önlemleri ve CAPTCHA’lar arka planda halledilir, yani kullanıcının stealth eklentileriyle ya da proxy pool’larıyla doğrudan uğraşmasına gerek kalmaz.
curl -X POST https://openapi.thunderbit.com/openapi/v1/extract \
-H "Authorization: Bearer $THUNDERBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product",
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"price": {"type": "number"}
},
"required": ["name", "price"]
}
}'
Ayrıca, katı bir schema yerine yalnızca temiz Markdown’a ihtiyaç duyduğunuzda kullanılan bir POST /distill endpoint’i de var, ve aynı schema’yı birden fazla URL’e tek seferde uygulayan batch extraction da destekleniyor. Thunderbit’in güncel API fiyatlandırmasına göre Distill sayfa başına 1 unit, Extract sayfa başına 20 unit kullanıyor. Ücretsiz planda 600 tek seferlik unit bulunuyor, bu da bir iş akışına bağlanmadan önce denemek için yeterli.
Claude, Cursor veya MCP uyumlu bir istemci içinde çalışan geliştiriciler için Thunderbit, thunderbit_extract ve thunderbit_distill araçlarını MCP üzerinden de sunuyor. Böylece bir agent, iş akışının ortasında ayrı bir scraping adımına gerek kalmadan sayfadan veri almaya karar verebilir. MCP yapılandırmasını eklemeden önce gerçek API reference’ını kontrol etmenizi öneririm, çünkü araç isimleri ve parametreler dokümantasyon sürümlerine göre değişebilir.
| Boyut | Puppeteer + Dönen Proxy’ler | Thunderbit API |
|---|---|---|
| Kurulum karmaşıklığı | Yüksek — proxy havuzu, rotasyon mantığı, stealth, yeniden deneme | Düşük — JSON Schema ile tek API çağrısı |
| Anti-bot yönetimi | Manuel | Yerleşik |
| Çıktı | Ham HTML (ayrıştırma gerekir) | Şemanıza uyan yapılandırılmış JSON |
| Bakım | Yüksek — selector’lar bozulur, proxy’ler yıpranır | Düşük |
| En iyi kullanım | Özel otomasyon, giriş akışları, niş etkileşimler | Ölçekli veri çıkarma |
DIY yaklaşımın da elbette avantajları var. Kullanım senaryonuz hesap girişi, birden fazla adımı tıklayarak ilerlemek veya oturum durumunu korumak gerektiriyorsa, extraction API’nin yerini tutması genellikle zordur. Thunderbit’in SSS’i de interaktif login akışlarının şu an API tarafından desteklenmediğini açıkça belirtiyor. Bu durumlarda hâlâ Puppeteer + proxy doğru seçim. Ama işiniz "birden fazla herkese açık sayfadan kendi schema’ma uyan veriyi almak" ise, kendi proxy rotasyon yığınınızı sıfırdan kurmak, aslında olduğundan daha büyük bir problemi çözmeye çalışmak olabilir. Daha az kod yazmak isteyen ekipler için, Thunderbit Chrome Eklentisi aynı AI tabanlı extraction’ı tıklama tabanlı bir arayüzle sunuyor. Kodsuz web scraping ile tam geliştirici düzeyinde bir kurulum arasında karar veremiyorsanız, göz atmaya değer.
Sonuç ve Temel Çıkarımlar
Puppeteer’da dönen proxy tek bir teknik anlamına gelmez. Tarayıcı başına rotasyon basit ve izoledir. Kimlik doğrulaması gereken backconnect gateway, tek bir tarayıcı-ortak uç noktanın arkasında çıkışları döndürür. Daha ince ayrıntılı istek bazlı kontrol veya eşzamanlılık yönetimi istiyorsanız browser sharding veya harici bir yönlendirici gerekir; yalnızca request interception ile Chrome’un ağ yolunu değiştiremezsiniz.
Ama diğer katmanlar desteklemedikçe bunların hiçbiri fazla bir anlam ifade etmez. Proxy, IP itibarı problemini çözer; stealth plugin ve fingerprint tutarlılığı, browser signal problemini çözer; jitter ve hızı ayarlanmış istekler ise davranış deseni problemini çözer. Bunlardan biri bile eksik olursa yine de engellenebilirsiniz — sadece bu sefer nedeni farklı olur.
Kendi başınıza kuracaksanız proxy-chain deposundan ve yukarıdaki kod bloklarından başlayın — bu sizi çoğu ücretli kurstan çok daha ileriye taşır. Proxy yönetimini tamamen atlayıp yalnızca structured data almak istiyorsanız, bütün hafta sonunuzu bitmek bilmeyen bir health check altyapısı kurmaya harcamadan önce Thunderbit API dokümantasyonuna 10 dakika ayırmak buna değer. İki yaklaşım da geçerli. Önemli olan, bir eğitimin varsaydığı sorunu değil, gerçekten sizin sahip olduğunuz sorunu çözmek. Bu alanın AI ile nasıl değiştiğine daha geniş açıdan bakmak isterseniz, AI web scraping ile geleneksel yaklaşımları karşılaştıran derinlemesine yazıya da göz atabilirsiniz.
SSS
Puppeteer’da proxy’leri ne sıklıkla döndürmeliyim?
Bu, hedef sitenin rate limit’inin ne kadar agresif olduğuna bağlıdır. Bot tespiti sıkı bir siteyse, sayfa bazında ya da oturum bazında değiştirin. Daha esnek bir siteyse, tüm scrape boyunca aynı IP’yi bir oturumda sabit tutmak da sorun olmayabilir. Evrensel bir sayı yoktur. 403, 429 ve timeout’ları sabit bir istek sayısı olarak değil, daha agresif bir rotasyona ihtiyaç duyduğunuzun sinyali olarak görün.
Puppeteer scraping için ücretsiz proxy kullanabilir miyim?
Teknik olarak mümkün, ama hızlı bir testin ötesine geçtiğinizde önermiyorum. Ücretsiz proxy listeleri genellikle yavaş, güvenilmez ve çoğu zaman zaten scrape etmeye çalıştığınız sitede engellenmiş durumda. Üretim için bir işse, ücretli bir sağlayıcının residential proxy’sine ya da yönetilen bir gateway’e para ödemek buna değer.
puppeteer-extra-plugin-stealth tüm anti-bot sistemlerine karşı işe yarar mı?
Hayır. Eklentinin kendi dokümantasyonu da bunu söylüyor. Bazı yaygın headless Chrome sinyallerini azaltır, ama hedef site yine de ağ itibarını, TLS özelliklerini, çerezleri, client hints’i ve davranış desenlerini değerlendirebilir. Bu eklenti bir garanti değil, bir uyumluluk katmanıdır.
Puppeteer’da proxy-chain ile --proxy-server arasındaki fark nedir?
--proxy-server, tek bir proxy uç noktasını tüm tarayıcı örneğine bağlayan bir Chromium başlangıç bayrağıdır. Chrome bu noktada yerleşik proxy kimlik bilgilerini kabul etmez. proxy-chain, kimlik doğrulama gerektiren bir upstream’e giden yerel, anonim bir tünel oluşturur. Rotasyonu sağlamanın yolu farklı bir upstream ile yeniden başlatmak, sağlayıcı tarafından yönetilen bir backconnect gateway kullanmak ya da bu amaç için tasarlanmış ayrı bir yönlendirici kullanmaktır — proxy-chain’in Puppeteer’ın her page’ine ayrı ayrı proxy takması şeklinde değil.
Tamamen engellenmemek için dönen proxy’ler yeterli mi?
Hayır. Ve bu en yaygın yanlış anlama. Cloudflare’ın bot management gibi modern anti-bot sistemleri yalnızca IP itibarına değil, browser fingerprint’ine, davranış desenlerine ve oturum geçmişine de bakar. Proxy yalnızca IP itibarı kısmını çözer. Diğer sinyallerde takılmamak için stealth yapılandırması, tutarlı bir fingerprint ve gerçekçi bir zamanlama da gereklidir.
Daha Fazla Bilgi
