Penyaringan proxy buruk dalam kumpulan parser: metrik dan kode

Jika parser Wildberries atau Ozon tiba-tiba mulai memberikan halaman kosong, timeout, dan kesalahan 403 — masalahnya tidak selalu terletak pada platform itu sendiri. Sebagian besar, beberapa alamat IP dalam kolam proksi sudah "kedaluwarsa": mereka diblokir, diperlambat, atau terjebak dalam CAPTCHA. Mari kita bahas metrik mana yang dapat membedakan proksi yang berfungsi dari yang mati dan bagaimana mengotomatiskan penyaringan tanpa kontrol manual.

Mengapa kolam proksi mengalami degradasi seiring waktu

Setiap kolam proksi — bahkan yang dibeli dari penyedia yang terpercaya — seiring waktu kehilangan sebagian alamat yang berfungsi. Alasannya bervariasi: sistem anti-fraud Wildberries, Ozon, dan Avito mengumpulkan tanda reputasi pada IP, beberapa alamat masuk dalam daftar hitam setelah permintaan massal dari klien lain penyedia (jika proksi dibagikan), rentang data center diblokir secara massal berdasarkan subnet, dan IP residensial kadang-kadang hanya keluar dari kolam karena pengguna nyata mematikan perangkatnya.

Jika kolam tidak dibersihkan, proporsi proksi "mati" meningkat secara non-linear: awalnya 5%, setelah seminggu pengambilan data aktif — 20-30%. Parser mulai menghabiskan sumber daya untuk percobaan ulang melalui IP yang tidak berfungsi, waktu rata-rata untuk mengumpulkan satu halaman meningkat, dan dalam log terakumulasi kesalahan yang menyembunyikan masalah nyata (misalnya, perubahan tata letak situs). Tanpa sistem penyaringan, Anda baik-baik saja menyimpan kolam yang membengkak "untuk cadangan", atau secara teratur mengalami kegagalan dalam pengumpulan data.

Tugasnya bukan hanya untuk mencatat fakta kesalahan, tetapi juga untuk mengklasifikasikannya: kelebihan beban server sementara, pemblokiran IP tertentu, pemblokiran regional, atau masalah di sisi parser (header tidak valid, cookie yang kedaluwarsa). Tipe kesalahan menentukan apakah proksi harus dibuang dari kolam selamanya, ditempatkan dalam "karantina" untuk sementara, atau cukup mengulangi permintaan.

Metrik kesalahan kunci untuk penyaringan

Untuk membedakan gangguan sementara dari proksi yang benar-benar mati, perlu mengumpulkan beberapa metrik untuk setiap IP, bukan hanya mengandalkan status HTTP tunggal. Berikut adalah set dasar yang perlu dicatat pada setiap permintaan:

Metrik	Apa yang disinyalkan	Tindakan
HTTP 403 / 429	Pemblokiran atau batasan laju pada IP	Karantina 30-60 menit, jika terulang — penghapusan
Timeout koneksi	Proksi kelebihan beban atau mati	3 timeout berturut-turut — penghapusan dari kolam
CAPTCHA dalam respons	IP dicurigai oleh anti-bot	Kurangi frekuensi permintaan atau ganti IP
Waktu respons > 5 detik	Degradasi kecepatan di sisi proksi	Turunkan prioritas di kolam
Ukuran respons di bawah rata-rata	Diberikan placeholder/halaman pemblokiran	Pemeriksaan tambahan konten sebelum penerimaan
Proporsi permintaan yang berhasil (success rate)	Penilaian kualitas IP secara keseluruhan	Di bawah 70% untuk 50 permintaan — penghapusan

Penting untuk tidak membingungkan kode kesalahan situs dengan kesalahan jaringan. Misalnya, 404 — ini bukan masalah proksi, tetapi produk yang tidak ada di Wildberries. Namun, jika satu IP yang sama secara teratur menerima 403 di tempat yang lain IP menerima 200 — ini adalah tanda jelas pemblokiran titik pada alamat ini.

Algoritma penilaian proksi

Alih-alih menggunakan sistem biner "berfungsi / tidak berfungsi", lebih nyaman untuk menghitung skor untuk setiap IP dari 0 hingga 100, yang secara bertahap menurun saat terjadi kesalahan dan pulih saat permintaan berhasil. Ini memungkinkan Anda untuk tidak membuang proksi setelah satu gangguan acak (server marketplace mungkin hanya macet sesaat), tetapi dengan cepat menghapus IP yang secara sistematis memberikan hasil yang buruk.

Logika sederhana: permintaan berhasil dengan kode 200 dan konten yang valid menambah +2 pada skor (tetapi tidak lebih dari 100). Timeout — minus 15. Kode 403/429 — minus 25. CAPTCHA dalam respons — minus 20. Jika skor jatuh di bawah ambang batas (misalnya, 30), proksi masuk ke karantina untuk waktu yang ditentukan, dan jika setelah kembali dari karantina skor kembali jatuh di bawah 10 — IP dihapus dari kolam secara permanen dan dicatat untuk analisis.

