Proksi untuk agen AI: Playwright MCP dan penggunaan browser 2026

AI-agent yang dapat menjelajahi situs web sendiri — Claude dengan Playwright MCP, browser-use, Browserbase berbasis cloud — menghadapi dinding yang sama seperti parser biasa: beberapa puluh permintaan dari satu alamat, dan selanjutnya, alih-alih halaman, muncul tantangan dari Cloudflare. Perbedaannya adalah bahwa agen tidak bisa merasa tersakiti dan hanya terjebak, membakar token dalam upaya "menekan tombol yang tidak ada".

Ini dapat diatasi dengan proxy. Namun, menghubungkan proxy ke agen ternyata tidak semudah yang dibayangkan: setengah dari instruksi di internet menawarkan sintaks yang diabaikan oleh Chromium. Di bawah ini adalah konfigurasi yang berfungsi untuk tiga tumpukan paling umum tahun 2026 dan analisis jebakan yang sering membuat orang terjatuh.

Siapa yang Membutuhkan Ini

Panduan untuk mereka yang sudah menjalankan agen dan mengalami salah satu gejala:

agen menjalankan 10–20 langkah, tetapi setiap langkah berikutnya mengembalikan captcha atau halaman "Verifikasi bahwa Anda manusia";
agen melihat konten yang berbeda dari yang Anda lihat: harga, hasil pencarian, dan ketersediaan produk ditampilkan berdasarkan IP server Anda, bukan berdasarkan negara yang diinginkan;
agen dijalankan di cloud (VPS, GitHub Actions, kontainer), dan alamat pusat data penyedia sudah ditandai sebagai bot;
Anda telah mengonfigurasi proxy dengan login dan kata sandi, tetapi browser mulai seolah-olah proxy tidak ada sama sekali.

Jika Anda masih dalam tahap "mengapa agen diblokir" — baca terlebih dahulu analisis tentang bagaimana sistem anti-bot membedakan browser agen dari manusia: di sana ada sinyal deteksi, dan di sini — praktik murni untuk menghubungkan.

Jebakan №1: Chromium tidak menerima login dan kata sandi dalam string proxy

Kesalahan yang paling umum, dan ini menghabiskan waktu orang untuk debugging. Bentuk klasik dari string dari penyedia adalah user:pass@host:port. Anda memasukkannya ke dalam flag peluncuran browser:

--proxy-server="http://user:[email protected]:8080"

Dan tidak ada yang berfungsi. Chromium tidak mendukung pengiriman kredensial di dalam flag --proxy-server: kesalahan tentang proxy yang tidak didukung muncul di konsol, dan lalu lintas melewati begitu saja. Jika Anda menghapus kredensial dan hanya menyisakan host:port, browser dalam mode biasa akan menampilkan jendela sistem dengan permintaan login dan kata sandi — dan di sini semuanya akan terhenti, karena dalam mode headless tidak ada jendela dan tidak ada yang bisa mengklik di dalamnya.

Dari sini ada tiga jalur kerja, dan Anda harus memilih dengan bijak:

Otorisasi berdasarkan IP (whitelist). Opsi paling bersih untuk agen. Anda menambahkan alamat mesin tempat agen berjalan ke dalam daftar putih di panel penyedia — dan kemudian terhubung tanpa login dan kata sandi, hanya dengan string sederhana host:port. Flag --proxy-server mulai berfungsi seperti yang diharapkan, headless tidak meminta apa pun lagi. ProxyCove mendukung kedua metode — login:kata sandi dan IP-whitelist, dan bahkan secara bersamaan, sehingga untuk agen Anda dapat membuat whitelist, sementara untuk tugas manual tetap menggunakan kata sandi.
Menyampaikan kredensial di tingkat API, bukan flag. Playwright, Puppeteer, dan browser-use dapat menerima username dan password sebagai bidang terpisah — ini bukan mekanisme yang sama dengan flag baris perintah, dan ini berfungsi. Cocok ketika Anda menulis kode agen sendiri.
Relay lokal. Anda mengatur proxy tanpa kata sandi yang meneruskan permintaan ke upstream dengan kata sandi, dan menunjukkan alamat lokal kepada agen. Opsi untuk kasus ketika daftar putih tidak tersedia: misalnya, IP mesin berubah-ubah.

Playwright MCP: konfigurasi yang benar-benar berfungsi

Playwright MCP dari Microsoft — hari ini adalah standar de facto untuk agen yang membutuhkan browser nyata. Proxy ditentukan dengan argumen server langsung dalam konfigurasi klien MCP:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

