Cara Mengukur Kecepatan dan Uptime Proxy Sendiri: Metode yang Dapat Diulang

Kecepatan proxy bukanlah satu angka: itu adalah latensi (berapa lama hingga byte pertama), throughput (seberapa cepat byte tiba), dan tingkat keberhasilan (seberapa sering Anda mendapatkan respons yang dapat digunakan) — yang masing-masing bervariasi berdasarkan jam, target, dan IP keluar. Satu tes pada satu saat hampir tidak memberi tahu Anda apa pun, itulah sebabnya angka pemasaran penyedia dan ulasan sekali jalan begitu mudah dibuat dan sulit ditindaklanjuti. Ini adalah metode yang kami gunakan untuk peringkat kami sendiri: apa yang harus diukur, bagaimana, seberapa sering, dan bagaimana merangkumnya agar hasilnya bermakna.

Empat angka

Metrik	Apa yang dijawabnya	Bagaimana mendapatkannya	Nilai bagus yang umum
Latensi (TTFB)	Berapa lama setiap permintaan menunggu sebelum data mulai	curl -w %{time_starttransfer} pada sumber daya kecil	Datacenter: +10–50 ms di atas langsung; residential/mobile: +80–300 ms
Throughput	Seberapa cepat data massal bergerak	Waktu unduhan ukuran tetap (1–10 MB)	Datacenter: mendekati kecepatan garis; residential: 5–50 Mbit/s; mobile: 5–30 Mbit/s
Tingkat keberhasilan	Seberapa sering permintaan selesai dengan 2xx nyata	Hitung hasil dari banyak permintaan	>98% pada target netral; lebih rendah pada target yang dilindungi adalah tindakan target
Uptime	Seberapa sering proxy dapat dijangkau sama sekali	Probe konektivitas berkala selama berhari-hari	>99.5% untuk datacenter/ISP; kumpulan rotasi menyembunyikan kegagalan individu

Laporan yang memberikan satu angka “kecepatan” biasanya melaporkan throughput pada unduhan besar dari proxy datacenter pada jam sepi — kombinasi yang paling menyanjung.

Prinsip sebelum perintah

1. Ukur perbedaannya, bukan absolutnya. Selalu jalankan permintaan yang sama langsung dan melalui proxy, secara berurutan, dan laporkan selisihnya. Variabilitas koneksi Anda sendiri akan tercampur dengan proxy.
2. Target yang sama, selalu. Gunakan endpoint kecil, cepat, dan stabil yang tidak membatasi kecepatan — file statis di CDN besar, atau server Anda sendiri. Jangan pernah melakukan benchmark terhadap situs yang ingin Anda scrape; respons anti-botnya adalah pengukuran yang berbeda.
3. Banyak sampel, tersebar dari waktu ke waktu. Setidaknya 20 permintaan per sesi; sesi pada beberapa jam dalam sehari dan selama seminggu. Proxy adalah infrastruktur bersama dan beban mengikuti jam kerja di wilayah penyedia dan IP keluar.
4. Laporkan persentil, bukan rata-rata. Satu timeout 30 detik merusak rata-rata. Median (p50) memberi tahu pengalaman tipikal; p95 memberi tahu pengalaman hari buruk; keduanya lebih penting daripada rata-rata.
5. Lakukan pemanasan. Buang permintaan pertama dari setiap sesi — pengaturan sesi DNS dan TLS membuatnya lebih lambat dari yang lain.
6. Ubah satu hal pada satu waktu. Membandingkan datacenter penyedia A dengan residential penyedia B membandingkan tipe, bukan penyedia.

Latensi dengan curl

# langsung
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# melalui proxy
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

Melalui proxy, time_connect adalah waktu untuk mencapai proxy; koneksi tujuan dan TLS terjadi di dalam tunnel dan masuk ke time_appconnect/time_starttransfer. Angka yang harus dibandingkan adalah ttfb: proxy dikurangi langsung adalah latensi tambahan proxy. Ulangi:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Throughput

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Gunakan file yang cukup besar sehingga pengaturan koneksi menjadi sebagian kecil (5–10 MB), cukup kecil agar tidak menghabiskan kuota residential per-GB di banyak sesi. Pada kumpulan rotasi, throughput bervariasi dengan koneksi host keluar; jalankan cukup sampel untuk melihat distribusi, dan ingat bahwa pada paket per-GB, throughput juga menentukan seberapa cepat Anda menghabiskan uang.

Tingkat keberhasilan

Setiap permintaan berakhir dengan salah satu dari: 2xx dengan body ukuran yang diharapkan; 4xx/5xx dari target; kesalahan proxy (407, koneksi ditolak, timeout); atau halaman tantangan (CAPTCHA/interstitial) dengan status 200 — yang terakhir adalah yang sering terlewat oleh penghitung naif, jadi periksa body, bukan hanya kodenya. Dalam Python:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Pisahkan kegagalan proxy (407, kesalahan koneksi, timeout ke proxy) dari kegagalan target (403, 429, tantangan). Yang pertama adalah masalah penyedia; yang kedua tentang reputasi IP pada target tersebut dan termasuk dalam tes yang berbeda — lihat cara sistem anti-bot menilai permintaan.

Uptime

