Rotasi Proxy Puppeteer: Sesi Sticky, Retry, dan Penanganan Error

Sebuah job Puppeteer mungkin perlu mempertahankan exit IP yang sama saat berpindah di beberapa halaman. Job lain mungkin menggunakan proxy berputar dan menerima exit baru untuk setiap permintaan yang diproksi. Itu adalah alur kerja yang berbeda, dan keduanya tidak sama dengan mencoba ulang tugas yang gagal.

Panduan ini menunjukkan cara menetapkan sesi ke job scraping, memverifikasi perilaku exit IP, mengklasifikasikan kegagalan umum, dan menambahkan retry berbatas. Panduan ini menggunakan pengaturan HTTP proxy KindProxy sebagai contoh. Kode ditujukan untuk halaman publik yang Anda diizinkan mengakses; proxy tidak mengesampingkan aturan akses situs.

1. Rotasi Proxy, Sesi Sticky, dan Retry

Tiga mekanisme terlibat:

Kata “permintaan” penting di browser. Satu navigasi halaman dapat memicu permintaan untuk dokumen, skrip, stylesheet, gambar, dan sumber daya lain. Jika alur kerja membutuhkan satu exit yang konsisten di seluruh langkahnya, gunakan sesi sticky daripada mengasumsikan navigasi adalah satu permintaan proxy.

ID sesi baru membuat sesi independen, tetapi tidak menjamin IP yang berbeda dari sesi lain. Penyedia mungkin menetapkan exit yang sama yang tersedia ke keduanya.

2. Rencanakan Hubungan Tugas-ke-Sesi

Pilih sesi berdasarkan pekerjaan yang harus diselesaikan browser:

• Pemeriksaan satu halaman: sesi berputar mungkin cukup jika tugas tidak bergantung pada kontinuitas IP.

• Alur kerja multi-langkah: gunakan satu sesi sticky untuk tugas logis, misalnya membuka halaman produk lalu memeriksa variannya.

• Job paralel independen: beri setiap job pengenal sesi sendiri agar job tidak secara tidak sengaja berbagi sesi.

Simpan catatan yang memetakan setiap ID tugas ke ID sesinya. Saat sesi kedaluwarsa, permintaan berikutnya dapat dilanjutkan dengan exit baru jika sumber daya yang cocok tersedia. Jika filter negara dan ASN yang dipilih tidak memiliki sumber daya yang cocok, permintaan dapat gagal.

3. Konfigurasi Puppeteer dengan HTTP Proxy

Bagian ini adalah pengingat konfigurasi singkat. Untuk panduan koneksi lengkap, lihat Setup proxy residensial Puppeteer .

Instal Puppeteer dan sediakan endpoint proxy serta kredensial melalui variabel lingkungan:

npm install puppeteer

export KP_PROXY_HOST="gw.kindproxy.com"

export KP_PROXY_PORT="12000"

export KP_PROXY_USER_BASE="YOUR_DASHBOARD_USERNAME__cr.us"

export KP_PROXY_USER="$KP_PROXY_USER_BASE"

export KP_PROXY_PASSWORD="YOUR_PASSWORD"

Nama pengguna di atas adalah placeholder. Gunakan nilai targeting lokasi dan ASN yang dibuat untuk akun Anda di dasbor. Jangan commit kredensial ke Git.

Puppeteer meluncurkan Chromium dengan endpoint proxy, lalu menyediakan autentikasi HTTP ke setiap halaman:

import puppeteer from "puppeteer";

const browser = await puppeteer.launch({

  args: [

    `--proxy-server=http://${process.env.KP_PROXY_HOST}:${process.env.KP_PROXY_PORT}`,

  ],

});

const page = await browser.newPage();

await page.authenticate({

  username: process.env.KP_PROXY_USER,

  password: process.env.KP_PROXY_PASSWORD,

});

try {

  const response = await page.goto("https://api.ipify.org?format=json", {

    waitUntil: "domcontentloaded",

    timeout: 30_000,

  });

  console.log("HTTP status:", response?.status());

  console.log("IP response:", await page.$eval("body", el => el.innerText));

} finally {

  await browser.close();

}

Periksa exit IP sebelum mengirim browser ke halaman target. Pemeriksaan IP yang berhasil memverifikasi rute proxy; itu tidak menjamin bahwa situs tujuan akan mengembalikan halaman yang diharapkan.

4. Kelola ID Sesi Sticky dan Masa Hidupnya

KindProxy menambahkan parameter sesi ke nama pengguna yang dibuat dasbor. Format berikut valid:

YOUR_DASHBOARD_USERNAME__cr.us;sessid.product-check-42;sessttl.10