Yang penting di sini adalah poin-poin berikut:

--proxy-server menerima alamat HTTP dan SOCKS5 dalam bentuk socks5://host:port. Tanpa kredensial — lihat jebakan di atas.
--proxy-bypass — daftar domain yang dipisahkan dengan koma yang tidak melalui proxy. Ini bukan opsi dekoratif: jika agen memiliki layanan internal atau API lokal, mengarahkannya melalui saluran residensial — itu adalah lalu lintas tambahan dengan biaya per gigabyte.
--isolated menyimpan profil dalam memori dan tidak menulisnya ke disk. Berguna ketika setiap tugas harus dimulai dari awal. Sisi negatifnya — cookie tidak bertahan setelah restart, dan setiap sesi untuk situs terlihat seperti pengunjung baru.
--user-data-dir — sebaliknya, profil permanen. Untuk skenario dengan otorisasi, gunakan ini, bukan isolasi, dan pastikan untuk mengunci IP (lihat bagian tentang sticky di bawah).
--storage-state memungkinkan Anda menyisipkan cookie dan localStorage yang disimpan ke dalam sesi terisolasi — kompromi antara dua yang sebelumnya.
--allowed-origins dan --blocked-origins membatasi ke mana agen dapat pergi. Penghematan yang sering diabaikan: agen yang terlibat dalam analitik dan domain iklan dengan mudah dapat meningkatkan penggunaan lalu lintas.
--device (misalnya, "iPhone 15") dan --user-agent mengubah bagaimana agen memperkenalkan dirinya sebagai browser. Atur mereka sesuai dengan jenis proxy: User-Agent seluler di atas IP pusat data — itu adalah kontradiksi yang dibaca oleh sistem anti-bot dengan segera.

Secara terpisah tentang --cdp-endpoint: ini menghubungkan MCP ke browser yang sudah berjalan. Maka proxy diatur tidak dengan flag MCP, tetapi saat memulai browser tersebut — alasan umum mengapa "proxy terdaftar, tetapi IP tetap sama".

browser-use: proxy melalui ProxySettings

Jika agen dibangun di atas browser-use, konfigurasi masuk ke dalam objek pengaturan, dan di sini login dengan kata sandi dapat disampaikan — mereka dikirim melalui API, bukan melalui baris perintah:

from browser_use import Browser, ProxySettings proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1') browser = Browser(proxy=proxy)

Bidang server adalah wajib, yang lainnya opsional. Prinsip yang sama berlaku di Playwright murni: proxy ditentukan baik secara global saat memulai browser, atau secara terpisah untuk setiap konteks melalui browser.newContext({ proxy: { server: ... } }). Yang kedua adalah kunci untuk agen paralel: setiap konteks mendapatkan alamat keluar sendiri, dan sepuluh tugas tidak berbagi satu IP.

Browser cloud: proxy di tingkat sesi

Di Browserbase dan layanan serupa, browser hidup di cloud orang lain, jadi flag peluncuran tidak tersedia untuk Anda — proxy ditentukan dalam parameter sesi, biasanya dengan string seperti http://login:password@gateway:port dalam variabel lingkungan server MCP. Pembatasan Chromium di sini tidak menghalangi: penyedia cloud sendiri mengurai string dan mengatur browser dari dalam.

Nuansa praktis: browser cloud memiliki kumpulan proxy sendiri, dan itu umum untuk semua klien. Jika tugas sensitif terhadap reputasi alamat — masuk ke akun, bekerja dengan platform di mana Anda sudah dikenal — saluran Anda sendiri lebih dapat diprediksi daripada yang umum.

Rotasi atau penguncian: pilih sesuai dengan jenis tugas

Kesalahan pemula — mengaktifkan rotasi untuk setiap permintaan dan heran mengapa agen terputus. Skenario agen memiliki dua mode, dan mereka tidak saling menggantikan:

Rotasi untuk setiap permintaan (di ProxyCove ini adalah port 824) — untuk eksplorasi: melewati seratus kartu produk, mengumpulkan hasil pencarian, memeriksa harga di berbagai wilayah. Setiap permintaan keluar dari alamat baru, menghubungkan mereka satu sama lain sulit.
Sesi yang dikunci (port 10000+, interval perubahan dari 1 hingga 120 menit) — untuk semua yang terdiri dari langkah-langkah: login, keranjang, formulir multi-halaman, dialog panjang dengan antarmuka. Jika IP berubah di tengah rantai, situs setidaknya akan meminta untuk melakukan otorisasi ulang, paling buruk — menandai sesi sebagai mencurigakan.

