Kesalahan Proxy Umum dan Cara Memperbaikinya

Kesalahan proxy dapat secara diam-diam merusak pengambilan data, pemantauan SEO, pelacakan harga, verifikasi iklan, dan alur kerja otomatisasi browser. Sebuah pekerjaan mungkin terlihat sedang berjalan, tetapi di belakang layar, permintaan mengalami timeout, sesi direset, halaman mengembalikan blok lembut, atau hasil yang ditargetkan secara geo berasal dari lokasi yang salah.

Kesalahan proxy yang paling umum biasanya berasal dari masalah otentikasi, batasan laju, rentang IP yang diblokir, ketidakcocokan TLS atau DNS, rute proxy yang tidak stabil, inkonsistensi sesi, atau pengaturan permintaan yang buruk. Solusinya tidak selalu "gunakan proxy yang berbeda." Pengaturan yang dapat diandalkan memerlukan kredensial yang benar, routing yang lebih baik, desain sesi yang bersih, backoff, validasi konten, dan metrik yang menunjukkan apakah pipeline benar-benar membaik.

Untuk tim yang menggunakan proxy pengambilan web, tujuannya sederhana: mengurangi permintaan yang gagal, meningkatkan output yang valid, dan menurunkan biaya per permintaan yang berhasil tanpa menebak.

Jawaban Cepat: Mengapa Kesalahan Proxy Terjadi

Kesalahan proxy terjadi ketika satu lapisan dari jalur permintaan gagal atau menjadi tidak konsisten.

Lapisan itu mungkin:

• otentikasi proxy
• reputasi IP
• volume permintaan
• cookie sesi
• resolusi DNS
• handshake TLS
• sidik jari browser
• batasan laju sisi target
• routing geo
• kesehatan kolam proxy

Kesalahan 407 biasanya menunjukkan masalah otentikasi proxy. Kesalahan 429 menunjukkan batasan laju. Kesalahan 403 mungkin berarti target memblokir rute atau sesi. Timeout dan kesalahan 502/504 sering menunjukkan rute hulu yang tidak stabil. CAPTCHA atau halaman interstitial biasanya berarti target menerapkan gesekan berdasarkan lalu lintas, sidik jari, atau sinyal sesi.

Cara terbaik untuk memperbaiki kesalahan proxy adalah dengan mengidentifikasi lapisan yang gagal terlebih dahulu, kemudian menerapkan perbaikan terkecil yang ditargetkan.

Tabel Diagnosis Kesalahan Proxy

Gunakan tabel ini sebagai panduan awal.

Jangan perlakukan semua kesalahan sama. Kesalahan 407, 429, dan blok lembut memerlukan respons yang berbeda.

407 Otentikasi Proxy Diperlukan

Kesalahan 407 berarti server proxy menolak permintaan karena otentikasi gagal.

Penyebab umum meliputi:

• nama pengguna yang salah
• kata sandi yang salah
• token yang kedaluwarsa
• port proxy yang salah
• header otentikasi yang hilang
• IP tidak ada dalam daftar putih
• URL proxy yang tidak valid
• menggunakan kredensial HTTP pada endpoint SOCKS
• rotasi rahasia tidak diterapkan dengan benar

Cara Memperbaiki Kesalahan 407

Mulailah dengan pengujian permintaan tunggal yang sederhana menggunakan klien yang diketahui baik. Konfirmasi host proxy, port, nama pengguna, kata sandi, dan protokol.

Periksa:

• format kredensial
• jenis endpoint
• metode otentikasi
• kedaluwarsa token
• status akun
• daftar putih IP
• variabel lingkungan
• penyimpanan rahasia aplikasi

Jika otentikasi berbasis IP, pastikan bahwa permintaan berasal dari IP server yang diharapkan. Jika infrastruktur Anda melakukan autoscaling atau mengubah wilayah cloud, IP keluar mungkin telah berubah.

Apa yang Harus Dipantau

Lacak tingkat 407 berdasarkan lingkungan, penyebaran, dan akun proxy. Lonjakan mendadak biasanya berarti penyimpangan konfigurasi, kredensial yang kedaluwarsa, atau masalah penyebaran.