sessttl diukur dalam menit dan mendukung nilai dari 1 hingga 1440. Dalam contoh ini, sessttl.10 meminta sesi 10 menit. Nama pengguna harus mempertahankan lokasi dan bidang targeting lain yang dibuat untuk akun; tambahkan parameter sesi ke nama pengguna itu alih-alih mengganti pengaturan targetingnya.

Untuk kode, bangun nama pengguna sesi untuk setiap tugas logis:

function usernameForTask(taskId) {

  const baseUsername = process.env.KP_PROXY_USER_BASE;

  if (!baseUsername) throw new Error("KP_PROXY_USER_BASE is required");

  // Keep taskId to a simple, URL-safe set of characters.*

  const sessionId = `job-${taskId}`;

  return `${baseUsername};sessid.${sessionId};sessttl.10`;

}

// Use this username when authenticating the page for this task.*

await page.authenticate({

  username: usernameForTask("product-check-42"),

  password: process.env.KP_PROXY_PASSWORD,

});

Di sini, KP_PROXY_USER_BASE harus berisi nama pengguna yang dibuat dasbor dan nilai targeting, tetapi tanpa bidang sessid atau sessttl. Konfirmasikan komposisi ini terhadap nama pengguna yang ditampilkan di dasbor Anda sebelum menjalankannya.

Ketika sesi sticky mencapai batas waktunya, atau sumber daya saat ini offline, permintaan dilanjutkan menggunakan exit baru jika sumber daya yang sesuai tersedia. Jika tidak ada sumber daya yang cocok dengan filter lokasi dan ASN yang dipilih, permintaan gagal. Jangan menggambarkan sesi sticky sebagai janji tanpa syarat bahwa IP tidak pernah bisa berubah.

5. Tambahkan Logika Retry Berbatas

Keputusan retry harus mengikuti kategori error. Mengulangi setiap kegagalan dengan sesi baru dapat membuang traffic dan mempersulit diagnosis.

Helper retry kecil dapat membuat batas menjadi eksplisit:

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

async function withRetries(task, { maxAttempts = 3, baseDelayMs = 1_000 } = {}) {

  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {

    try {

      return await task(attempt);

    } catch (error) {

      if (attempt === maxAttempts || !isRetryable(error)) throw error;

      const exponentialDelay = baseDelayMs * 2 ** (attempt - 1);

      const jitter = Math.floor(Math.random() * 250);

      console.warn(`Attempt ${attempt} failed; retrying in ${exponentialDelay + jitter} ms`);

      await sleep(exponentialDelay + jitter);

    }

  }

}

function isRetryable(error) {

  // Keep this list narrow and adapt it to the errors your job actually observes.*

  const message = String(error?.message ?? error);

  return error?.name === "TimeoutError" || /ECONNRESET|ETIMEDOUT|ERR_PROXY_CONNECTION_FAILED/.test(message);

}

Helper ini hanya menangani error yang dilempar. Respons HTTP seperti 429, 403, atau 503 tidak selalu dilempar oleh page.goto(). Periksa status respons yang dikembalikan secara terpisah dan terapkan kebijakan di atas. Untuk 429, gunakan penundaan retry yang dinyatakan tujuan jika tersedia dan jaga laju permintaan dalam aturan situs.

Apakah retry harus menggunakan kembali sesi yang sama bergantung pada kegagalan yang didiagnosis. Pertahankan sesi untuk tugas multi-langkah ketika kontinuitas diperlukan. Jika sumber daya sesi tidak tersedia, gateway mungkin melanjutkan melalui exit baru; jika lokasi/ASN yang diminta tidak memiliki sumber daya tersedia, berhenti dan laporkan kegagalan itu daripada mencoba ulang tanpa batas.

6. Klasifikasikan Error dan Catat Detail yang Tepat

Diagnostik yang berguna memisahkan browser, proxy, tujuan, dan parser:

1. Startup browser: Apakah Chromium diluncurkan?

2. Koneksi/autentikasi proxy: Bisakah terhubung ke gateway dan mengautentikasi? 407 sisi proxy termasuk di sini.

3. Respons tujuan: Status HTTP apa yang dikembalikan target? 401, 403, atau 429 sisi target berbeda dari 407 proxy.

4. Navigasi: Apakah halaman dimuat sebelum timeout?

5. Ekstraksi: Apakah data yang diharapkan muncul di halaman yang dirender?

Catat cukup untuk mereproduksi kegagalan tanpa mengekspos kredensial:

{

  "task_id": "product-check-42",

  "session_id": "job-product-check-42",

  "attempt": 2,

  "exit_ip": "RECORD_OBSERVED_IP",

  "http_status": 200,

  "duration_ms": 1840,

  "error_category": null,

  "outcome": "success"

}

