Mengapa proxy menjadi lambat? Diagnostik lanjutan: pelacakan, MTR, dan analisis header.

31 Maret 2026

Mengapa proxy menjadi lambat? Diagnostik lanjutan: pelacakan, MTR, dan analisis header.

Anda membeli proksi statis premium, menghubungkannya ke browser anti-deteksi, membuka situs yang diinginkan... dan halaman tersebut memuat dengan sangat lambat. Pemikiran pertama yang muncul sangat logis: "Saya telah dijual proksi yang buruk."

Namun, internet bukanlah pipa lurus antara komputer Anda dan situs tujuan. Ini adalah jaringan logistik yang sangat kompleks, terdiri dari puluhan node transit, kabel utama, dan protokol keamanan. Kecepatan bisa turun di tahap mana pun dari proses ini.

Dalam artikel ini, kita akan membahas metode lanjutan untuk mendiagnosis koneksi jaringan. Anda akan belajar menemukan penyebab sebenarnya dari keterlambatan dan berbicara dengan layanan dukungan penyedia proksi dalam bahasa teknis yang sama.


🌍 Alasan 1: Fisika dan Perutean (Routing)

Penyebab paling umum dari kinerja yang lambat adalah mengabaikan hukum fisika. Kecepatan cahaya itu terbatas, dan data dikirimkan melalui kabel serat optik.

Jika Anda secara fisik berada di Berlin, membeli proksi di Los Angeles, dan kemudian menggunakannya untuk membuka situs yang servernya berada di Paris, data Anda melakukan perjalanan transatlantik dua kali.

Rute: Berlin ➡️ Los Angeles ➡️ Paris ➡️ Los Angeles ➡️ Berlin.

Ping (waktu respons) dalam skema seperti ini pasti akan mencapai 200–300 milidetik. Untuk memuat situs web yang berat dengan banyak skrip, ini akan memakan waktu tunggu beberapa detik.

Cara mengatasinya: Selalu usahakan untuk memilih lokasi geografis (GEO) proksi yang sedekat mungkin dengan lokasi fisik Anda atau dengan server sumber daya target.


🕵️‍♂️ Alasan 2: Masalah pada Jaringan Utama (Menggunakan MTR)

Bahkan jika server proksi kuat dan situs target berfungsi dengan sempurna, masalah dapat muncul di tengah jalan antara keduanya. Penyedia layanan bertukar lalu lintas melalui node komunikasi (operator Tier-1). Jika terjadi kecelakaan atau kelebihan beban pada salah satu node di Frankfurt atau Amsterdam, lalu lintas Anda akan hilang.

Untuk menemukan node yang "rusak" ini, para profesional menggunakan MTR (My Traceroute). Ini adalah utilitas yang menggabungkan fungsi ping dan traceroute. Program ini mengirimkan paket data ke seluruh rantai dan menunjukkan statistik untuk setiap tautan.

Cara melakukan diagnosis:

  1. Untuk Windows, unduh program gratis WinMTR. Untuk macOS/Linux, MTR diinstal melalui terminal (misalnya, brew install mtr).

    👉 Tautan ke repositori GitHub

  2. Di kolom Host, masukkan alamat IP server proksi Anda (misalnya, [ALAMAT_IP_PROKSI_ANDA]) dan tekan Start.

  3. Catatan teknis penting: Banyak orang mencoba mengaktifkan proksi di sistem, memasukkan alamat situs akhir (misalnya, google.com) di WinMTR, dan berharap lalu lintas akan melewati proksi. Ini tidak akan berhasil. Proksi (HTTP/SOCKS5) tidak dapat melewatkan lalu lintas ICMP tingkat rendah yang digunakan oleh ping dan WinMTR. Jika Anda melakukannya, program hanya akan menunjukkan rute rumah langsung Anda tanpa melalui proksi.

    Itulah sebabnya di kolom Host Anda harus memasukkan secara eksklusif alamat IP server proksi Anda. Dengan cara ini kita memeriksa kualitas koneksi pada segmen "Anda ➡️ Proksi".

  4. Biarkan program berjalan selama 1–2 menit agar mengirimkan setidaknya 100 paket.