403 Terlarang

Kesalahan 403 berarti server target menolak akses. Ini mungkin disebabkan oleh izin, pemblokiran sisi target, reputasi IP, masalah sidik jari browser, atau masalah pola permintaan.

Penyebab umum meliputi:

• rentang proxy yang diblokir
• ASN pusat data yang ditandai
• header yang diperlukan hilang
• cookie sesi yang tidak valid
• negara atau wilayah yang tidak didukung
• tingkat permintaan yang agresif
• target mendeteksi otomatisasi
• akses dibatasi oleh kebijakan situs

Cara Memperbaiki Kesalahan 403

Pertama, konfirmasi apakah halaman dapat diakses melalui browser normal dan apakah alur kerja Anda diizinkan. Jika halaman memerlukan login, verifikasi bahwa sesi Anda valid.

Kemudian isolasi penyebabnya:

• Uji permintaan tunggal dari klien yang bersih.
• Bandingkan rute pusat data dan residensial.
• Kurangi tingkat konkuren.
• Periksa header dan cookie.
• Validasi pengaturan wilayah dan bahasa.
• Tinjau apakah konten yang dikembalikan adalah pemblokiran keras atau pemblokiran lunak.

Untuk halaman publik yang memblokir rentang pusat data, proxy residensial dapat meningkatkan keberhasilan. Untuk target yang toleran, proxy pusat data mungkin masih lebih hemat biaya.

Untuk keputusan routing yang lebih luas, lihat Perbandingan Proxy Pusat Data vs Residensial vs ISP.

401 Tidak Terautentikasi

Kesalahan 401 biasanya berarti target memerlukan otentikasi yang valid dan permintaan Anda tidak menyediakannya.

Penyebab umum meliputi:

• sesi login yang kedaluwarsa
• token bearer yang hilang
• kunci API yang tidak valid
• cookie tidak dipertahankan
• alur login yang rusak
• sesi terikat pada IP sebelumnya
• akun memerlukan otentikasi ulang

Cara Memperbaiki Kesalahan 401

Untuk alur kerja API, segarkan token dan konfirmasi header otorisasi.

Untuk alur kerja browser, pertahankan cookie, penyimpanan lokal, dan status sesi. Hindari merotasi IP di tengah sesi jika target mengikat status login ke identitas jaringan.

Gunakan sesi lengket atau statis untuk alur kerja berbasis akun. Untuk lebih lanjut tentang perilaku rute, lihat Proxy Rotasi vs Statis.

429 Terlalu Banyak Permintaan

Kesalahan 429 berarti target membatasi laju kerja.

Penyebab umum meliputi:

• terlalu banyak permintaan dari satu IP
• terlalu banyak permintaan dari satu subnet
• tingkat konkuren per domain yang tinggi
• penjadwalan yang mendadak
• badai percobaan ulang
• akses berulang ke endpoint dengan gesekan tinggi
• tidak ada penundaan setelah kesalahan

Cara Memperbaiki Kesalahan 429

Gunakan pembentukan lalu lintas yang lebih halus.

Perbaikan yang direkomendasikan:

• kurangi tingkat konkuren per domain
• tambahkan jitter acak
• gunakan penundaan eksponensial
• sebar pekerjaan di jendela yang lebih panjang
• cache respons yang stabil
• hindari mencoba ulang segera
• pisahkan endpoint berisiko tinggi dari halaman berisiko rendah
• rotasi hanya ketika alur kerja mengizinkannya

Jangan hanya menambahkan lebih banyak percobaan ulang. Percobaan ulang yang dalam meningkatkan biaya dan dapat memperburuk batas laju.

Apa yang Harus Dipantau

Lacak kedalaman percobaan ulang, tingkat pemblokiran, dan CPSR.

CPSR berarti biaya per permintaan yang berhasil. Dalam istilah sederhana, CPSR memberi tahu Anda berapa biaya setiap hasil yang valid setelah pengeluaran proxy, komputasi, percobaan ulang, dan kegagalan.