Uptime adalah tingkat keberhasilan dari waktu ke waktu. Jadwalkan probe ringan — perintah latensi di atas, atau CONNECT sederhana — setiap 5–15 menit selama setidaknya seminggu, catat hasilnya dengan stempel waktu, dan hitung fraksi probe yang berhasil. Dua kehalusan:

• Kumpulan rotasi menyembunyikan kegagalan. Jika satu exit mati, Anda mendapatkan yang lain; gateway itu sendiri yang memiliki uptime. Probe gateway, dan secara terpisah lacak seberapa sering IP yang ditugaskan berubah ketika Anda meminta sesi sticky — perubahan yang tidak terduga adalah kegagalan lunak.
• IP statis (datacenter, ISP) adalah yang biasanya diklaim “99.9%”. 99.9% adalah 43 menit downtime per bulan; 99.5% adalah 3.6 jam. Keduanya mudah dibedakan dari seminggu probe 15 menit.

Menjadwalkan sesi

Jadwal minimal namun bermakna: latensi + keberhasilan (20–50 permintaan) pada 03:00, 09:00, 14:00, dan 20:00 waktu lokal IP keluar, setiap hari selama tujuh hari; throughput sekali per sesi; probe konektivitas setiap 15 menit sepanjang waktu. Itu beberapa ratus kilobyte per hari per proxy untuk latensi dan beberapa puluh megabyte untuk throughput — terjangkau bahkan pada paket per-GB jika Anda menggunakan file kecil. Jalankan dari mesin yang tetap menyala (VPS kecil ideal) dengan cron, dan tulis satu baris CSV per permintaan. Peringkat kami yang diterbitkan — misalnya peringkat kecepatan dan peringkat keandalan — dibangun dari rangkaian seminggu persis seperti ini, bukan dari satu sore.

Membaca hasil

• Latensi p50 mendekati norma tipe dan p95 dalam ~3× p50: sehat. p95 yang jauh lebih besar dari p50 berarti kemacetan intermiten — penyedia kelebihan kapasitas pada jam sibuk.
• Tingkat keberhasilan di bawah ~97% pada target netral dari kesalahan sisi proxy: masalah infrastruktur, bukan Anda.
• Siang hari jauh lebih buruk daripada malam: kapasitas bersama; tanyakan tentang opsi khusus atau terima dalam penjadwalan.
• Angka bagus di datacenter, buruk di residential dari penyedia yang sama: normal — produk berbeda; bandingkan residential dengan residential.
• Uptime di bawah klaim: Anda sekarang memiliki log untuk ditunjukkan ke dukungan, yang lebih berharga daripada keluhan.

Terakhir, ingat jenisnya. Proxy residential dan mobile lebih lambat secara konstruksi — lalu lintas benar-benar melalui jalur rumah atau menara seluler — dan membelinya untuk kecepatan adalah kesalahan kategori; lihat perbandingan jenis proxy. Ukur mereka terhadap kelas mereka sendiri dan terhadap apa yang sebenarnya dibutuhkan tugas Anda. Perhatikan juga bahwa koneksi proxy menggunakan HTTP/2, bukan HTTP/3, jadi bandingkan seperti dengan seperti ketika baseline langsung berada di situs yang mendukung QUIC (detail).

Pertanyaan yang sering diajukan

Bagaimana cara menguji kecepatan proxy?

Minta sumber daya kecil yang sama secara langsung dan melalui proxy, berkali-kali, pada beberapa waktu dalam sehari; bandingkan waktu-ke-byte-pertama (latensi) dan, secara terpisah, waktu unduhan ukuran tetap (throughput). Laporkan median dan persentil ke-95, bukan rata-rata.

Berapa latensi proxy yang baik?

Relatif terhadap koneksi langsung: proxy datacenter menambah puluhan milidetik; residential dan mobile menambah sekitar 80–300 ms karena lalu lintas melewati koneksi konsumen. Nilai setiap jenis terhadap normanya sendiri.

Bagaimana cara memeriksa uptime proxy?

Probe secara terjadwal (setiap 5–15 menit) selama setidaknya seminggu, catat setiap hasil, dan hitung fraksi probe yang berhasil. Untuk kumpulan rotasi, probe gateway; untuk IP statis, probe IP itu sendiri.

Mengapa hasil saya berbeda dari klaim penyedia?

Klaim biasanya kasus terbaik: produk datacenter, jam sepi, unduhan besar, sampel tunggal. Pengukuran Anda mencakup jam sibuk, IP keluar spesifik yang Anda terima, dan persentil. Angka Anda adalah yang memprediksi pengalaman Anda.

Haruskah saya melakukan benchmark terhadap situs yang ingin saya scrape?

Tidak untuk kecepatan. Lapisan anti-botnya akan menambahkan tantangan dan blokir yang mengukur reputasi IP, bukan kinerja proxy. Gunakan sumber daya statis netral untuk kecepatan dan jalankan tes reputasi secara terpisah.

Berapa banyak sampel yang saya butuhkan?

Setidaknya 20 per sesi untuk mendapatkan median yang stabil, beberapa sesi sehari selama seminggu untuk melihat efek waktu-dalam-hari dan hari-dalam-minggu. Uptime membutuhkan seminggu penuh.