Agen hampir selalu bekerja dalam mode kedua: ia secara definisi melakukan urutan langkah, bukan satu tembakan. Rincian pemilihan interval dan kesalahan umum dibahas dalam panduan tentang kapan sticky-sesi diperlukan dan bagaimana cara mengaturnya.

Lima jebakan

SOCKS5 dengan otorisasi di Chromium. Sintaks socks5:// ada di Playwright, tetapi kombinasi "SOCKS5 ditambah login dan kata sandi" di browser berbasis Chromium secara historis bermasalah — permintaan terkait di pelacak Playwright dibuka sejak November 2021. Jika ada pilihan, untuk agen gunakan saluran HTTP(S), itu lebih dapat diprediksi.
Kebocoran DNS dan WebRTC. Lalu lintas melalui proxy, tetapi nama diresolusikan secara langsung atau WebRTC memberikan alamat nyata — dan semua penyamaran kehilangan makna. Periksa ini sebelum, bukan setelah menjalankan agen: cara menutup WebRTC saat bekerja melalui proxy.
Ketidaksinkronan geo dan lokal. IP di Jerman, zona waktu mesin Moskow, bahasa antarmuka Inggris — kombinasi yang terlihat seperti otomatisasi. Di Playwright, lokal dan zona waktu ditentukan dengan parameter konteks, sesuaikan dengan negara proxy.
Lalu lintas yang tidak Anda pesan. Agen membuka halaman sepenuhnya, termasuk gambar, font, dan skrip iklan. Di saluran residensial dengan pembayaran per gigabyte, ini adalah pengeluaran yang signifikan — blokir domain yang tidak perlu dan, jika memungkinkan, matikan pemuatan media.
Proxy tidak terdaftar di tempat browser dimulai. Saat bekerja melalui --cdp-endpoint, melalui pembungkus docker, atau melalui layanan cloud, flag MCP tidak mempengaruhi koneksi nyata. Hal pertama yang harus dilakukan setelah pengaturan adalah memaksa agen membuka layanan pemeriksaan IP mana pun dan memastikan bahwa alamat dan negara adalah yang benar.

Jenis proxy apa yang harus diambil untuk agen

Aturannya sederhana: semakin dekat tugas dengan pengguna nyata, semakin "manusiawi" alamatnya harus.

Proxy residensial — dasar untuk agen. Ini adalah alamat dari penyedia rumah, dan untuk situs, agen terlihat seperti pengunjung biasa. Diperlukan di mana pun ada Cloudflare, harga regional, dan setiap petunjuk tentang anti-bot.
Proxy seluler — artileri berat untuk media sosial dan platform di mana akun sangat diperhatikan. Di balik satu alamat seluler, terdapat ribuan pelanggan nyata, jadi memblokirnya sepenuhnya akan mahal bagi platform.
Proxy pusat data — untuk API internal, lingkungan pengujian, dan sumber terbuka tanpa perlindungan. Cepat dan murah, tetapi di situs yang dilindungi, agen akan segera menghadapi tantangan.

Detail berguna untuk skenario agen: perubahan protokol di ProxyCove dilakukan dengan mengganti prefiks dalam string koneksi — HTTP, HTTPS, dan SOCKS5 tersedia pada proxy yang sama, proxy itu sendiri tidak perlu disesuaikan. Negara dalam kumpulan lebih dari 195, jadi "menunjukkan hasil lokal kepada agen" dapat diselesaikan dengan memilih negara saat membeli.

Kesimpulan

Menghubungkan proxy ke AI-agent bukan hanya satu baris, tetapi tiga solusi berturut-turut: bagaimana melakukan otorisasi (untuk agen headless hampir selalu daftar putih IP, bukan kata sandi), di mana menetapkan proxy (flag MCP, objek pengaturan, atau parameter sesi cloud — tetapi pastikan di tempat di mana browser benar-benar dimulai) dan dalam mode apa bekerja (untuk skenario multi-langkah — alamat yang dikunci, bukan rotasi untuk setiap permintaan). Plus pemeriksaan wajib untuk kebocoran DNS dan WebRTC sebelum peluncuran operasional.

Lakukan ini sekali dengan hati-hati — dan agen akan berhenti membakar token untuk berbicara dengan captcha. Proxy residensial ProxyCove terhubung ke Playwright MCP dan browser-use dalam beberapa menit, pembayaran berdasarkan lalu lintas, dan IP-whitelist untuk mode headless diaktifkan di panel.