Jika 429 menurun tetapi CPSR meningkat, perbaikan mungkin tidak efisien.

Kesalahan Gateway 502 dan 504

Kesalahan 502 atau 504 biasanya menunjukkan masalah hulu antara klien Anda, penyedia proxy, dan server target.

Penyebab umum termasuk:

• keluar proxy yang tidak stabil
• rute yang kelebihan beban
• keterlambatan server target
• kegagalan rantai proxy
• masalah pengaturan regional
• waktu tunggu terlalu pendek
• koneksi hulu yang buruk

Cara Memperbaiki Kesalahan 502 dan 504

Gunakan percobaan ulang terbatas dengan penundaan. Jangan coba ulang tanpa batas.

Perbaikan yang disarankan:

• coba ulang 1–2 kali dengan penundaan
• ganti rute proxy setelah kegagalan berulang
• pantau berdasarkan wilayah dan kumpulan proxy
• karantina keluar yang gagal
• tingkatkan waktu tunggu hanya jika target biasanya lambat
• kurangi tingkat koneksi pada domain yang terpengaruh
• pisahkan kesalahan jaringan dari blok target

Sebuah 504 pada halaman JavaScript yang berat mungkin memerlukan waktu tunggu yang berbeda dibandingkan dengan halaman HTML statis yang sederhana.

Waktu Habis Koneksi dan ECONNRESET

Waktu habis dan reset koneksi terjadi ketika koneksi tidak dapat diselesaikan atau ditutup secara tidak terduga.

Penyebab umum termasuk:

• keluar proxy yang mati
• target yang kelebihan beban
• jalur jaringan yang tidak stabil
• koneksi yang diblokir
• terlalu banyak soket terbuka
• pengaturan waktu tunggu terlalu agresif
• rute proxy terlalu jauh dari target
• target menutup sesi yang mencurigakan

Cara Memperbaiki Waktu Habis

Mulailah dengan memisahkan waktu habis koneksi dari waktu habis baca. Koneksi yang tidak dapat dibangun berbeda dari respons halaman yang lambat.

Perbaikan yang disarankan:

• gunakan rute proxy regional yang lebih dekat dengan target
• pendekkan waktu habis koneksi
• atur waktu habis baca yang realistis
• rotasi keluar setelah kegagalan berulang
• batasi koneksi terbuka per pekerja
• pantau latensi p95
• karantina keluar proxy dengan kegagalan tinggi

Untuk otomatisasi browser, juga pantau kecelakaan browser dan waktu habis navigasi secara terpisah.

Kesalahan TLS dan SSL

Kesalahan TLS terjadi selama pengaturan koneksi yang aman.

Penyebab umum termasuk:

• ketidakcocokan SNI
• versi TLS yang tidak didukung
• kegagalan validasi sertifikat
• pustaka klien yang usang
• ketidakcocokan ALPN
• target yang memerlukan dukungan cipher modern
• permintaan HTTPS yang dikirim melalui protokol proxy yang salah

Cara Memperbaiki Kesalahan TLS

Verifikasi bahwa permintaan menggunakan nama host dan protokol yang benar. Pastikan jenis proxy mendukung tunneling HTTPS jika diperlukan.

Pemeriksaan yang disarankan:

• konfirmasi SNI cocok dengan nama host target
• perbarui klien HTTP atau runtime browser
• gunakan versi TLS modern
• hindari pengaturan cipher lama
• konfirmasi perilaku validasi sertifikat
• bandingkan dengan permintaan browser normal

Perilaku TLS juga dapat berkontribusi pada deteksi bot. Jika User-Agent mengklaim Chrome tetapi profil TLS tidak menyerupai Chrome, target mungkin tidak mempercayai sesi tersebut.

Untuk masalah konsistensi browser dan klien, tinjau Fingerprinting Browser untuk Web Scraping.

Kesalahan Resolusi DNS

Kesalahan DNS berarti nama host target tidak dapat diselesaikan atau menyelesaikan dengan salah.

Penyebab umum termasuk:

• resolver DNS yang buruk
• ketidakcocokan DNS regional
• DNS horizon terpisah
• rute DNS yang diblokir
• catatan cache yang usang
• ketidakcocokan IPv6/IPv4
• proxy yang melewati resolver yang diharapkan

Cara Memperbaiki Kesalahan DNS

Gunakan resolver yang dapat diandalkan dan validasi perilaku DNS dari dalam runtime yang sama yang mengirim permintaan.

Perbaikan yang disarankan:

• periksa resolusi nama host target
• uji dari rute proxy
• sesuaikan wilayah DNS dengan wilayah proxy
• bersihkan cache DNS yang usang
• pin catatan hanya sementara
• pantau kegagalan DNS berdasarkan wilayah

Untuk alur kerja yang sensitif terhadap geo, DNS penting karena lokasi resolver dapat mempengaruhi konten yang dikembalikan.

CAPTCHA dan Halaman Interstitial

Halaman CAPTCHA atau interstitial biasanya berarti target menerapkan gesekan.

• tingkat permintaan tinggi
• reputasi IP mencurigakan
• ketidakcocokan sidik jari browser
• tidak ada riwayat sesi
• terlalu banyak percobaan ulang
• ketidakcocokan geo
• kebocoran WebRTC atau DNS
• perilaku navigasi yang tidak biasa

Cara Mengurangi Frekuensi CAPTCHA

Tujuannya adalah pencegahan, bukan penghindaran.

Perbaikan yang direkomendasikan:

• kurangi tingkat koneksi
• tambahkan jeda setelah tantangan
• gunakan sesi lengket jika perlu
• sesuaikan wilayah proxy, zona waktu, dan bahasa
• pertahankan cookie untuk alur kerja sesi
• validasi konsistensi profil browser
• hindari badai percobaan ulang
• gunakan API atau umpan yang disetujui jika tersedia

Jika prompt CAPTCHA muncul pada hampir setiap permintaan, tinjau kembali alur kerja daripada memaksakan lebih keras.

Untuk masalah terkait WebRTC, lihat Kebocoran WebRTC: Mengapa Mereka Menghancurkan Pengaturan Anti-Deteksi.

Kesalahan Ketidakcocokan Geo

Ketidakcocokan geo terjadi ketika lokasi proxy, pengaturan browser, toko target, atau konten yang dikembalikan tidak selaras.

Contoh termasuk:

• proxy keluar di satu negara tetapi konten menunjukkan negara lain
• hasil SEO tingkat kota berasal dari area yang salah
• harga muncul dalam mata uang yang salah
• opsi pengiriman tidak cocok dengan wilayah target
• konflik zona waktu dengan lokasi IP
• cookie membawa wilayah lama

Cara Memperbaiki Ketidakcocokan Geo

Jangan hanya mengandalkan label penyedia proxy. Validasi konten yang dikembalikan.

Periksa:

• mata uang
• bahasa
• alamat paket lokal
• lokasi toko
• wilayah pengiriman
• URL halaman
• spanduk negara
• cuplikan yang dilokalisasi

Untuk SEO lokal dan pemantauan geo-spesifik, rute residensial seringkali lebih dapat diandalkan. Lihat Pemantauan SEO Lokal dengan Proxy Residensial.

Soft Blocks: Kesalahan Proxy yang Terlewatkan Tim

Soft block adalah ketika sebuah halaman berhasil dikembalikan tetapi kontennya tidak valid.

Contoh termasuk:

• HTTP 200 dengan konten CAPTCHA
• halaman produk tidak ada harga
• halaman SERP tidak ada hasil organik
• template kesalahan generik
• data inventaris kosong
• halaman wilayah yang salah
• konten placeholder
• respons identik yang berulang

Soft block berbahaya karena dapat masuk ke dasbor sebagai data nyata.

Cara Mendeteksi Soft Blocks

Validasi struktur konten sebelum menghitung keberhasilan.

Untuk pemantauan harga, konfirmasi:

• judul produk
• SKU
• harga
• mata uang
• ketersediaan
• wilayah

Untuk pemantauan SEO, konfirmasi:

• jumlah hasil organik
• data paket lokal
• lokasi target
• fitur SERP yang diharapkan

