AI proxy: Bagaimana proxy mendukung agen AI

Agen AI dapat merencanakan tugas, memilih alat, membuka browser, mencari situs web, membandingkan hasil, dan memutuskan apa yang harus dilakukan selanjutnya. Tetapi saat ia mencapai web, sesuatu yang sangat biasa terjadi: ia membuat permintaan jaringan.
Permintaan tersebut tetap berasal dari alamat IP, dan memiliki lokasi, rute jaringan, dan sesi di belakangnya. Tergantung pada tugasnya, agen mungkin perlu mempertahankan IP tersebut untuk seluruh perjalanan browser, mengakses web dari lokasi tertentu, atau mendistribusikan ribuan permintaan independen di seluruh pool IP yang berputar.
Di sinilah proxy AI berperan.
Untuk agen browser, agen scraping, alat riset, dan otomasi terhubung web lainnya, proxy AI mengontrol rute jaringan antara alat akses web agen dan tujuannya. Proxy dapat menentukan jenis dan lokasi IP, berapa lama IP tetap dengan sesi, dan kapan traffic berpindah melalui pool yang lebih besar.
CyberYozh App menyediakan lapisan jaringan tersebut melalui proxy agen AI, infrastruktur agen browser, proxy residensial, rute mobile, IP datacenter, dan integrasi dengan alat otomasi umum.
AI tetap melakukan pemikiran. Proxy menangani bagaimana AI tersebut mencapai web.
TL;DR
Proxy AI dapat berarti dua hal berbeda: proxy jaringan yang mengontrol bagaimana agen AI mencapai web, atau gateway AI/proxy LLM yang mengelola permintaan antara aplikasi dan penyedia model.
Untuk agen terhubung web, proxy berada di antara browser atau klien HTTP dan tujuan, mengontrol exit IP, lokasi, jenis jaringan, perilaku sesi, dan rotasi.
Proxy AI dapat mendukung agen browser, web scraping AI, RAG dan pengambilan web, riset, lokalisasi dan QA, serta monitoring ketika rute jaringan penting untuk tugas tersebut.
Pilih proxy berdasarkan beban kerja: ISP statis untuk sesi stabil yang lebih lama, residensial sticky untuk kontinuitas sementara, residensial rotating untuk permintaan independen, mobile ketika routing carrier penting, dan datacenter ketika infrastruktur yang lebih sederhana sudah cukup.
Konfigurasikan proxy di alat yang benar-benar mengakses web, seperti Playwright, Puppeteer, Selenium, Scrapy, atau Postman, bukan di language model itu sendiri.
Rotasi tidak otomatis lebih baik. Pertahankan rute tetap stabil ketika permintaan termasuk dalam sesi yang sama dan lakukan rotasi ketika beban kerja terdiri dari permintaan independen.
Proxy menangani lapisan jaringan saja. Proxy tidak mengamankan prompt, mengelola state browser, memperbaiki logika ekstraksi, mengontrol izin agen, atau membuat keputusan model lebih aman.
Dengan CyberYozh App, pengaturan praktisnya adalah memilih lokasi dan perilaku sesi yang tepat, mengonfigurasi koneksi di tool akses web, memverifikasi IP keluar, dan menambahkan kontrol berbasis API hanya ketika alur kerja memerlukannya.
Apa itu AI proxy?
AI proxy adalah perantara yang digunakan dalam alur kerja AI untuk merutekan koneksi antara berbagai bagian sistem. Apa yang sebenarnya dihubungkan tergantung pada jenis AI proxy yang Anda maksud: network proxy untuk AI agent yang mengontrol bagaimana AI agent mengakses web, atau AI gateway atau LLM proxy yang mengelola bagaimana aplikasi berkomunikasi dengan penyedia model.
Keduanya berada di lapisan berbeda dari stack AI dan menyelesaikan masalah yang berbeda.
Network proxy untuk AI agent
Inilah yang terutama kita bahas dalam artikel ini.
Alurnya terlihat seperti ini:
AI agent → browser atau HTTP client → proxy → website
AI proxy mengontrol koneksi jaringan antara tool agent dan tujuannya.
Hal tersebut dapat mengubah:
Alamat IP yang terlihat
Lokasi geografis koneksi
Jenis jaringan, seperti residential, mobile, ISP, atau datacenter
Berapa lama IP yang sama tetap terhubung ke sesi
Bagaimana permintaan didistribusikan di seluruh pool IP
Dapatkan CyberYozh App AI agent proxy.
AI gateway atau LLM proxy
AI gateway berada di tempat lain.
Alurnya lebih seperti:
Aplikasi → AI gateway → penyedia model
Ini dapat memusatkan perutean model, logging, retry, kontrol rate, pemilihan penyedia, dan fungsi tingkat API serupa. Cloudflare, misalnya, mendeskripsikan AI Gateway-nya sebagai lapisan untuk mengamati dan mengontrol permintaan model dengan fitur termasuk logging, caching, rate limiting, retry, dan fallback. Dokumentasi Cloudflare AI Gateway
Itu adalah infrastruktur yang berguna, tetapi tidak sama dengan memberikan IP residential kepada browser agent.
Tips: AI gateway mengontrol bagaimana aplikasi Anda mengakses model. Network AI proxy mengontrol bagaimana agent mengakses web. Keduanya dapat ada dalam sistem yang sama.
Proxy jaringan untuk agen AI | |
Berada di antara | Browser/klien agen dan situs web |
Mengontrol | IP, lokasi, jenis jaringan, sesi sticky, rotasi |
Penggunaan umum | Agen browser, web scraping, riset, pengujian regional |
Contoh alur | Agen → proxy → situs web |
CyberYozh App menyediakan ini? | Ya |
Bagaimana cara kerja proxy AI?
Proxy AI jaringan bekerja di antara tool yang digunakan agen AI untuk mengakses web dan situs web atau layanan yang perlu dijangkau. Alih-alih terhubung langsung dari mesin yang menjalankan agen, permintaan pertama-tama melewati server proxy.
Rute dasarnya terlihat seperti ini:
Agen AI → browser atau klien HTTP → server proxy → situs web
Ketika browser, scraper, atau klien HTTP mengirim permintaan, proxy menerimanya dan meneruskannya ke tujuan menggunakan IP exit dari jaringannya. Situs web melihat IP exit tersebut, bukan IP mesin yang menjalankan agen. Respons kemudian berjalan kembali melalui proxy ke tool akses web agen.
Apa yang terjadi pada IP sepanjang perjalanan bergantung pada konfigurasi proxy. Agen mungkin mempertahankan IP yang sama sepanjang sesi browser multi-langkah, menggunakan IP sticky untuk periode tertentu, atau mengambil IP exit yang berbeda dari pool rotasi untuk permintaan independen. Lokasi juga dapat dipilih ketika alur kerja memerlukan akses web dari negara atau wilayah tertentu.
Mengapa agen AI menggunakan proxy saat mengakses web
Jika agen AI tetap berada di dalam database atau perangkat lunak internal Anda, mungkin tidak memerlukan proxy sama sekali.
Proxy menjadi relevan ketika agen mulai berinteraksi dengan situs web dan layanan eksternal.
Pikirkan tentang agen riset yang harus membuka ratusan halaman produk publik. Atau agen QA yang menguji situs web dari beberapa negara. Atau agen browser yang perlu tetap berada dalam sesi yang sama sambil melalui alur kerja lima langkah.
Pekerjaan-pekerjaan tersebut memiliki persyaratan jaringan yang sangat berbeda.
Agen browser AI memerlukan rute yang konsisten
Agen browser mungkin mencari, mengklik, menavigasi, membandingkan informasi, mengambil tangkapan layar, mengisi formulir yang disetujui, atau berinteraksi dengan aplikasi web.
Jika alur kerja berlangsung beberapa menit, mengubah IP di tengah jalan mungkin tidak perlu atau justru tidak membantu.
Untuk jenis pekerjaan ini, rute jaringan biasanya harus dapat diprediksi.
Lingkungan browser masih merupakan lapisan terpisah. Cookie, storage, header, sesi, dan keamanan browser tidak hilang hanya karena IP berubah.
Proxy menangani identitas jaringan. Ini tidak menggantikan desain agen browser yang baik.
Agen riset AI mungkin memerlukan kontrol lokasi
Bayangkan agen AI yang membandingkan hasil pencarian publik, harga, ketersediaan, atau halaman yang dilokalkan di beberapa negara.
Menjalankan setiap permintaan dari satu lokasi cloud dapat memberikan gambaran yang sangat tidak lengkap kepada agen.
Proxy memungkinkan agen membuat permintaan melalui rute di wilayah yang sedang diuji.
Itu tidak mengubah identitas atau kelayakan pengguna untuk suatu layanan. Ini hanya mengubah lokasi jaringan yang digunakan untuk permintaan.
Agen scraping AI mungkin memerlukan beberapa IP
Pengumpulan data publik berskala besar memiliki bentuk yang berbeda.
Agen mungkin tidak peduli untuk mempertahankan satu identitas browser selama satu jam. Agen mungkin mengambil banyak halaman independen, memvalidasi respons, mengekstrak informasi terstruktur, dan melanjutkan.
Di sinilah AI web scraping dan infrastruktur proxy rotating menjadi lebih berguna.
Scraper masih memerlukan logika retry, parsing, deduplikasi, validasi, dan pacing permintaan yang masuk akal. Proxy hanya menyelesaikan bagian routing jaringan dari sistem tersebut.
Proxy adalah infrastruktur, bukan kecerdasan. Proxy dapat meningkatkan cara agen mencapai sumber daya, tetapi tidak dapat memperbaiki logika ekstraksi yang buruk atau keputusan buruk yang dibuat oleh model.
Kasus penggunaan proxy AI
Proxy AI menjadi berguna ketika sistem AI perlu berinteraksi dengan web publik dan rute jaringan penting untuk tugas tersebut. Peran spesifik proxy bergantung pada apa yang coba diambil, diuji, dipantau, atau diotomatisasi oleh agen.
Kasus penggunaan | Apa yang dilakukan AI | Apa yang ditambahkan proxy |
Agen browser | Menavigasi situs web dan menyelesaikan tugas multi-langkah | Sesi stabil dan kontrol atas lokasi jaringan |
AI web scraping | Mengumpulkan data publik dari banyak halaman | Akses ke pool IP rotating untuk permintaan independen |
RAG dan pengambilan web | Mengambil konten web terkini sebelum meneruskannya ke LLM | Akses terdistribusi dan sadar lokasi ke halaman sumber |
Agen riset | Membandingkan informasi publik di berbagai situs web atau pasar | Routing IP regional untuk hasil yang dilokalkan |
Lokalisasi dan QA | Menguji bagaimana situs atau aplikasi berperilaku dari berbagai wilayah | Akses dari IP di lokasi yang diuji |
Agen pemantauan | Memeriksa halaman publik berulang kali untuk perubahan | Rute konsisten atau terdistribusi tergantung pada pekerjaan pemantauan |
RAG dan pengambilan web
Retrieval-augmented generation menjadi sangat relevan ketika informasi yang dibutuhkan sistem AI tidak tersedia dalam model atau basis pengetahuan internalnya.
Workflow RAG dapat mengambil informasi dari database, API, dokumen, atau web sebelum menyediakan materi yang relevan ke model. Ketika sumber pengambilan adalah situs web publik, komponen akses web masih harus membuat permintaan jaringan biasa.
Proxy dapat mengontrol IP dan lokasi yang digunakan untuk permintaan tersebut. Ini menjadi berguna ketika sistem retrieval mengumpulkan informasi publik di berbagai wilayah atau mendistribusikan beban kerja retrieval yang lebih besar melalui beberapa rute.
Proxy tidak melakukan retrieval atau meningkatkan penalaran model. Proxy menyediakan lapisan jaringan yang digunakan untuk mencapai sumber-sumber dari mana sistem RAG mengambil informasi.
Geo targeting dan QA berbasis AI
Agen AI juga dapat mengotomatiskan bagian dari pengujian situs web dan aplikasi regional. Agen mungkin memeriksa halaman yang dilokalkan, hasil pencarian, ketersediaan produk, variasi bahasa, atau konten lain yang dapat berbeda tergantung dari mana permintaan berasal.
Merutekan agen melalui proxy di lokasi yang diuji memungkinkan alur kerja QA mengamati web dari lokasi jaringan tersebut daripada sepenuhnya bergantung pada server tempat otomasi berjalan.
Dapatkan proxy geotargeting CyberYozh App untuk tampil sebagai pengguna lokal asli di negara, kota, atau jaringan operator mana pun.
Agen monitoring
Agen monitoring berulang kali memeriksa sumber daya publik untuk perubahan, seperti informasi produk, ketersediaan, hasil pencarian, data pasar, atau pembaruan situs web.
Agen yang berulang kali memeriksa sumber daya yang sama mungkin bekerja dengan sempurna dengan rute yang konsisten, sementara sistem monitoring yang lebih besar yang mencakup banyak sumber independen mungkin mendapat manfaat dari mendistribusikan permintaan di seluruh pool IP.
Seperti kasus penggunaan proxy AI lainnya, strategi jaringan harus mengikuti beban kerja daripada menerapkan rotasi hanya karena tersedia.
Jenis proxy AI mana yang harus Anda gunakan?
Tidak ada satu proxy terbaik untuk setiap agen AI.
Pilihan terbaik tergantung pada apa yang dilakukan agen setelah meninggalkan infrastruktur Anda dan mencapai web publik.
Beban kerja AI | Proxy yang dipertimbangkan | Alasan |
Tugas browser multi-langkah | ISP statis | Mempertahankan satu IP yang konsisten |
Sesi browser residential | Residential sticky | Mempertahankan rute residential untuk sesi |
Beban kerja data publik besar | Residential rotating | Mendistribusikan permintaan independen |
Gateway rotating otomatis | Proxy backconnect | Memberikan klien satu gateway sementara exit berotasi |
Pengujian jaringan mobile | Mobile | Menggunakan infrastruktur LTE/5G |
Otomasi sederhana | Datacenter | Sederhana dan hemat biaya ketika routing residential tidak diperlukan |
Proxy ISP statis untuk sesi agen AI yang panjang
Agen yang berjalan lama sering mendapat manfaat dari rute yang stabil.
Misalnya, jika agen membuka situs web, menavigasi melalui beberapa halaman, memilih opsi, dan kemudian mengembalikan hasil, mempertahankan satu IP sepanjang perjalanan lebih mudah dipahami.
Proxy ISP statis CyberYozh App memberikan alur kerja tersebut alamat persisten yang didukung ISP.
Ini biasanya lebih tepat daripada merotasi IP hanya karena rotasi tersedia.
Proxy residential sticky untuk kontinuitas sementara
Terkadang Anda menginginkan routing residential tanpa mempertahankan IP yang sama tanpa batas waktu.
Sesi sticky memungkinkan beberapa permintaan terkait berbagi exit untuk periode yang ditentukan.
Ini dapat bekerja dengan baik ketika agen membutuhkan kontinuitas sesi tetapi sistem yang lebih besar masih menggunakan pool residential.
Proxy residential rotating untuk permintaan independen
Jika agen mengumpulkan banyak halaman publik yang tidak terkait, rotasi menjadi lebih berguna.
CyberYozh App proxy residential rotating dapat mendukung beban kerja di mana permintaan yang berbeda tidak perlu berbagi satu identitas jaringan yang berumur panjang.
Proxy backconnect untuk rotasi otomatis
Sebuah proxy backconnect memberikan otomasi Anda satu gateway proxy sementara infrastruktur mengelola perubahan IP exit di belakangnya.
Ini dapat menyederhanakan beberapa arsitektur agen karena klien tidak perlu memelihara daftar besar alamat proxy individual.
Untuk otomasi volume tinggi, ini sering kali lebih mudah dikelola daripada memasukkan IP baru ke dalam aplikasi secara manual.
Proxy mobile untuk alur kerja jaringan carrier
Proxy mobile menggunakan infrastruktur jaringan mobile.
Mereka masuk akal untuk alur kerja di mana routing LTE atau 5G sebenarnya merupakan bagian dari apa yang Anda uji.
Ini dapat mencakup QA mobile, pengalaman mobile regional, atau agen yang tugasnya secara khusus bergantung pada rute jaringan carrier.
Jangan memilih mobile secara otomatis karena terdengar lebih canggih. Jika tugas tidak memerlukan jaringan mobile, jenis proxy lain mungkin lebih sederhana.
Proxy datacenter untuk otomasi AI yang lebih sederhana
Banyak tugas otomasi tidak memerlukan karakteristik residential atau mobile sama sekali.
Sebuah proxy datacenter dapat menjadi pilihan yang mudah untuk pemeriksaan teknis, pengembangan, pemantauan, pekerjaan data terbuka, dan pekerjaan lain di mana IP infrastruktur normal sudah cukup.
Proxy yang tepat adalah jaringan yang paling tidak rumit yang memenuhi tugas.
Cara mengatur proxy AI dengan CyberYozh App
Setelah Anda mengetahui rute jaringan apa yang dibutuhkan agen AI Anda, pengaturan bermuara pada mengonfigurasi alat yang digunakannya untuk menjangkau web. Anda telah memilih jenis proxy yang sesuai; sekarang Anda perlu memutuskan bagaimana koneksi harus berperilaku dan menghubungkannya ke lapisan akses web agen.
Langkah 1. Pilih lokasi
Jika geografi penting untuk tugas, pilih negara, wilayah, atau opsi penargetan lain yang tersedia yang dibutuhkan agen.
Ini dapat penting untuk riset AI, pengambilan web lokal, QA regional, pemantauan, dan alur kerja lain di mana konten yang dikembalikan oleh situs web dapat bervariasi tergantung pada lokasi permintaan.
Jika geografi tidak penting, tidak ada alasan untuk menambahkan persyaratan lokasi hanya karena opsi tersebut ada.
Langkah 2. Tentukan bagaimana IP harus berperilaku
Selanjutnya, tentukan apakah agen harus mempertahankan IP-nya atau mengubahnya.
Perjalanan browser multi-langkah umumnya mendapat manfaat dari kontinuitas. Untuk set besar permintaan independen, rotasi mungkin lebih tepat. Sesi sticky berada di antara keduanya, mempertahankan IP exit yang sama untuk periode yang ditentukan.
Bagian penting adalah membuat perilaku IP mengikuti tugas agen daripada timer yang sewenang-wenang. panduan rotasi proxy kami menjelaskan pendekatan yang berbeda secara lebih rinci.
Langkah 3. Pilih protokol yang didukung klien Anda
Protokol harus didukung oleh browser, framework otomasi, scraper, atau klien HTTP yang membuat permintaan.
Pilih sesuai dengan apa yang sebenarnya dibutuhkan oleh klien dan alur kerja, bukan menganggap satu protokol secara universal lebih baik. Jika Anda memerlukan bantuan memilih di antara opsi umum.
Lihat perbandingan proxy SOCKS5 vs HTTPSkami.
Langkah 4. Dapatkan kredensial proxy Anda
Setelah konfigurasi jaringan siap, gunakan detail koneksi yang disediakan di dasbor CyberYozh App Anda. Koneksi proxy biasanya mencakup:
Host
Port
Username
Password
Protokol
Konfigurasi yang tepat dapat bervariasi tergantung pada produk proxy dan lokasi, sesi, atau pengaturan IP yang telah Anda pilih.
Simpan kredensial ini di lingkungan eksekusi daripada mengeksposnya ke model bahasa itu sendiri.
Langkah 5. Hubungkan proxy ke tool yang membuat permintaan
Konfigurasikan proxy di tempat agen benar-benar mengakses web.
Misalnya:
LLM → logika agen → Playwright → proxy CyberYozh App → website
Jika Playwright mengontrol browser, konfigurasikan proxy di Playwright. Prinsip yang sama berlaku untuk Puppeteer, Selenium, Scrapy, Postman, klien HTTP, atau lingkungan otomasi lainnya.
Panduan pengaturan Playwright CyberYozh App menunjukkan satu contoh koneksi praktis.
Aturan pengaturan: Ikuti permintaan. Komponen yang mengirimkannya ke web biasanya adalah tempat proxy berada.
Langkah 6. Verifikasi koneksi sebelum menjalankan agen
Jangan berasumsi proxy berfungsi hanya karena kredensial telah berhasil ditambahkan.
Gunakan pemeriksa IP CyberYozh App untuk mengonfirmasi IP keluar dan lokasi yang diharapkan. Untuk alur kerja statis atau sticky, periksa bahwa rute tetap konsisten seperti yang diharapkan. Jika rotasi adalah bagian dari pengaturan, verifikasi bahwa perilaku IP sesuai dengan konfigurasi Anda.
Baru setelah itu serahkan alur kerja kepada agen.
Langkah 7. Tambahkan kontrol API ketika alur kerja memerlukannya
Untuk alur kerja AI yang lebih besar, manajemen proxy pada akhirnya mungkin perlu menjadi bagian dari otomasi itu sendiri daripada sesuatu yang dikonfigurasi secara manual sebelum setiap eksekusi.
Jika didukung oleh produk proxy, kontrol berbasis API dapat diintegrasikan ke dalam pipeline otomasi yang lebih luas. Namun untuk agen yang lebih sederhana, tidak ada alasan untuk menambahkan lapisan logika lain jika koneksi proxy standar sudah menyelesaikan pekerjaan.
Siap menghubungkan alur kerja AI Anda? Pilih proxy CyberYozh App berdasarkan lokasi, perilaku sesi, protokol, dan persyaratan jaringan agen Anda.
Proxy AI untuk web scraping dan pengumpulan data
AI telah membuat alur kerja scraping lebih fleksibel, tetapi tidak menghilangkan masalah rekayasa normal seputar pengumpulan data.
Agen masih harus mengambil halaman sebelum LLM dapat mengklasifikasi, mengekstrak, merangkum, atau menalar tentang kontennya.
Langkah jaringan tersebut sangat penting.
proxy web scraping dapat membantu mendistribusikan permintaan data publik dan memisahkan infrastruktur scraping dari mesin yang menjalankan agen.
Namun proxy harus berada di dalam sistem yang lebih luas yang menangani:
Pacing permintaan
Retry
Validasi
Deteksi duplikat
Kegagalan parser
Manajemen sesi
Penanganan error
Kepatuhan terhadap aturan dan izin yang berlaku
Proxy tidak menggantikan komponen-komponen tersebut.
Untuk workflow yang lebih besar, CyberYozh App web scraping stack menyediakan lapisan jaringan bersama integrasi scraping dan automasi yang sudah ada.
Kesalahan umum AI proxy
Sebagian besar setup AI proxy yang buruk ternyata sangat biasa. Biasanya merupakan kesalahan arsitektur atau konfigurasi, bukan masalah AI yang misterius.
Merotasi setiap permintaan
Rotasi tidak otomatis lebih baik.
Jika agen membuat ribuan permintaan independen, rotasi mungkin sesuai dengan beban kerja. Jika memerlukan kontinuitas di seluruh perjalanan browser multi-langkah, mengubah IP di tengah jalan dapat membuat sesi lebih sulit dipertahankan.
Sesuaikan rotasi dengan struktur tugas, bukan mengaktifkannya secara default.
Menggunakan residential proxy untuk semuanya
Routing residential berguna ketika beban kerja benar-benar membutuhkannya.
Beberapa pekerjaan development, tugas monitoring, pemeriksaan teknis, dan workflow automasi bekerja dengan sempurna melalui infrastruktur datacenter. Demikian pula, mobile proxy hanya masuk akal ketika rute carrier-network relevan.
Fakta bahwa workflow menggunakan AI tidak secara otomatis berarti memerlukan tipe proxy paling kompleks yang tersedia.
Memberikan kredensial proxy ke model
Model biasanya tidak perlu melihat username proxy, password, atau kredensial API Anda.
Simpan rahasia di execution environment dan biarkan Playwright, Puppeteer, Selenium, Scrapy, atau Postman menggunakan koneksi proxy yang dikonfigurasi. Model dapat mengarahkan workflow tanpa memiliki akses ke kredensial di baliknya.
Mengonfigurasi proxy di tempat yang salah
Proxy perlu dikonfigurasi pada komponen yang benar-benar membuat permintaan web keluar.
Jika Playwright mengontrol browser, misalnya, menambahkan informasi proxy di suatu tempat dalam konfigurasi LLM tidak secara otomatis merutekan traffic Playwright melaluinya.
Ikuti permintaan melalui arsitektur dan konfigurasikan proxy di tempat permintaan tersebut meninggalkan sistem.
Lupa memverifikasi exit IP
Konfigurasi proxy yang ada di kode Anda belum tentu konfigurasi proxy yang berfungsi.
Periksa exit IP dan lokasi yang diharapkan sebelum tugas dimulai. Jika tidak, Anda mungkin akan berakhir men-debug prompt, logika agen, atau perilaku browser padahal masalahnya hanya koneksi yang salah dikonfigurasi.
Mencoba ulang tindakan yang gagal secara membabi buta
Permintaan jaringan yang gagal tidak seharusnya secara otomatis menyebabkan agen otonom mengulangi setiap tindakan.
Pertama, identifikasi apakah kegagalan tersebut berasal dari autentikasi, rute proxy, tujuan, sesi, atau alat. Referensi kesalahan proxy CyberYozh App dapat membantu membedakan kegagalan jaringan dan proxy yang umum terjadi.
Untuk sistem yang berjalan lama, lebih masuk akal untuk memikirkan keseluruhan siklus hidup proxy daripada mengganti IP secara acak setiap kali terjadi kegagalan.