Antarmuka program WinMTR
Gbr 1. Antarmuka program WinMTR

Setelah Anda melakukan tes (mengirim setidaknya 100–200 paket), hasilnya perlu dicatat. Di WinMTR ada empat tombol di bagian atas jendela untuk tujuan ini:

  • Copy Text/HTML to clipboard: Menyalin data dengan cepat untuk ditempelkan langsung ke email atau chat dukungan.

  • Export TEXT/HTML: Menyimpan file secara lengkap. Versi HTML lebih nyaman dilihat karena mempertahankan struktur tabel.

Contoh hasil tes:

Host

Loss %

Sent

Recv

Best

Avrg

Wrst

Last

Home-Router

0

1272

1272

2

3

326

2

ISP-Gateway

1

1269

1268

5

7

74

7

Local-ISP-Node-A

3

1145

1112

5

6

31

6

Local-ISP-Node-B

1

1268

1267

5

8

171

6

Transit-Gateway-X

100

258

2

0

6

7

7

Regional-Hub-1

0

1273

1273

6

9

86

7

Regional-Hub-2

85

293

46

0

7

23

9

Regional-Hub-3

4

1136

1100

6

7

27

7

Regional-Hub-4

53

413

196

0

7

19

7

Regional-Hub-5

19

733

595

7

8

25

8

Global-Transit-A

0

1273

1273

7

9

74

8

Global-Transit-B

18

764

634

31

33

46

46

No response from host

100

257

0

0

0

0

0

Backbone-EU-AMS

1

1246

1240

196

197

278

197

Backbone-EU-LIL

1

1257

1253

191

192

207

193

Backbone-EU-PAR

1

1269

1268

198

199

227

201

Backbone-EU-SBG

0

1272

1272

208

212

313

249

ns3261405.ip-51-77-190.eu

1

1268

1267

205

206

229

206

Cara membaca hasil WinMTR: Perhatikan kolom Loss % (persentase paket yang hilang).

  • Jika kehilangan paket dimulai pada 1-2 langkah pertama, masalahnya ada pada router rumah atau penyedia internet Anda.

  • Jika kehilangan paket ada di tengah daftar (pada node dengan nama aneh seperti ae1.level3.net), masalahnya ada pada saluran utama global.

Hostname

Loss %

Sent

Recv

Best

Avrg

Wrst

Last

192.168.1.1

0

1304

1304

2

3

326

3

...intermediate-node...

100

301

47

0

7

23

7

be102.ams-gsa1-sbb2-nc5.nl.eu

1

1277

1270

196

197

278

197

ns3261405.ip-51-77-190.eu

1

1300

1299

205

206

229

206

  • Jika Anda melihat 100% loss (No response from host) pada salah satu node perantara, tetapi tidak ada kehilangan paket pada alamat tujuan akhir — jangan panik. Node tersebut hanya diatur untuk mengabaikan ping, tetapi lalu lintas utama Anda tetap lewat tanpa masalah.

  • Jika kehilangan paket hanya terjadi pada langkah terakhir (alamat proksi Anda) — berarti server tersebut memang kelebihan beban, dan Anda harus menghubungi dukungan penyedia.

Screenshot MTR dengan kehilangan paket pada node utama adalah bukti terbaik bagi dukungan teknis yang akan menghemat waktu korespondensi Anda.

Lalu bagaimana cara memeriksa rute dari proksi ke situs tujuan? Jika WinMTR menunjukkan paket sampai ke proksi dengan sempurna tetapi situs tetap lambat, masalahnya mungkin ada pada jaringan antara proksi itu sendiri dan server situs. Untuk memeriksa bagian ini, gunakan layanan publik Looking Glass. Cukup cari di Google "Looking Glass [negara proksi Anda]" — di situs-situs ini Anda dapat menjalankan ping dan traceroute langsung dari lokasi proksi ke situs target.