Untuk saluran pengikisan, konfirmasi bidang yang diperlukan dan aturan skema.

Apa yang Harus Diukur

Keandalan proxy harus diukur melalui output yang valid, bukan permintaan mentah.

Lacak ini berdasarkan domain, rute, jenis proxy, wilayah, dan beban kerja.

Kerangka Keputusan: Perbaiki Lapisan yang Tepat

Gunakan jalur ini saat memecahkan masalah.

1. Kesalahan otentikasi? Perbaiki kredensial, daftar putih, port, dan rotasi rahasia.

2. Kesalahan batas laju? Kurangi tingkat koneksi, tambahkan jitter, dan terapkan jeda.

3. Kesalahan jaringan? Periksa kesehatan rute, timeout, DNS, dan latensi regional.

4. Kesalahan TLS atau protokol? Validasi versi klien, SNI, ALPN, dan perilaku sertifikat.

5. Blok keras? Tinjau jenis proxy, header, sidik jari browser, dan waktu permintaan.

6. Blok lunak? Validasi konten halaman dan ekspektasi parser.

7. Ketidakcocokan geo? Sesuaikan lokasi proxy, lokal browser, cookie, dan toko target.

Ini menjaga fokus pemecahan masalah.

Skenario Dunia Nyata: Pemantauan Harga E-Commerce

Tim harga memantau ribuan halaman produk. Sistem melaporkan peningkatan mendadak dalam harga yang hilang.

Pada awalnya, tim menganggap pengecer mengubah tata letaknya. Namun, sampel kegagalan menunjukkan respons HTTP 200 dengan wadah produk kosong. Masalahnya adalah blok lunak.

Perbaikannya meliputi:

• mengurangi konkurensi
• beralih ke halaman produk sensitif menggunakan proxy residensial
• menggunakan sesi lengket untuk pemeriksaan toko regional
• memvalidasi harga dan mata uang sebelum menyimpan catatan
• menangkap sampel HTML saat kegagalan parsing

Tingkat harga yang hilang menurun, dan CPSR meningkat karena pengulangan berkurang.

Skenario Dunia Nyata: Pelacakan Peringkat SEO

Sebuah platform SEO mengumpulkan SERP tingkat kota di ratusan lokasi.

Laporan menunjukkan peringkat lokal yang tidak stabil. Setelah penyelidikan, tim menemukan bahwa beberapa rute proxy mengembalikan hasil kota terdekat alih-alih hasil kota target yang tepat.

Perbaikannya meliputi:

• memvalidasi alamat paket lokal
• mencatat bendera akurasi geo
• memperketat routing proxy residensial
• menyelaraskan Accept-Language dan parameter pencarian
• memisahkan pemeriksaan nasional yang luas dari pemeriksaan lokal

Hasilnya adalah data peringkat yang lebih bersih dan lebih sedikit perubahan peringkat yang salah.

Kesalahan Umum yang Harus Dihindari

Mengulangi Setiap Kesalahan dengan Cara yang Sama

Kesalahan 407, 429, timeout, dan blok lunak memerlukan respons yang berbeda.

Mengabaikan Blok Lunak

Kode status yang berhasil tidak berarti data valid.

Memutar IP Terlalu Sering

Rotasi berlebihan dapat merusak kepercayaan sesi dan cookie.

Menggunakan Proxy Premium di Mana Saja

Gunakan rute residensial atau ISP di mana mereka meningkatkan keluaran yang valid. Pertahankan rute datacenter untuk halaman yang toleran.

Melupakan DNS dan TLS

Perilaku DNS dan TLS dapat berubah setelah pembaruan pustaka atau perubahan infrastruktur.

Meningkatkan Skala Sebelum Instrumentasi

Jangan tingkatkan volume sampai tingkat keberhasilan, tingkat blok, latensi, dan CPSR diukur.

Daftar Praktik Terbaik

Sebelum meningkatkan alur kerja yang didukung proxy:

• Verifikasi kredensial dan konfigurasi titik akhir proxy.
• Segmentasikan kesalahan berdasarkan jenis.
• Lacak tingkat keberhasilan, tingkat blok, tingkat blok lunak, dan CPSR.
• Gunakan batas konkurensi per domain.
• Tambahkan anggaran pengulangan dan penundaan eksponensial.
• Validasi konten sebelum menyimpan data.
• Gunakan sesi lengket untuk alur kerja multi-langkah.
• Sesuaikan wilayah proxy dengan lokal browser dan toko target.
• Pantau kegagalan DNS dan TLS.
• Karantina keluaran proxy yang buruk.
• Simpan sampel kegagalan untuk debugging.
• Uji ulang setelah pembaruan klien atau browser.

Untuk dukungan pengaturan, tinjau tutorial proxy dan kasus penggunaan proxy yang lebih luas dari SquidProxies.

Pertanyaan yang Sering Diajukan

Apa kesalahan proxy yang paling umum?

Kesalahan proxy yang paling umum adalah kesalahan autentikasi 407, respons terlarang 403, respons tidak sah 401, batas laju 429, kesalahan gateway 502 dan 504, kesalahan TLS, kegagalan DNS, timeout koneksi, halaman CAPTCHA, dan ketidakcocokan geo.

Apa arti 407 Proxy Authentication Required?

Ini berarti proxy menolak permintaan Anda karena autentikasi gagal. Periksa nama pengguna, kata sandi, token, port, protokol proxy, dan pengaturan daftar izinkan IP.

Apa arti 429 Too Many Requests?

Ini berarti target membatasi lalu lintas Anda. Kurangi konkurensi, tambahkan jitter, gunakan penundaan, dan hindari mencoba ulang segera.

Mengapa saya mendapatkan HTTP 200 tetapi tidak ada data yang berguna?

Ini sering kali merupakan blok lunak, kegagalan parser, halaman persetujuan, halaman wilayah yang salah, atau masalah rendering JavaScript. Validasi struktur halaman sebelum menghitung keberhasilan.

Bagaimana cara mengurangi timeout proxy?

Gunakan rute yang lebih sehat, perpendek waktu koneksi, tetapkan waktu baca yang realistis, coba ulang dengan penundaan, dan karantina keluaran proxy dengan tingkat kegagalan tinggi.

Kapan saya harus menggunakan proxy residensial daripada proxy pusat data?

Gunakan proxy residensial ketika akurasi geo, identitas jaringan seperti konsumen, atau ketahanan terhadap pemblokiran penting. Gunakan proxy pusat data untuk halaman publik dengan volume tinggi dan gesekan rendah.

Bagaimana saya tahu jika proxy adalah masalahnya?

Bandingkan permintaan yang sama di berbagai jenis proxy, wilayah, dan baseline browser normal. Jika kegagalan mengikuti satu rute atau kumpulan, lapisan proxy kemungkinan terlibat.

Metrik apa yang harus saya pantau?

Lacak tingkat keberhasilan, tingkat pemblokiran, tingkat pemblokiran lunak, kedalaman percobaan ulang, CPSR, latensi p95, kelangsungan sesi, akurasi geo, kegagalan otentikasi, dan kesehatan kumpulan proxy.

Pemikiran Akhir

Sebagian besar kesalahan proxy dapat diperbaiki setelah Anda mengidentifikasi lapisan yang gagal. Kesalahan otentikasi memerlukan perbaikan kredensial. Batas laju memerlukan pengaturan. Waktu habis memerlukan pemeriksaan kesehatan rute. Kegagalan TLS dan DNS memerlukan validasi protokol. Pemblokiran lunak memerlukan validasi konten. Ketidakcocokan geo memerlukan pengaturan rute yang lebih baik dan penyesuaian lokal.

Sistem yang paling kuat tidak bergantung pada percobaan ulang buta. Mereka mengklasifikasikan kesalahan, menerapkan perbaikan yang ditargetkan, dan mengukur apakah keluaran yang valid meningkat.

Mulailah dengan metrik yang jelas, uji perubahan dalam pilot kecil, dan skalakan hanya ketika tingkat keberhasilan, akurasi geo, latensi, dan CPSR stabil.