Pendekatan ini mirip dengan sistem reputasi di browser anti-detect seperti Dolphin Anty atau AdsPower, di mana akun memiliki "kesehatan" tergantung pada aktivitas. Mekanika yang sama juga bekerja dengan baik untuk alamat IP dalam pengambilan data.

Kode: ProxyPool dengan penyaringan otomatis di Python

Di bawah ini adalah kerangka kerja kelas yang berfungsi untuk mengelola kolam proksi dengan mempertimbangkan metrik kesalahan. Ini dapat dihubungkan ke parser mana pun yang menggunakan requests, httpx, atau Scrapy, dengan mengganti logika pengambilan proksi dengan pemanggilan pool.get_proxy().

import time
import random
from dataclasses import dataclass, field
from typing import Optional

@dataclass
class ProxyStats:
    address: str
    score: int = 100
    quarantine_until: float = 0.0
    total_requests: int = 0
    total_success: int = 0
    consecutive_timeouts: int = 0
    is_dead: bool = False

    @property
    def success_rate(self) -> float:
        if self.total_requests == 0:
            return 1.0
        return self.total_success / self.total_requests


class ProxyPool:
    def __init__(self, proxies: list[str],
                 min_score: int = 30,
                 dead_score: int = 10,
                 quarantine_seconds: int = 1800):
        self.stats = {p: ProxyStats(address=p) for p in proxies}
        self.min_score = min_score
        self.dead_score = dead_score
        self.quarantine_seconds = quarantine_seconds

    def _is_available(self, stats: ProxyStats) -> bool:
        if stats.is_dead:
            return False
        if stats.quarantine_until > time.time():
            return False
        return True

    def get_proxy(self) -> Optional[str]:
        available = [s for s in self.stats.values() if self._is_available(s)]
        if not available:
            return None
        # mengurutkan berdasarkan skor, mengambil acak dari 30% teratas, agar tidak terus-menerus menggunakan satu IP
        available.sort(key=lambda s: s.score, reverse=True)
        top_pool = available[:max(1, len(available) // 3)]
        return random.choice(top_pool).address

    def report_success(self, proxy: str):
        s = self.stats[proxy]
        s.total_requests += 1
        s.total_success += 1
        s.consecutive_timeouts = 0
        s.score = min(100, s.score + 2)

    def report_timeout(self, proxy: str):
        s = self.stats[proxy]
        s.total_requests += 1
        s.consecutive_timeouts += 1
        s.score -= 15
        if s.consecutive_timeouts >= 3:
            self._quarantine(s)
        self._check_dead(s)

    def report_blocked(self, proxy: str, captcha: bool = False):
        s = self.stats[proxy]
        s.total_requests += 1
        s.score -= 20 if captcha else 25
        self._quarantine(s)
        self._check_dead(s)

    def _quarantine(self, s: ProxyStats):
        if s.score < self.min_score:
            s.quarantine_until = time.time() + self.quarantine_seconds

    def _check_dead(self, s: ProxyStats):
        if s.score <= self.dead_score:
            s.is_dead = True

    def stats_report(self) -> list[dict]:
        return [
            {
                "proxy": s.address,
                "score": s.score,
                "success_rate": round(s.success_rate, 2),
                "dead": s.is_dead,
            }
            for s in self.stats.values()
        ]

Dalam parser nyata, pemanggilan report_success, report_timeout, dan report_blocked dimasukkan langsung ke dalam penanganan respons setelah setiap permintaan HTTP. Contoh integrasi dengan requests:

import requests

def fetch(url: str, pool: ProxyPool):
    proxy = pool.get_proxy()
    if not proxy:
        raise RuntimeError("Tidak ada proksi yang tersedia di kolam")

    proxies = {"http": proxy, "https": proxy}
    try:
        resp = requests.get(url, proxies=proxies, timeout=8)
    except requests.exceptions.Timeout:
        pool.report_timeout(proxy)
        return None

    if resp.status_code in (403, 429):
        pool.report_blocked(proxy)
        return None

    if "captcha" in resp.text.lower():
        pool.report_blocked(proxy, captcha=True)
        return None

    pool.report_success(proxy)
    return resp

Pendekatan ini mengurangi beban dari pemantauan manual: Anda hanya perlu mengatur ambang batas sekali, dan selanjutnya kolam akan "sembuh" sendiri, mengeluarkan alamat yang mati dan mengembalikan yang keluar dari karantina.

Nilai ambang untuk pemblokiran IP

Tidak ada angka universal — ambang batas tergantung pada platform dan agresivitas anti-botnya. Namun, ada patokan yang bekerja dengan baik dalam praktik saat mengambil data dari Wildberries, Ozon, dan Avito:

Success rate di bawah 70% pada sampel dari 30-50 permintaan — alasan untuk menghapus IP, bahkan jika skor saat ini belum kritis.
3 timeout berturut-turut — hampir selalu berarti bahwa proksi secara fisik tidak tersedia atau kelebihan beban, tidak ada gunanya menyimpannya di kolam aktif.
CAPTCHA lebih dari 1 kali dalam 20 permintaan — IP sudah dicurigai oleh anti-bot, lebih baik mengurangi frekuensi permintaan atau mengganti alamat.
Waktu respons rata-rata lebih dari 2x dari median kolam — sinyal degradasi, tidak kritis, tetapi alasan untuk menurunkan prioritas saat memilih.

Karantina selama 30-60 menit biasanya cukup untuk proksi data center dan residensial, agar anti-bot "melupakan" aktivitas mencurigakan sementara. Untuk proksi seluler, situasinya berbeda: di sana IP berubah saat operator mengganti sel, sehingga karantina bisa lebih pendek — 10-15 menit, karena setelah rotasi ini secara fisik sudah menjadi alamat yang berbeda.

Healthcheck dan rotasi di latar belakang

Selain penyaringan reaktif (berdasarkan kesalahan dalam aliran utama pengambilan data), berguna untuk menjalankan healthcheck di latar belakang — proses terpisah yang setiap beberapa menit memeriksa proksi dengan permintaan ringan ke URL netral (misalnya, httpbin.org/ip) dan memperbarui statistik kolam sebelum proksi masuk ke permintaan nyata ke Wildberries atau Ozon.

import threading

def healthcheck_loop(pool: ProxyPool, interval: int = 300):
    while True:
        for proxy in list(pool.stats.keys()):
            try:
                r = requests.get(
                    "https://httpbin.org/ip",
                    proxies={"http": proxy, "https": proxy},
                    timeout=5
                )
                if r.status_code == 200:
                    pool.report_success(proxy)
                else:
                    pool.report_blocked(proxy)
            except requests.exceptions.RequestException:
                pool.report_timeout(proxy)
        time.sleep(interval)

threading.Thread(target=healthcheck_loop, args=(pool,), daemon=True).start()

Proses latar belakang seperti ini sangat penting jika kolam besar (ratusan IP) dan pengambilan data tidak dilakukan secara terus-menerus, tetapi dalam batch — tanpa healthcheck, beberapa proksi hanya sempat "kedaluwarsa" antara peluncuran, dan beberapa menit pertama pengambilan data dihabiskan untuk penyaringan secara langsung, alih-alih langsung bekerja dengan alamat yang telah terverifikasi.

Jenis proksi mana yang harus dipilih untuk pengambilan data di marketplace

Pemilihan jenis proksi secara langsung mempengaruhi seberapa sering penyaringan harus dilakukan dan seberapa agresif ambang batasnya. Untuk pengambilan data yang stabil di Wildberries dan Ozon, di mana anti-bot menganalisis pola perilaku dan reputasi subnet, proksi residensial menunjukkan hasil terbaik — IP mereka dimiliki oleh penyedia internet rumah yang nyata, dan anti-bot jauh lebih jarang memblokir mereka secara massal berdasarkan subnet.

Untuk sumber yang lebih sederhana dan kurang terlindungi (misalnya, pengumpulan data publik dari Avito atau pemantauan harga di etalase yang tidak rumit) sering kali cukup menggunakan proksi data center — mereka lebih cepat dan lebih murah, yang kritis untuk volume permintaan yang besar, tetapi juga lebih sering diblokir, sehingga ambang batas penyaringan untuk mereka harus dibuat lebih ketat.

Jenis Proksi	Kecepatan Penyaringan	Kapan Menggunakan
Data Center	Tinggi, subnet diblokir secara massal	Etalase sederhana, volume besar, perlindungan rendah
Residensial	Sedang, IP diblokir secara titik	Wildberries, Ozon, situs dengan anti-bot
Seluler	Rendah, IP berubah secara otomatis oleh operator	Sumber yang sangat terlindungi, pengambilan data frekuensi tinggi

Dalam praktiknya, banyak tim menggunakan kolam hibrida: sebagian besar permintaan dilakukan melalui IP residensial, dan saat terjadi pemblokiran massal, proksi seluler dihubungkan sebagai cadangan "darurat", karena perubahan IP mereka terjadi secara alami melalui rotasi jaringan seluler dan tidak memerlukan intervensi manual.

Kesimpulan

Kolam proksi tanpa sistem penyaringan akan mengalami degradasi, dan semakin lama ia beroperasi tanpa pembersihan, semakin banyak sumber daya yang dihabiskan parser secara sia-sia pada IP mati. Model penilaian yang mempertimbangkan kode HTTP, timeout, CAPTCHA, dan success rate memungkinkan untuk secara otomatis mengidentifikasi alamat yang bermasalah dan menjaga kolam dalam kondisi kerja tanpa kontrol manual. Kode dari artikel ini dapat disesuaikan dengan tumpukan mana pun — requests, httpx, Scrapy, atau parser asinkron Anda sendiri.

Jika Anda baru saja mengumpulkan kolam untuk pengambilan data di marketplace dan ingin mengurangi frekuensi pemblokiran sejak awal, kami merekomendasikan untuk mempertimbangkan proksi residensial — mereka memberikan tingkat keberhasilan yang jauh lebih tinggi di platform yang terlindungi seperti Wildberries dan Ozon dibandingkan dengan alamat data center biasa.