Nilai di atas hanya mengilustrasikan format log; itu bukan hasil uji KindProxy. Jangan pernah mencatat kata sandi proxy atau nama pengguna lengkap jika berisi pengenal akun.

7. Uji dan Verifikasi Rotasi Proxy

Jalankan pemeriksaan terkontrol terhadap endpoint pengecekan IP sebelum menguji halaman tujuan.

Verifikasi sesi sticky

Kirim beberapa pemeriksaan menggunakan nama pengguna sesi yang sama dan catat stempel waktu serta exit IP yang diamati. Dalam kondisi normal, sesi harus mempertahankan exit selama masa hidup yang dikonfigurasi. Jika sumber daya kedaluwarsa atau offline, exit baru mungkin digunakan; jika tidak ada sumber daya yang cocok dengan lokasi dan ASN yang dikonfigurasi, permintaan dapat gagal.

Amati mode rotasi

Lakukan pemeriksaan berulang tanpa sesi sticky dan bandingkan exit yang diamati dengan perilaku rotasi penyedia. Untuk contoh ini, luncurkan browser baru untuk setiap pemeriksaan agar mengurangi penggunaan ulang koneksi proxy. Karena rotasi terjadi per permintaan yang diproksi, halaman browser dapat mengeluarkan beberapa subpermintaan. Jangan asumsikan setiap page.goto() memetakan ke tepat satu permintaan proxy.

Hasil uji yang diamati (1 November 2026)

Hasil berikut dicatat selama uji terkontrol dengan skrip Puppeteer pendamping. Alamat IP sengaja disamarkan dalam ilustrasi yang dipublikasikan. Pemeriksaan rotasi dan sesi sticky menggunakan koneksi proxy langsung; kegagalan retry disimulasikan secara lokal.

Gambar: Ringkasan yang dibersihkan dari observasi exit-IP aktual dan demonstrasi retry terkontrol. Alamat IP disamarkan; error retry adalah simulasi, bukan gangguan proxy langsung.

Uji mode rotasi pertama menggunakan kembali satu koneksi browser dan mengamati satu exit di lima pemeriksaan. Mengulangi uji dengan browser baru untuk setiap pemeriksaan menghasilkan lima exit yang berbeda. Ini menunjukkan bahwa penggunaan ulang koneksi dapat berpengaruh untuk konfigurasi ini, tetapi tidak menetapkan aturan rotasi per koneksi yang universal atau menjamin IP yang berbeda.

Demikian pula, uji sesi sticky mengonfirmasi konsistensi selama jendela singkat yang diamati, bukan sepanjang seluruh TTL yang dikonfigurasi. ID sesi yang berbeda juga mungkin ditetapkan exit yang sama.

Jalankan contoh sendiri

Repositori pendamping dimaksudkan untuk dipublikasikan di kindproxy-puppeteer-proxy-rotation . Repositori ini berisi rotating-session.js, sticky-session.js, dan retry-handler.js, dengan instalasi dan konfigurasi lingkungan di README. Publikasikan repositori sebelum membuat artikel ini publik.

npm run rotate
npm run sticky
RETRY_TEST_MODE=timeout npm run retry
RETRY_TEST_MODE=http503 npm run retry
RETRY_TEST_MODE=http429 npm run retry

8. Kesalahan Umum dan Praktik Terbaik

• Memperlakukan retry klien seolah secara otomatis mengubah IP proxy.

• Mengasumsikan ID sesi baru menjamin exit IP yang unik.

• Mengasumsikan setiap navigasi browser sama dengan satu permintaan yang diproksi.

• Merotasi sesi segera setelah 429 atau 403 alih-alih memeriksa respons dan aturan akses tujuan.

• Mencoba ulang error autentikasi atau kegagalan parser seolah itu masalah jaringan sementara.

• Menjalankan retry tanpa batas atau konkurensi tinggi tanpa pacing permintaan.

• Memasukkan kredensial atau nama pengguna akun lengkap ke kontrol sumber atau log.

• Gagal membedakan error sisi target dari kegagalan koneksi sisi proxy.

Kesimpulan

Puppeteer tidak memutuskan kapan proxy residensial berputar. Layanan proxy mengelola exit yang berputar, parameter sesi sticky meminta kontinuitas, dan kode Anda memutuskan apakah tugas yang gagal harus dicoba ulang. Pisahkan tanggung jawab tersebut, klasifikasikan kegagalan sebelum mencoba ulang, dan verifikasi perilaku IP yang diamati terhadap aturan aktual penyedia.

Jika Anda masih membutuhkan langkah koneksi browser dasar, lihat Setup proxy residensial Puppeteer . Untuk contoh yang dapat dijalankan, lihat proyek GitHub pendamping (publikasikan repositori sebelum merilis artikel ini). Saat Anda siap memilih paket, jelajahi Proxy Residensial KindProxy .