Kembali ke blog

Proxy untuk Pengambilan Data Aviasales, Booking, dan Skyscanner: Cara Mengumpulkan Harga Tanpa Pemblokiran

Panduan lengkap untuk memilih dan mengatur proxy untuk memantau harga di agregator perjalanan: jenis proxy yang digunakan, cara menghindari pemblokiran, dan mengumpulkan data dari Aviasales, Booking, Skyscanner.

📅9 Maret 2026
```html

Agregator perjalanan seperti Aviasales, Booking, Skyscanner secara aktif melindungi diri dari pengumpulan data otomatis — memblokir IP setelah 10-20 permintaan, menampilkan captcha, dan mengubah harga untuk bot. Jika Anda memantau harga tiket pesawat atau hotel untuk layanan Anda, program afiliasi, atau analisis pasar, tanpa proxy yang diatur dengan benar, Anda akan mendapatkan larangan hanya dalam beberapa menit kerja parser.

Dalam panduan ini, kita akan membahas jenis proxy yang diperlukan untuk parsing situs perjalanan yang stabil, cara mengatur rotasi IP, menghindari sistem anti-bot Cloudflare dan Akamai, serta kesalahan apa yang dapat menyebabkan pemblokiran bahkan saat menggunakan proxy.

Mengapa agregator perjalanan memblokir parsing dan bagaimana mereka melakukannya

Agregator perjalanan mengalami kerugian nyata akibat parsing: setiap permintaan ke API mereka memerlukan biaya (mereka membayar maskapai dan hotel untuk akses data), dan pesaing menggunakan harga yang dikumpulkan untuk menarik pelanggan. Oleh karena itu, Aviasales, Booking, Skyscanner, Kayak menginvestasikan jutaan dalam perlindungan anti-bot.

Metode utama deteksi parsing

1. Analisis frekuensi permintaan dari satu IP. Pengguna biasa membuat 3-5 permintaan pencarian per sesi, parser — ratusan per menit. Jika dari IP Anda datang lebih dari 15-20 permintaan per menit, sistem menandainya sebagai mencurigakan. Setelah 50-100 permintaan — pemblokiran selama 24 jam atau selamanya.

2. Fingerprinting browser. Situs perjalanan mengumpulkan puluhan parameter: resolusi layar, zona waktu, font yang diinstal, sidik jari WebGL, sidik jari kanvas, konteks audio. Jika parameter ini tidak sesuai dengan geolokasi IP yang dinyatakan (misalnya, IP dari Moskow, tetapi zona waktu UTC+8) — ini adalah tanda proxy atau VPN.

3. Pemeriksaan reputasi IP. Situs menggunakan basis data penyedia proxy yang dikenal, pusat data, server VPN. Jika IP Anda terdaftar dalam basis data tersebut (misalnya, MaxMind GeoIP2, IPQualityScore, SEON), permintaan akan diblokir atau captcha akan ditampilkan. Booking dan Skyscanner sangat ketat terhadap IP dari rentang Amazon AWS, Google Cloud, DigitalOcean.

4. Analisis perilaku. Sistem anti-bot melacak gerakan mouse, kecepatan scroll, jeda antara klik. Selenium dan Puppeteer tanpa patch tambahan meninggalkan jejak: properti navigator.webdriver, tidak ada plugin, ukuran jendela yang tidak biasa. Bahkan dengan proxy, lalu lintas semacam itu mudah dikenali.

5. TLS-fingerprinting. Sistem anti-bot modern (Cloudflare, Akamai) menganalisis parameter TLS handshake: urutan cipher suites, ekstensi, versi protokol. Di Python requests dan pustaka standar, TLS-fingerprint berbeda dari browser — ini segera mengungkap bot.

Kasus nyata: Salah satu klien kami melakukan parsing harga di Booking melalui 100 proxy pusat data (DigitalOcean). Setelah 2 jam kerja, semua IP diblokir selamanya — Booking mendeteksi rentang pusat data dan menambahkannya ke daftar hitam. Beralih ke proxy residensial menyelesaikan masalah: selama sebulan bekerja — tidak ada pemblokiran.

Jenis proxy apa yang cocok untuk memantau harga: perbandingan

Untuk parsing agregator perjalanan, ada tiga jenis proxy yang digunakan: proxy residensial, mobile, dan proxy pusat data. Setiap jenis memiliki kelebihan, kekurangan, dan skenario penggunaan masing-masing. Pemilihan tergantung pada volume parsing, anggaran, dan persyaratan anonimitas.

Jenis Proxy Tingkat Kepercayaan Situs Kecepatan Biaya (kira-kira) Terbaik untuk
Proxy Residensial Sangat tinggi (IP pengguna rumah) Sedang (300-800 ms) $$$ (berdasarkan lalu lintas) Booking, Expedia, Airbnb — situs dengan perlindungan ketat
Proxy Mobile Maksimal (IP operator seluler) Rendah (500-1500 ms) $$$$ (yang termahal) Parsing versi mobile, permintaan API, menghindari Cloudflare
Proxy Pusat Data Rendah (mudah terdeteksi) Sangat tinggi (50-150 ms) $ (yang termurah) API Aviasales, agregator yang kurang terlindungi, pengujian

Fitur pemilihan untuk situs perjalanan tertentu

Aviasales dan Skyscanner — relatif toleran terhadap parsing melalui API (jika Anda memiliki akses afiliasi). Untuk web parsing, cukup menggunakan proxy residensial dengan rotasi setiap 5-10 permintaan. Proxy pusat data berfungsi, tetapi memerlukan kumpulan IP yang besar (minimal 500 alamat) dan rotasi lambat (tidak lebih dari 1 permintaan dalam 30 detik dari satu IP).

Booking.com dan Expedia — menggunakan Cloudflare Enterprise dengan aturan ketat. Proxy pusat data diblokir dalam 90% kasus bahkan dengan parsing lambat. Hanya diperlukan proxy residensial atau mobile, ditambah emulasi browser nyata (Selenium Stealth, Puppeteer Extra dengan plugin). Rotasi IP — setelah setiap 3-5 permintaan.

Airbnb — salah satu situs yang paling terlindungi. Memerlukan proxy residensial dengan geolokasi yang sesuai dengan permintaan pencarian (jika mencari hotel di Paris — IP harus berasal dari Prancis). Cookies, referer, dan header browser wajib. Proxy mobile menunjukkan hasil terbaik untuk parsing melalui API mobile.

Kayak dan Momondo — tingkat perlindungan sedang. Proxy residensial adalah pilihan optimal. Anda dapat menggunakan proxy pusat data, tetapi dengan rotasi wajib dan jeda antara permintaan (minimal 10-15 detik).

Proxy Residensial vs Pusat Data: apa yang harus dipilih untuk situs perjalanan

Perbedaan utama antara proxy residensial dan proxy pusat data adalah sumber alamat IP. Proxy residensial menggunakan IP dari penyedia internet rumah yang nyata (Rostelecom, MTS, Comcast, Verizon), sedangkan proxy pusat data menggunakan IP dari server perusahaan hosting (AWS, Google Cloud, OVH). Situs perjalanan mempercayai IP residensial karena digunakan oleh pengguna biasa.

Kapan proxy residensial wajib

1. Parsing situs dengan Cloudflare/Akamai. Booking, Expedia, Airbnb menggunakan sistem ini — mereka secara otomatis memblokir 95% IP pusat data. Proxy residensial lolos pemeriksaan karena IP mereka tidak terdaftar dalam basis data penyedia proxy.

2. Pengumpulan harga dengan keterikatan geolokasi. Situs perjalanan menunjukkan harga yang berbeda kepada pengguna dari negara dan kota yang berbeda (karena pajak, kurs mata uang, promosi lokal). Jika Anda memerlukan harga untuk wilayah tertentu (misalnya, harga untuk penduduk Jerman), proxy residensial dengan IP Jerman adalah satu-satunya pilihan yang dapat diandalkan.

3. Parsing jangka panjang tanpa pemblokiran. Jika Anda memantau harga 24/7 selama berbulan-bulan, proxy residensial akan terbayar — Anda tidak menghabiskan waktu untuk mengganti IP yang diblokir dan mengatur proxy baru.

Kapan bisa menggunakan proxy pusat data

1. Parsing melalui API resmi. Jika Anda memiliki akses afiliasi ke API Aviasales, API Skyscanner — jenis proxy tidak kritis, API kurang sensitif terhadap sumber IP. Proxy pusat data akan memberikan kecepatan tinggi dan biaya rendah.

2. Pengujian dan pengembangan parser. Pada tahap penulisan dan debugging kode, gunakan proxy pusat data — mereka lebih murah, lebih cepat, dan tidak masalah jika beberapa IP terblokir.

3. Parsing agregator yang kurang terlindungi. Beberapa situs perjalanan regional atau agregator tiket bus tidak menggunakan perlindungan anti-bot yang canggih. Untuk mereka, proxy pusat data dengan kumpulan IP besar dan rotasi lambat sangat cocok.

Saran: Kombinasikan jenis proxy. Gunakan proxy residensial untuk permintaan kritis (pencarian pertama, mendapatkan token, menghindari captcha), dan proxy pusat data untuk permintaan massal ke API atau endpoint yang kurang terlindungi. Ini akan mengurangi biaya hingga 40-60% sambil mempertahankan stabilitas.

Strategi rotasi IP: seberapa sering mengganti proxy saat parsing

Rotasi IP yang benar adalah kunci untuk parsing jangka panjang tanpa pemblokiran. Jika Anda mengganti IP terlalu sering, Anda akan cepat menghabiskan kumpulan alamat dan mendapatkan biaya tinggi untuk lalu lintas. Jika terlalu jarang — Anda akan mengumpulkan aktivitas mencurigakan pada satu IP dan mendapatkan larangan.

Jenis rotasi proxy

1. Rotasi berdasarkan permintaan (rotating proxies). IP berubah secara otomatis setelah setiap permintaan atau setelah jumlah permintaan tertentu. Sebagian besar penyedia proxy residensial menawarkan mode ini: Anda terhubung ke satu endpoint (misalnya, gate.proxycove.com:8000), dan IP berubah di sisi penyedia.

Kelebihan: Kemudahan pengaturan, tidak perlu mengelola kumpulan IP secara manual, risiko pemblokiran satu IP minimal.
Kekurangan: Tidak dapat mengontrol sesi (jika perlu menyimpan cookies atau token), setiap permintaan = IP baru = biaya lalu lintas baru.

2. Sesi lengket (sticky sessions). IP terikat pada sesi Anda untuk waktu tertentu (biasanya 10-30 menit). Anda melakukan beberapa permintaan dari satu IP, kemudian secara otomatis berubah. Dapat diatur melalui parameter proxy (misalnya, menambahkan session-id123 dalam login).

Kelebihan: Dapat menyimpan cookies dan token dalam sesi, pengeluaran lalu lintas lebih sedikit (satu IP = beberapa permintaan).
Kekurangan: Jika IP terblokir selama sesi, semua permintaan berikutnya dalam sesi tersebut akan diblokir.

3. Rotasi manual dari kumpulan. Anda mendapatkan daftar alamat IP (misalnya, 1000 buah) dan mengelola rotasi dalam kode parser: memilih IP acak dari daftar, melakukan N permintaan, beralih ke berikutnya. Umum untuk proxy pusat data.

Kelebihan: Kontrol penuh atas rotasi, dapat mengecualikan IP yang diblokir dari kumpulan.
Kekurangan: Perlu menulis logika rotasi dalam kode, mengelola status IP (mana yang telah digunakan, mana yang diblokir).

Frekuensi rotasi yang disarankan untuk situs perjalanan

Situs Jenis Proxy Frekuensi Rotasi Maks. permintaan dari 1 IP
Booking.com Residensial Setelah 3-5 permintaan 5-7
Expedia Residensial Setelah 5-8 permintaan 8-10
Airbnb Residensial/Mobile Setelah 2-4 permintaan 3-5
Aviasales Residensial/Data Center Setelah 10-15 permintaan 15-20
Skyscanner Residensial/Data Center Setelah 8-12 permintaan 12-15
Kayak Residensial Setelah 5-10 permintaan 10-12

Penting: Ini adalah nilai rata-rata. Batas nyata tergantung pada waktu dalam sehari (di malam hari, sistem anti-bot lebih ketat), jenis permintaan (pencarian tiket pesawat = lebih banyak beban pada API dibandingkan dengan melihat hotel), kualitas emulasi browser. Mulailah dengan nilai konservatif (lebih sedikit permintaan per IP), kemudian tingkatkan secara bertahap, sambil memantau persentase pemblokiran.

Geo-targeting proxy: mengapa negara dan kota IP penting

Situs perjalanan menunjukkan harga yang berbeda tergantung pada geolokasi pengguna. Ini bukan bug, tetapi model bisnis: maskapai dan hotel menetapkan tarif yang berbeda untuk pasar yang berbeda. Misalnya, tiket Moskow-New York dapat berharga $600 untuk pengguna dari Rusia dan $750 untuk pengguna dari AS (karena pajak, persaingan, daya beli).

Bagaimana situs menentukan geolokasi

1. Berdasarkan alamat IP. Metode utama. Situs menggunakan basis data GeoIP (MaxMind, IP2Location) yang mencocokkan IP dengan kota, wilayah, negara. Akurasi penentuan kota — 70-90%, negara — 95-99%.

2. Berdasarkan bahasa browser dan zona waktu. Jika IP menunjukkan Jerman, tetapi bahasa browser — Rusia, dan zona waktu — UTC+3 (Moskow) — ini adalah tanda proxy. Situs dapat menampilkan captcha atau memblokir permintaan.

3. Berdasarkan mata uang dan pengaturan akun. Jika Anda masuk ke akun Booking, situs mengingat negara Anda saat mendaftar. Mengganti IP ke negara lain akan menimbulkan kecurigaan — Booking dapat meminta Anda untuk mengonfirmasi identitas atau memblokir akun.

Cara memilih geolokasi proxy dengan benar

Untuk mengumpulkan harga pasar tertentu: Gunakan IP dari negara yang harga tersebut menarik bagi Anda. Jika Anda memantau harga untuk pasar Rusia — ambil proxy residensial Rusia. Untuk pasar Eropa — proxy dari negara-negara UE (Jerman, Prancis, Polandia). Untuk AS — proxy Amerika.

Untuk menghindari geo-blocking: Beberapa situs perjalanan atau penawaran khusus hanya tersedia dari negara tertentu. Misalnya, penerbangan domestik AS sering lebih murah saat dipesan dari IP Amerika. Gunakan proxy dari negara yang diperlukan + atur bahasa browser dan zona waktu sesuai negara tersebut.

Untuk parsing data global: Jika Anda memerlukan harga untuk semua pasar (misalnya, untuk analisis), gunakan kumpulan proxy dari berbagai negara. Rotasi geolokasi bersama dengan IP: permintaan dari IP Jerman → harga Jerman, permintaan dari IP Prancis → harga Prancis.

Kesalahan: Menggunakan IP dari satu negara, tetapi mencari hotel/tiket di negara lain dengan mata uang yang tidak sesuai. Misalnya, IP dari Rusia, mencari hotel di Thailand, mata uang — euro. Ini terlihat mencurigakan. Gunakan IP dari negara tujuan, atau IP dari negara asli Anda dengan mata uangnya.

Pengaturan proxy untuk parser dan skrip populer

Mari kita lihat pengaturan proxy untuk alat parsing situs perjalanan yang paling populer. Contoh diberikan untuk proxy residensial dengan rotasi, tetapi juga cocok untuk jenis lainnya.

Python + requests / httpx

Opsi paling sederhana untuk parsing API atau halaman sederhana tanpa JavaScript. Cocok untuk API Aviasales, API Skyscanner, endpoint sederhana tanpa Cloudflare.

import requests

# Data proxy (ganti dengan milik Anda)
proxy_host = "gate.proxycove.com"
proxy_port = "8000"
proxy_user = "your_username"
proxy_pass = "your_password"

proxies = {
    "http": f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
    "https": f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}"
}

# Header browser (wajib!)
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Referer": "https://www.google.com/"
}

# Permintaan melalui proxy
response = requests.get(
    "https://www.aviasales.com/search",
    proxies=proxies,
    headers=headers,
    timeout=30
)

print(response.status_code)
print(response.text[:500])  # 500 karakter pertama dari respons

Penting: Untuk proxy residensial dengan rotasi, setiap permintaan baru secara otomatis akan mendapatkan IP baru. Jika perlu sesi lengket (satu IP untuk beberapa permintaan), tambahkan ID sesi dalam username: your_username-session-12345.

Selenium (untuk situs dengan JavaScript)

Booking, Expedia, Airbnb secara aktif menggunakan JavaScript untuk merender konten dan pemeriksaan anti-bot. Selenium meniru browser nyata, tetapi memerlukan pengaturan tambahan untuk menghindari deteksi.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service

# Pengaturan Chrome
chrome_options = Options()

# Proxy
proxy_host = "gate.proxycove.com"
proxy_port = "8000"
proxy_user = "your_username"
proxy_pass = "your_password"

# Format proxy untuk Chrome
chrome_options.add_argument(f'--proxy-server=http://{proxy_host}:{proxy_port}')

# Menyembunyikan otomatisasi
chrome_options.add_argument('--disable-blink-features=AutomationControlled')
chrome_options.add_experimental_option("excludeSwitches", ["enable-automation"])
chrome_options.add_experimental_option('useAutomationExtension', False)

# User-Agent
chrome_options.add_argument('user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36')

driver = webdriver.Chrome(options=chrome_options)

# Menghapus properti webdriver
driver.execute_script("Object.defineProperty(navigator, 'webdriver', {get: () => undefined})")

# Otorisasi proxy (jika diperlukan)
# Untuk Chrome, Anda perlu membuat ekstensi dengan otorisasi, lihat selenium-wire atau lebih mudah menggunakan Puppeteer

driver.get("https://www.booking.com/")
print(driver.title)
driver.quit()

Masalah: Chrome tidak mendukung otorisasi proxy melalui login:password secara langsung. Solusi: gunakan pustaka selenium-wire (menambahkan proxy dengan otorisasi), buat ekstensi Chrome untuk otorisasi, atau gunakan Puppeteer (Node.js).

Puppeteer (Node.js) — pilihan terbaik untuk situs yang kompleks

Puppeteer lebih baik dalam meniru browser dibandingkan Selenium, dan mudah diatur dengan otorisasi proxy. Direkomendasikan untuk Booking, Airbnb, Expedia.

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: true,
    args: [
      '--proxy-server=http://gate.proxycove.com:8000',
      '--disable-blink-features=AutomationControlled',
      '--no-sandbox'
    ]
  });

  const page = await browser.newPage();

  // Otorisasi proxy
  await page.authenticate({
    username: 'your_username',
    password: 'your_password'
  });

  // Menyembunyikan webdriver
  await page.evaluateOnNewDocument(() => {
    Object.defineProperty(navigator, 'webdriver', {
      get: () => undefined
    });
  });

  // User-Agent
  await page.setUserAgent('Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36');

  await page.goto('https://www.booking.com/', { waitUntil: 'networkidle2' });
  
  const title = await page.title();
  console.log('Judul:', title);

  await browser.close();
})();

Untuk perlindungan lebih baik dari deteksi, gunakan plugin puppeteer-extra-plugin-stealth — ia secara otomatis menyembunyikan semua tanda otomatisasi.

Solusi siap pakai: Scrapy, Crawlee

Scrapy (Python) — kerangka kerja untuk parsing skala besar. Mendukung proxy melalui middleware. Contoh pengaturan di settings.py:

# settings.py
DOWNLOADER_MIDDLEWARES = {
    'scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware': 1,
}

# Di spider
class TravelSpider(scrapy.Spider):
    def start_requests(self):
        proxy = "http://your_username:your_password@gate.proxycove.com:8000"
        yield scrapy.Request(
            url="https://www.aviasales.com/",
            meta={'proxy': proxy},
            callback=self.parse
        )

Crawlee (Node.js) — kerangka kerja modern dengan rotasi proxy bawaan, menghindari sistem anti-bot, dan retry otomatis. Sangat cocok untuk situs perjalanan.

Menghindari sistem anti-bot Cloudflare, PerimeterX, Akamai

Bahkan dengan proxy residensial berkualitas tinggi, Anda dapat menghadapi pemblokiran jika tidak menghindari sistem anti-bot dengan benar. Booking menggunakan Cloudflare, Airbnb — PerimeterX, beberapa situs — Akamai Bot Manager. Sistem ini menganalisis tidak hanya IP, tetapi juga perilaku, fingerprint browser, TLS handshake.

Cloudflare: metode utama untuk menghindari

1. Gunakan otomatisasi browser. Cloudflare memeriksa tantangan JavaScript, yang dijalankan di browser. Permintaan HTTP sederhana (requests, curl) tidak akan lolos pemeriksaan. Anda memerlukan Puppeteer, Playwright, atau Selenium dengan pengaturan yang benar.

2. Sembunyikan tanda otomatisasi. Pasang puppeteer-extra-plugin-stealth (Node.js) atau undetected-chromedriver (Python). Pustaka ini mempatch browser, menghapus properti navigator.webdriver, window.chrome, mengubah permissions API.

3. Fingerprint TLS yang benar. Cloudflare menganalisis TLS handshake. Gunakan pustaka yang meniru TLS browser: curl-impersonate (meniru TLS Chrome/Firefox), tls-client (Go), hrequests (Python).

4. Selesaikan captcha secara otomatis. Jika Cloudflare menampilkan captcha (Turnstile), gunakan layanan penyelesaian captcha: 2Captcha, Anti-Captcha, CapSolver. Mereka terintegrasi melalui API dan biayanya $1-3 untuk 1000 solusi.

PerimeterX (Airbnb, beberapa situs perjalanan)

PerimeterX adalah salah satu sistem anti-bot yang paling kompleks. Ia menganalisis perilaku pengguna (gerakan mouse, klik, scroll), membuat fingerprint perangkat, memeriksa cookies dan localStorage.

Metode untuk menghindari:

1. Emulasi perilaku pengguna. Tambahkan jeda acak antara tindakan (2-5 detik), gerakkan mouse, scroll halaman. Di Puppeteer, gunakan pustaka ghost-cursor untuk gerakan mouse yang realistis.

2. Simpan cookies dan localStorage. PerimeterX menghasilkan token yang disimpan dalam cookies (_px3, _pxhd) dan localStorage. Jika Anda mengganti IP tetapi menyimpan cookies — ini mencurigakan. Sebaiknya ganti IP + bersihkan cookies, atau gunakan sesi lengket (satu IP = satu sesi dengan cookies).

3. Gunakan proxy mobile. PerimeterX lebih ketat terhadap IP pusat data. Proxy mobile menunjukkan hasil terbaik untuk menghindari PerimeterX.

Akamai Bot Manager

Akamai menganalisis data sensor (akselerometer, giroskop di mobile), fingerprint WebGL, konteks audio, kinerja perangkat. Menghindari ini memerlukan emulasi browser yang canggih.

Rekomendasi: Gunakan browser nyata (tidak headless), proxy mobile, tambahkan jeda acak, emulasi peristiwa sensor (touch events). Untuk kasus yang kompleks — gunakan farm browser (BrowserStack, LambdaTest) atau browser anti-deteksi (AdsPower, Multilogin).

Kesalahan umum saat parsing situs perjalanan melalui proxy

Bahkan pengembang berpengalaman melakukan kesalahan yang mengarah pada pemblokiran. Berikut adalah masalah yang paling umum dan solusinya.

Kesalahan 1: Menggunakan satu User-Agent untuk semua permintaan

Jika semua permintaan Anda datang dengan User-Agent yang sama (misalnya, Python requests standar: python-requests/2.28.0), ini segera mengungkap bot. Bahkan jika Anda mengganti IP, situs melihat UA yang sama dan mengaitkan permintaan.

Solusi: Gunakan daftar User-Agent browser nyata (Chrome, Firefox, Safari) dan rotasi mereka. Pustaka fake-useragent (Python) secara otomatis menghasilkan UA acak.

Kesalahan 2: Kecepatan permintaan terlalu tinggi

Parser melakukan 100 permintaan per detik — ini secara fisik tidak mungkin bagi manusia. Bahkan dengan IP yang berbeda, sistem anti-bot mendeteksi aktivitas anomali berdasarkan pola (semua permintaan datang tepat dalam 0.01 detik).

Solusi: Tambahkan jeda acak antara permintaan: time.sleep(random.uniform(2, 5)). Untuk situs perjalanan, yang optimal: 2-5 detik antara permintaan dari satu IP, 0.5-2 detik antara permintaan dari IP yang berbeda.

Kesalahan 3: Mengabaikan cookies dan sesi

Situs perjalanan menggunakan cookies untuk melacak sesi, menyimpan token sistem anti-bot, personalisasi harga. Jika Anda melakukan setiap permintaan tanpa cookies (seperti pengguna baru), ini mencurigakan.

Solusi: Gunakan requests.Session() (Python) atau simpan cookies antara permintaan di Puppeteer. Untuk sesi lengket (satu IP = beberapa permintaan) pastikan untuk menyimpan cookies.

Kesalahan 4: Ketidaksesuaian geolokasi IP dan parameter browser

IP dari Jerman, tetapi bahasa browser — Rusia, zona waktu — UTC+3, mata uang — rubel. Sistem anti-bot melihat ketidaksesuaian ini dan memblokir permintaan.

Solusi: Sinkronkan parameter browser dengan geolokasi proxy. Jika Anda menggunakan IP Jerman — atur bahasa Jerman (Accept-Language: de-DE), zona waktu Europe/Berlin, mata uang EUR.

Kesalahan 5: Menggunakan proxy gratis atau berkualitas rendah

Proxy gratis dan proxy publik murah sudah diblokir di semua situs perjalanan besar. IP mereka terdaftar dalam daftar hitam, memiliki reputasi buruk (digunakan untuk spam, DDoS).

Solusi: Gunakan proxy residensial atau mobile berkualitas tinggi dari penyedia terpercaya. Periksa reputasi IP melalui layanan IPQualityScore, Scamalytics sebelum digunakan.

Checklist sebelum menjalankan parser:
✅ Proxy — residensial atau mobile, dengan geolokasi yang tepat
✅ User-Agent — browser nyata, dirotasi
✅ Cookies — disimpan dalam sesi
✅ Jeda — 2-5 detik antara permintaan
✅ Rotasi IP — setelah 3-10 permintaan (tergantung situs)

```