Kembali ke blog

Cara Mengatur Timeout dan Logika Retry untuk Proxy: Melindungi dari Kehilangan Data saat Parsing

Pelajari cara mengatur timeout dan logika retry dengan benar untuk proxy, agar menghindari kehilangan data saat melakukan parsing, otomatisasi, dan bekerja dengan akun iklan.

📅27 Februari 2026
```html

Ketika Anda bekerja dengan proxy untuk parsing marketplace, otomatisasi media sosial, atau pengumpulan data, masalah yang paling umum adalah permintaan yang terjebak dan kehilangan data. Server proxy mungkin tidak merespons tepat waktu, koneksi bisa terputus, dan skrip Anda bisa terhenti selama beberapa menit. Akibatnya, Anda kehilangan waktu, data, dan uang.

Dalam panduan ini, saya akan menunjukkan cara mengatur timeout (waktu tunggu) dan logika retry (logika percobaan ulang) untuk bekerja dengan proxy. Anda akan belajar nilai timeout apa yang harus digunakan untuk berbagai tugas, bagaimana cara terhubung kembali secara otomatis saat terjadi kesalahan, dan bagaimana tidak kehilangan satu pun permintaan. Artikel ini cocok untuk mereka yang menulis kode dalam Python, serta bagi mereka yang menggunakan alat parsing siap pakai.

Mengapa timeout sangat penting saat bekerja dengan proxy

Bayangkan situasi: Anda telah menjalankan parser harga dari Wildberries untuk 10.000 produk. Skrip bekerja melalui proxy untuk menghindari pemblokiran. Semuanya berjalan dengan baik, tetapi pada permintaan ke-523, server proxy berhenti merespons — mungkin karena kelebihan beban atau tidak tersedia sementara. Tanpa pengaturan timeout, skrip Anda akan menunggu respons selamanya (atau sampai timeout sistem habis dalam 2-5 menit). Akibatnya, parsing terhenti, Anda kehilangan waktu, dan saat Anda menyadari masalahnya, mungkin sudah beberapa jam berlalu.

Timeout adalah waktu maksimum yang diizinkan untuk menunggu respons dari server. Jika server tidak merespons dalam waktu tersebut, permintaan akan dibatalkan, dan Anda dapat mencoba lagi dengan proxy lain atau mencatat kesalahan dalam log. Ini sangat penting saat bekerja dengan proxy karena:

  • Server proxy bisa tidak stabil — terutama yang publik atau murah. Bahkan proxy residensial berkualitas pun kadang kehilangan koneksi karena pengguna nyata terputus dari internet.
  • Situs target bisa memblokir IP — jika proxy diblokir, ia tidak akan merespons sama sekali atau akan merespons sangat lambat (memberikan captcha atau pengalihan).
  • Penundaan jaringan tidak dapat diprediksi — terutama saat menggunakan proxy dari negara lain. Permintaan bisa melewati beberapa node perantara.
  • Operasi massal memerlukan stabilitas — jika Anda melakukan parsing 100.000 halaman atau mengelola 50 akun Instagram, bahkan 1% permintaan yang terjebak = 1.000 operasi yang hilang.

Tanpa pengaturan timeout yang benar, skrip Anda akan menghabiskan waktu menunggu proxy yang tidak tersedia alih-alih beralih ke yang berfungsi. Ini berdampak langsung pada kecepatan kerja dan stabilitas hasil.

Jenis-jenis timeout: connect, read, dan total timeout

Ada tiga jenis timeout utama yang perlu dipahami dan diatur secara terpisah. Banyak pengembang pemula dan pengguna parser hanya mengatur satu timeout umum, yang menyebabkan masalah.

1. Connect timeout (timeout koneksi)

Ini adalah waktu yang dialokasikan untuk membangun koneksi dengan server proxy. Jika dalam waktu tersebut koneksi tidak terjalin — permintaan akan dibatalkan. Connect timeout bertanggung jawab untuk handshake awal (TCP handshake) antara klien Anda dan proxy.

Kapan ini terjadi: Server proxy tidak tersedia, kelebihan beban, atau IP diblokir oleh firewall.

Nilai yang disarankan:

  • Untuk proxy data center yang cepat: 3-5 detik
  • Untuk proxy residensial: 5-10 detik
  • Untuk proxy seluler: 10-15 detik (internet seluler lebih lambat)

2. Read timeout (timeout pembacaan)

Ini adalah waktu tunggu untuk respons dari server target setelah koneksi dengan proxy sudah terjalin. Jika server tidak mulai mengirimkan data dalam waktu tersebut — permintaan akan dibatalkan. Read timeout melindungi dari situasi di mana server menerima permintaan tetapi "terjebak" dan tidak memberikan respons.

Kapan ini terjadi: Situs target memproses permintaan dengan lambat, kelebihan beban, atau sengaja memperlambat permintaan yang mencurigakan.

Nilai yang disarankan:

  • Untuk parsing halaman sederhana (HTML): 10-15 detik
  • Untuk parsing dengan rendering JavaScript: 30-60 detik
  • Untuk permintaan API: 5-10 detik
  • Untuk mengunduh file besar: 120+ detik

3. Total timeout (timeout total)

Ini adalah waktu maksimum untuk menyelesaikan seluruh permintaan dari awal hingga akhir, termasuk koneksi, pengiriman permintaan, penerimaan, dan pembacaan respons. Total timeout adalah "pemutus darurat" yang menjamin bahwa tidak ada permintaan yang akan berlangsung lebih lama dari waktu yang ditentukan.

Kapan digunakan: Ketika Anda penting agar setiap permintaan sesuai dengan batas waktu yang ketat (misalnya, saat parsing waktu nyata untuk arbitrase).

Rumus: Total timeout = Connect timeout + Read timeout + cadangan 20-30%

Penting: Tidak semua pustaka dan alat mendukung pengaturan terpisah untuk connect dan read timeout. Misalnya, pustaka requests di Python memungkinkan Anda untuk menentukan kedua nilai sebagai tuple: timeout=(5, 15), di mana 5 adalah connect, 15 adalah read.

Nilai optimal timeout untuk berbagai tugas

Nilai timeout yang tepat tergantung pada tugas Anda, jenis proxy, dan situs target. Timeout yang terlalu pendek akan mengakibatkan banyak kesalahan palsu (proxy berfungsi, tetapi Anda menolaknya). Timeout yang terlalu panjang akan menghabiskan waktu menunggu proxy yang mati.

Tugas Connect timeout Read timeout Komentar
Parsing Wildberries, Ozon 5-7 detik 15-20 detik Marketplace bisa lambat dalam memberikan halaman dengan banyak produk
Parsing Avito, Yandex.Market 5-7 detik Biasanya situs cepat, tetapi bisa memblokir IP yang mencurigakan
Otomatisasi Instagram, TikTok 7-10 detik Gunakan proxy seluler — mereka lebih lambat, tetapi lebih stabil
Bekerja dengan Facebook Ads API 5 detik API biasanya cepat, tetapi bisa melambat saat rate limiting
Parsing melalui Selenium/Puppeteer 10 detik Rendering JavaScript membutuhkan waktu, terutama pada proxy yang lambat
Pemeriksaan massal proxy 3-5 detik Pemeriksaan ketersediaan cepat, proxy lambat dibuang

Tips: Mulailah dengan timeout yang konservatif (lebih lama) dan secara bertahap kurangi, menganalisis log kesalahan. Jika Anda melihat banyak kesalahan timeout pada proxy yang berfungsi — tingkatkan nilai. Jika skrip melambat karena proxy yang lambat — kurangi.

Logika retry: cara mengatur percobaan ulang dengan benar

Timeout menyelesaikan masalah permintaan yang terjebak, tetapi tidak menyelesaikan masalah kehilangan data. Jika proxy tidak merespons — Anda hanya akan mendapatkan kesalahan dan kehilangan permintaan tersebut. Oleh karena itu, logika retry sangat penting.

Logika retry adalah pengulangan otomatis permintaan saat terjadi kesalahan. Prinsip dasar pengaturan yang benar:

1. Tentukan kesalahan mana yang memerlukan pengulangan

Tidak semua kesalahan perlu diulang. Misalnya:

  • Yang perlu diulang: Timeout, Connection refused, Proxy error, 502/503/504 (kesalahan sementara server), Rate limiting (429)
  • Yang TIDAK perlu diulang: 404 (halaman tidak ditemukan), 403 (akses ditolak selamanya), 401 (otorisasi tidak valid), kesalahan validasi data

2. Atur jumlah percobaan

Jumlah retry yang optimal tergantung pada kritikalitas data:

  • Untuk tugas yang tidak kritis (parsing untuk analisis): 2-3 percobaan
  • Untuk tugas penting (memantau harga pesaing): 3-5 percobaan
  • Untuk tugas kritis (bekerja dengan akun iklan): 5-10 percobaan

3. Gunakan exponential backoff (penundaan eksponensial)

Jangan ulangi permintaan secara instan — ini dapat memperburuk masalah (misalnya, jika server kelebihan beban). Gunakan penundaan yang meningkat antara percobaan:

  • Percobaan 1: segera
  • Percobaan 2: setelah 1-2 detik
  • Percobaan 3: setelah 4-5 detik
  • Percobaan 4: setelah 10-15 detik

Rumus: penundaan = base_delay * (2 ^ nomor percobaan). Misalnya: 1 detik, 2 detik, 4 detik, 8 detik, 16 detik.

4. Rotasi proxy saat percobaan ulang

Aturan terpenting: saat mencoba ulang, gunakan proxy LAIN dari kumpulan Anda. Jika satu proxy tidak dapat menyelesaikan permintaan, kemungkinan besar ia tidak akan berhasil pada percobaan berikutnya. Namun, proxy lain memiliki kemungkinan besar untuk berhasil.

Ini sangat penting saat bekerja dengan proxy residensial, di mana Anda memiliki kumpulan ratusan atau ribuan alamat IP. Pada setiap retry, ambil IP acak baru dari kumpulan.

Contoh pengaturan timeout dan retry di Python

Mari kita lihat contoh praktis penerapan timeout dan logika retry di Python menggunakan pustaka populer.

Contoh 1: Pengaturan dasar dengan requests

Pustaka requests adalah yang paling populer untuk permintaan HTTP di Python. Berikut cara mengatur timeout dan retry sederhana:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# Pengaturan logika retry
retry_strategy = Retry(
    total=5,  # Maksimum 5 percobaan
    backoff_factor=1,  # Penundaan: 1, 2, 4, 8, 16 detik
    status_forcelist=[429, 500, 502, 503, 504],  # Kode kesalahan untuk retry
    allowed_methods=["HEAD", "GET", "POST", "PUT", "DELETE"]
)

adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)

# Pengaturan proxy
proxies = {
    'http': 'http://username:password@proxy.example.com:8080',
    'https': 'http://username:password@proxy.example.com:8080'
}

# Melakukan permintaan dengan timeout
try:
    response = session.get(
        'https://www.wildberries.ru/catalog/electronics',
        proxies=proxies,
        timeout=(5, 15)  # connect timeout 5 detik, read timeout 15 detik
    )
    print(f"Sukses! Status: {response.status_code}")
    print(f"Ukuran respons: {len(response.content)} byte")
except requests.exceptions.Timeout:
    print("Kesalahan: timeout terlampaui")
except requests.exceptions.ProxyError:
    print("Kesalahan: masalah dengan proxy")
except requests.exceptions.RequestException as e:
    print(f"Kesalahan permintaan: {e}")

Dalam contoh ini, kami mengatur otomatisasi retry di tingkat sesi. Saat terjadi kesalahan 429, 500, 502, 503, 504, pustaka secara otomatis akan mencoba ulang permintaan hingga 5 kali dengan penundaan eksponensial.

Contoh 2: Rotasi proxy saat retry

Contoh yang lebih canggih dengan rotasi proxy dari kumpulan pada setiap percobaan:

import requests
import random
import time

# Kumpulan proxy (ganti dengan proxy nyata Anda)
PROXY_POOL = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
    'http://user:pass@proxy3.example.com:8080',
    'http://user:pass@proxy4.example.com:8080',
]

def make_request_with_retry(url, max_retries=5, base_delay=1):
    """
    Melakukan permintaan dengan retry dan rotasi proxy
    """
    for attempt in range(max_retries):
        # Memilih proxy acak dari kumpulan
        proxy = random.choice(PROXY_POOL)
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(
                url,
                proxies=proxies,
                timeout=(5, 15),
                headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'}
            )
            
            # Memeriksa kode status
            if response.status_code == 200:
                return response
            elif response.status_code in [429, 500, 502, 503, 504]:
                # Kesalahan sementara - ulangi
                print(f"Percobaan {attempt + 1}: kode {response.status_code}, mengulang...")
            else:
                # Kesalahan permanen - berhenti
                print(f"Kesalahan {response.status_code}, menghentikan percobaan")
                return None
                
        except (requests.exceptions.Timeout, 
                requests.exceptions.ProxyError,
                requests.exceptions.ConnectionError) as e:
            print(f"Percobaan {attempt + 1}: kesalahan {type(e).__name__}, mengulang...")
        
        # Jika ini bukan percobaan terakhir - tunggu dengan penundaan eksponensial
        if attempt < max_retries - 1:
            delay = base_delay * (2 ** attempt)
            print(f"Menunggu {delay} detik sebelum percobaan berikutnya...")
            time.sleep(delay)
    
    print("Semua percobaan telah habis")
    return None

# Penggunaan
result = make_request_with_retry('https://www.ozon.ru/category/smartfony-15502/')
if result:
    print(f"Sukses! Mendapatkan {len(result.content)} byte data")
else:
    print("Gagal melakukan permintaan")

Kode ini memilih proxy acak baru dari kumpulan pada setiap percobaan, yang secara signifikan meningkatkan kemungkinan permintaan berhasil.

Contoh 3: Menggunakan pustaka tenacity

Untuk pengelolaan logika retry yang lebih fleksibel, Anda dapat menggunakan pustaka khusus tenacity:

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(5),  # Maksimum 5 percobaan
    wait=wait_exponential(multiplier=1, min=1, max=30),  # Penundaan eksponensial 1-30 detik
    retry=retry_if_exception_type((requests.exceptions.Timeout, 
                                   requests.exceptions.ProxyError,
                                   requests.exceptions.ConnectionError))
)
def fetch_with_proxy(url, proxy):
    """
    Fungsi dengan otomatisasi retry melalui dekorator
    """
    proxies = {'http': proxy, 'https': proxy}
    response = requests.get(url, proxies=proxies, timeout=(5, 15))
    response.raise_for_status()  # Akan memicu pengecualian pada kesalahan HTTP
    return response

# Penggunaan
try:
    result = fetch_with_proxy(
        'https://www.avito.ru/rossiya/telefony',
        'http://user:pass@proxy.example.com:8080'
    )
    print(f"Sukses! Status: {result.status_code}")
except Exception as e:
    print(f"Gagal melakukan permintaan setelah semua percobaan: {e}")

Pustaka tenacity memberikan kemampuan pengaturan retry yang sangat fleksibel melalui dekorator. Instalasi: pip install tenacity

Solusi siap pakai untuk parsing tanpa kode

Jika Anda bukan seorang programmer atau ingin menghemat waktu dalam pengembangan, ada alat parsing siap pakai dengan dukungan bawaan untuk timeout dan logika retry. Anda tidak perlu menulis kode — cukup atur parameter dalam antarmuka grafis.

Octoparse

Parser visual populer untuk Windows dan Mac. Pengaturan timeout dan retry:

  • Buka pengaturan tugas → Opsi Lanjutan
  • Page Load Timeout: atur 20-30 detik
  • Ajax Timeout: 10-15 detik untuk konten dinamis
  • Retry Times: 3-5 percobaan saat terjadi kesalahan
  • Dalam pengaturan proxy, Anda dapat mengunggah daftar dan mengaktifkan rotasi otomatis

ParseHub

Parser berbasis cloud dengan tarif gratis. Pengaturan:

  • Settings → Advanced → Page Load Delay: 5-10 detik
  • Request Timeout: 30 detik
  • Retry Failed Requests: aktifkan, 3 percobaan
  • Mendukung proxy melalui pengaturan proyek

Apify

Platform untuk otomatisasi tugas web dengan aktor (skrip) siap pakai untuk parsing situs populer. Banyak aktor untuk parsing marketplace (Wildberries, Ozon) sudah memiliki pengaturan timeout dan retry yang optimal. Anda hanya perlu:

  • Pilih aktor siap pakai untuk situs yang diinginkan
  • Tentukan proxy (mendukung integrasi dengan penyedia proxy)
  • Jalankan tugas — semuanya diatur secara otomatis

Browser anti-detect untuk otomatisasi

Jika Anda bekerja dengan media sosial atau platform iklan melalui Dolphin Anty, AdsPower, atau Multilogin, timeout diatur dalam profil browser:

  • Dolphin Anty: Pengaturan profil → Proxy → Timeout: 10-15 detik
  • AdsPower: Proxy Settings → Connection Timeout: 10 detik, Read Timeout: 20 detik
  • Multilogin: Browser Profile → Network → Proxy Timeout: 15 detik

Saat otomatisasi melalui browser ini (misalnya, dengan skrip Selenium), timeout proxy diwarisi dari pengaturan profil, tetapi Anda juga dapat menetapkan timeout tambahan di tingkat skrip.

Kesalahan umum saat mengatur timeout

Bahkan pengembang berpengalaman dan spesialis parsing sering melakukan kesalahan umum saat bekerja dengan timeout dan retry. Berikut adalah kesalahan yang paling umum:

Kesalahan 1: Tidak ada timeout sama sekali

Banyak pustaka secara default tidak mengatur timeout atau menetapkan nilai yang sangat besar (beberapa menit). Jika Anda tidak menentukan timeout secara eksplisit — skrip Anda dapat terjebak untuk waktu yang lama.

Solusi: Selalu tentukan timeout secara eksplisit dalam setiap permintaan. Lebih baik mendapatkan kesalahan setelah 15 detik daripada menunggu 5 menit.

Kesalahan 2: Proxy yang sama pada semua retry

Jika proxy tidak merespons pada percobaan pertama, kemungkinan keberhasilan pada percobaan berikutnya dengan proxy yang sama sangat rendah. Banyak yang lupa untuk merotasi proxy antara percobaan.

Solusi: Gunakan proxy baru dari kumpulan pada setiap retry. Ini sangat penting untuk tingkat keberhasilan yang tinggi.

Kesalahan 3: Timeout terlalu pendek untuk proxy yang lambat

Proxy seluler dan beberapa proxy residensial mungkin lebih lambat daripada data center. Jika Anda menetapkan timeout 5 detik untuk proxy seluler — Anda akan mendapatkan banyak kesalahan palsu pada IP yang sebenarnya berfungsi.

Solusi: Pertimbangkan jenis proxy. Untuk proxy seluler, gunakan timeout minimal 10-15 detik.

Kesalahan 4: Retry tanpa batas

Beberapa orang menerapkan retry dalam loop while True tanpa batasan jumlah percobaan. Jika masalah ada di sisi situs target (misalnya, situs tersebut sepenuhnya down) — skrip akan terus mencoba tanpa henti.

Solusi: Selalu batasi jumlah retry (maksimal 3-10 percobaan) dan catat permintaan yang gagal untuk analisis selanjutnya.

Kesalahan 5: Mengabaikan jenis kesalahan

Tidak semua kesalahan perlu diulang. Misalnya, jika Anda mendapatkan 404 (halaman tidak ditemukan) — pengulangan tidak ada gunanya, halaman tersebut memang tidak ada. Namun, 503 (layanan sementara tidak tersedia) — masuk akal untuk mencoba ulang setelah beberapa detik.

Solusi: Analisis jenis kesalahan dan ulangi hanya masalah sementara (timeout, connection error, 429, 500, 502, 503, 504).

Kesalahan 6: Tidak ada logging

Tanpa log, Anda tidak akan mengerti mengapa permintaan gagal: apakah masalah ada pada proxy, timeout, atau situs target?

Solusi: Catat setiap kesalahan dengan menyertakan: proxy mana yang digunakan, berapa timeout yang ditetapkan, berapa banyak percobaan yang dilakukan, dan kesalahan apa yang terjadi. Ini akan membantu mengoptimalkan pengaturan.

Tips untuk memilih proxy: Jika Anda sering mengalami kesalahan timeout bahkan dengan pengaturan yang benar, mungkin masalahnya ada pada kualitas proxy. Proxy publik murah atau shared sering kali kelebihan beban dan merespons lambat. Untuk kinerja yang stabil, kami sarankan menggunakan proxy residensial berkualitas dengan uptime yang terjamin.

Kesimpulan

Pengaturan timeout dan logika retry yang benar bukan hanya detail teknis, tetapi faktor yang sangat penting untuk stabilitas dan efisiensi saat bekerja dengan proxy. Tanpa timeout, skrip Anda akan terjebak pada proxy yang mati, kehilangan waktu. Tanpa logika retry, Anda akan kehilangan data saat terjadi kesalahan sementara. Dan tanpa rotasi proxy saat percobaan ulang — Anda akan mendapatkan tingkat keberhasilan yang rendah bahkan dengan kumpulan IP yang berkualitas.

Kesimpulan utama dari panduan ini:

  • Selalu tetapkan timeout secara eksplisit: connect timeout 5-10 detik, read timeout 10-30 detik tergantung pada tugas
  • Gunakan logika retry dengan batasan 3-5 percobaan dan penundaan eksponensial
  • Rotasi proxy pada setiap percobaan ulang — ini kunci untuk tingkat keberhasilan yang tinggi
  • Ulangi hanya kesalahan sementara (timeout, 429, 500, 502, 503, 504), jangan buang percobaan pada kesalahan permanen (404, 403)
  • Catat semua kesalahan untuk analisis dan pengoptimalan pengaturan
  • Pertimbangkan jenis proxy: proxy seluler lebih lambat daripada data center, tingkatkan timeout sesuai kebutuhan

Jika Anda bekerja dengan parsing marketplace (Wildberries, Ozon, Avito), otomatisasi media sosial, atau platform iklan, stabilitas proxy secara langsung mempengaruhi hasil Anda. Gunakan proxy berkualitas dengan uptime tinggi dan atur timeout serta retry dengan benar — ini akan menghemat waktu berjam-jam dan ribuan permintaan yang hilang.

Untuk tugas yang memerlukan stabilitas maksimum dan jumlah kesalahan timeout minimal, kami sarankan untuk mencoba proxy data center — mereka memberikan kecepatan respons tinggi dan koneksi stabil, yang sangat penting saat melakukan parsing massal dan otomatisasi.

```