⏱️ Alasan 3: TLS Handshake dan Pemeriksaan Tersembunyi (cURL)

Terkadang MTR menunjukkan gambaran yang ideal: tidak ada paket yang hilang, ping rendah. Namun situs tetap memuat dengan lambat. Di sinilah protokol enkripsi dan sistem perlindungan (seperti Cloudflare) berperan.

Untuk memahami ke mana waktu terbuang saat memuat halaman, administrator sistem menggunakan utilitas konsol cURL. Buka terminal dan lakukan permintaan lanjutan ke situs melalui proksi Anda:

bash
curl -x socks5://user:pass@IP:PORT -w "DNS: %{time_namelookup}s \nConnect: %{time_connect}s \nTLS: %{time_appconnect}s \nTTFB: %{time_starttransfer}s \nTotal: %{time_total}s \n" -o /dev/null -s https://google.com

Hasil output permintaan:

bash
DNS: 0.000616s
Connect: 0.209187s
TLS: 3.170403s
TTFB: 3.947665s
Total: 3.948056s

Arti dari metrik ini:

  • DNS: Waktu mencari alamat IP situs. Jika lama, mungkin proksi menggunakan server DNS yang lambat.

  • Connect: Waktu pembuatan koneksi TCP.

  • TLS: Waktu "jabat tangan" kriptografi (pengaturan HTTPS).

  • TTFB (Time To First Byte): Waktu tunggu byte pertama dari server.

Jika Connect cepat tetapi TTFB memakan waktu 5 detik — ini berarti proksi berfungsi dengan baik, tetapi situs target sengaja menunda respons. Seringkali ini adalah cara kerja sistem anti-fraud tersembunyi: mereka melihat lalu lintas yang mencurigakan, melakukan pemeriksaan latar belakang (js-challenges), dan baru kemudian memberikan konten.


📝 Alasan 4: Header "Kotor" (Header Analysis)

Pemuatan yang lambat bisa jadi akibat dari penggunaan proksi HTTP gratis yang tidak memberikan anonimitas yang memadai. Beberapa proksi menambahkan header HTTP khusus ke lalu lintas Anda:

  • X-Forwarded-For: [IP asli Anda]

  • Via: 1.1 proxy.server

Ketika sistem perlindungan situs melihat header ini, mereka segera menyadari: ada seseorang yang datang melalui server perantara (proksi). Dalam kasus terbaik, Anda akan diberikan captcha (yang secara visual terlihat seperti "lambat"), dalam kasus terburuk — koneksi akan diblokir.

Solusi: Gunakan protokol SOCKS5. Berbeda dengan HTTP, protokol ini bekerja pada tingkat jaringan yang lebih rendah dan sama sekali tidak berinteraksi dengan header HTTP, mengirimkan lalu lintas Anda dalam bentuk aslinya. Atau pilih proksi HTTP Elite dari pemasok tepercaya yang menjamin penghapusan header yang mencurigakan.


Kesimpulan: Daftar Periksa Penyelamatan Kecepatan

Jika proksi Anda tiba-tiba mulai melambat, jangan terburu-buru membuangnya. Ikuti 4 langkah ini:

  1. Periksa Logika GEO: Apakah Anda mengirim lalu lintas ke ujung dunia dan kembali lagi?

  2. Ganti Protokol: Jika menggunakan HTTP, beralihlah ke SOCKS5 (atau sebaliknya). Terkadang masalah terletak pada beban port tertentu.

  3. Lakukan Pelacakan: Jalankan WinMTR ke alamat IP proksi. Jika ada kehilangan paket di jaringan utama — tunggu saja, biasanya kecelakaan seperti itu diperbaiki dalam beberapa jam.

  4. Kumpulkan Fakta untuk Dukungan: Jika WinMTR menunjukkan kehilangan paket pada node akhir, ambil screenshot atau laporan (txt, html) dan kirimkan ke penyedia. Dengan argumen seperti ini, tiket Anda akan langsung mendapatkan prioritas tertinggi.