Mengatasi CAPTCHA SearXNG dari Engine Pencarian
SearXNG di VPS lebih sering menerima halaman CAPTCHA daripada koneksi rumah. Kenali error 429 dan pilih perbaikan yang tetap berlaku setelah restart.
Makna error CAPTCHA SearXNG
Error CAPTCHA SearXNG berasal dari engine yang dikueri oleh instance Anda. Server Anda meminta hasil kepada suatu engine, tetapi engine tersebut mengirim halaman challenge, bukan hasil pencarian. SearXNG kemudian mencatat error pada engine itu karena tidak ada hasil yang dapat diurai dalam respons. Instance Anda berfungsi normal. Sistem yang tidak Anda kendalikan memutuskan bahwa permintaan Anda tidak tampak berasal dari manusia.
Fakta ini menentukan semua perbaikan di bawah. Keputusan tersebut dibuat pada perangkat keras milik engine, sehingga tidak ada konfigurasi dalam settings.yml Anda yang dapat membatalkannya. Hal yang dapat Anda ubah adalah alamat asal permintaan, engine yang digunakan, serta perilaku instance Anda ketika suatu engine mulai menolak permintaan.
Dua kegagalan yang tampak sama dan cara membedakannya
Kegagalan pertama terjadi ketika instance Anda sendiri mengirimkan respons HTTP 429 (terlalu banyak permintaan) ke browser Anda sendiri. Ini adalah limiter SearXNG, yaitu lapisan deteksi bot yang berada di depan endpoint pencarian. Limiter berjalan pada server Anda dan dapat Anda konfigurasi. limiter yang mengembalikan 429 kepada pengguna Anda sendiri adalah masalah terpisah dengan pengaturan yang berbeda, sehingga tidak satu pun saran di bawah ini berlaku untuk masalah tersebut.
Kegagalan kedua terjadi pada sisi upstream. Halaman hasil dimuat secara normal, tetapi satu atau beberapa engine tidak muncul dalam hasil atau menampilkan pemberitahuan error. Tidak ada komponen pada instance Anda yang menolak permintaan. Engine menolak server Anda.
- Halaman tidak dapat dimuat, atau endpoint pencarian mengembalikan 429: periksa limiter Anda.
- Halaman dimuat dan hasilnya sedikit, atau sebuah engine ditandai dengan error: periksa sisi upstream dan lanjutkan membaca.
Keduanya dapat terjadi pada instance yang sama dan saling memperburuk, karena limiter yang terlalu longgar memungkinkan masuknya trafik yang meningkatkan laju query keluar Anda. Diagnosis setiap masalah secara terpisah.
Mengapa engine SearXNG mengembalikan error CAPTCHA di VPS, tetapi tidak di laptop?
Penyebabnya adalah alamat asal permintaan. Koneksi rumah Anda menggunakan alamat dari rentang ISP konsumen (internet service provider) yang digunakan secara bergantian oleh banyak pengguna biasa. VPS Anda menggunakan alamat dari rentang datacenter. Rentang ini dipublikasikan, sehingga siapa pun dapat mengetahui alamat mana yang dimiliki penyedia hosting. Engine yang ingin mencegah scraper biasanya menganggap permintaan dari rentang hosting sebagai mencurigakan sejak awal, karena sangat sedikit alamat dalam rentang tersebut yang digunakan manusia dengan browser.
Beberapa faktor lain memperkuat pengaruh alamat tersebut. Instance Anda mengirim satu permintaan ke setiap engine untuk setiap pencarian pengguna. Jadi, sedikit pengguna pun dapat menghasilkan laju permintaan dari satu alamat yang tidak mungkin dihasilkan oleh satu orang. SearXNG tidak mempertahankan sesi dengan engine dan, sesuai desain, tidak mengirim cookie berumur panjang. Karena itu, setiap permintaan tiba tanpa riwayat sebelumnya. Alamat tersebut juga mungkin memiliki riwayat yang tidak Anda buat, karena penyedia mendaur ulang alamat dan tenant sebelumnya mungkin telah melakukan scraping dari alamat itu selama berbulan-bulan.
Penolakan tersebut tidak selalu terlihat sebagai kegagalan yang jelas. Engine dapat merespons dengan 403, 429, atau HTTP 200 yang berisi halaman challenge di dalam body. Kasus terakhir ini sering membingungkan, karena pemeriksaan kode status menunjukkan bahwa engine berfungsi, sementara SearXNG menemukan nol hasil dalam respons. Karena itu, baca laporan error dari instance Anda sendiri. Jangan hanya melakukan curl ke engine dan melihat baris statusnya.
Baca laporan instance Anda sebelum mengubah apa pun
Setiap perbaikan di bawah ini dimulai dengan nama engine yang mengalami kegagalan dan alasan yang dicatat instance Anda. SearXNG menyediakan keduanya. Halaman /stats mencantumkan engine beserta jumlah error dan keandalannya, sedangkan /stats/errors mengembalikan detail error dalam format JSON yang lebih mudah disimpan dan dibandingkan pada minggu berikutnya. Buka keduanya di browser yang biasa Anda gunakan untuk instance tersebut.
Log container memuat event yang sama saat terjadi. Nama service di sini adalah nama yang digunakan dalam file compose yang diterbitkan bersama dokumentasi container. Gunakan nama Anda sendiri jika berbeda.
docker compose logs -f coreJalankan pencarian yang gagal saat log sedang dipantau. Anda akan melihat entri untuk engine yang gagal muncul saat pencarian berlangsung. Catat nama engine dan string alasan persis yang ditampilkan oleh instance Anda. Jangan menyalin nama engine dari posting blog, termasuk posting ini. Daftar engine yang memblokir alamat datacenter berubah dari bulan ke bulan. Engine yang gagal pada instance Anda mungkin berfungsi normal bagi penulis posting yang sedang Anda baca.
Jika halaman hasil tidak menampilkan error sama sekali, tetapi hasilnya sedikit, periksa display_error_messages untuk engine tersebut. Nilai defaultnya adalah true. Instance yang menonaktifkan opsi ini menyembunyikan satu-satunya pesan yang Anda perlukan.
Cara SearXNG mengulangi permintaan dan menangguhkan engine yang gagal
SearXNG tidak terus-menerus mengirim permintaan ke engine yang menolaknya. Engine yang gagal akan ditangguhkan. Selama ditangguhkan, engine tersebut dilewati sepenuhnya. Akibatnya, engine yang rusak tampak seperti engine yang hilang tanpa pesan.
Dua lapisan mengendalikan perilaku ini. Keduanya berada di bawah search: dalam settings.yml. Pastikan nama-nama kunci ini sesuai dengan dokumentasi pengaturan untuk versi yang benar-benar Anda jalankan sebelum menempelkan konfigurasi apa pun, karena nama tersebut berubah antar-rilis. Berdasarkan dokumentasi pada 2 September 2026, nilai defaultnya adalah:
search:
ban_time_on_fail: 5
max_ban_time_on_fail: 120
suspended_times:
SearxEngineAccessDenied: 86400
SearxEngineCaptcha: 86400
SearxEngineTooManyRequests: 3600
cf_SearxEngineCaptcha: 1296000
cf_SearxEngineAccessDenied: 86400
recaptcha_SearxEngineCaptcha: 604800Lapisan pertama menangani kegagalan umum, seperti timeout. Pemblokiran dimulai setelah ban_time_on_fail detik dan bertambah pada setiap kegagalan berturut-turut, hingga mencapai max_ban_time_on_fail. Secara default, batasnya adalah dua menit. Jadi, engine yang tidak stabil akan pulih sendiri dalam beberapa menit setelah masalah teratasi.
Lapisan kedua menangani kegagalan yang dibahas dalam panduan ini. Jika SearXNG mengenali respons tersebut sebagai challenge atau penolakan, bukan error umum, SearXNG menerapkan entri yang sesuai dari suspended_times. Nilai-nilai tersebut jauh lebih besar. 86400 detik sama dengan satu hari penuh. 604800 detik sama dengan satu minggu. 1296000 detik sama dengan lima belas hari. Kunci dengan awalan cf_ berlaku ketika challenge dikenali sebagai challenge Cloudflare. Kunci dengan awalan recaptcha_ berlaku ketika challenge dikenali sebagai reCAPTCHA.
Hal ini menjelaskan gejala yang paling banyak membuang waktu. Anda menemukan penyebabnya dan memperbaikinya, tetapi engine tetap tidak mengembalikan hasil selama berjam-jam. Engine tersebut masih ditangguhkan. Status penangguhan disimpan dalam proses yang sedang berjalan. Jadi, me-restart container akan menghapus status tersebut, dan pencarian berikutnya akan mencoba engine itu lagi. Restart biasa sudah cukup dalam situasi ini. Anda juga perlu mengetahui kapan restart sudah cukup dan kapan container perlu dibuat ulang sebelum mulai membangun ulang image tanpa alasan. Jika engine kembali gagal segera setelah restart, perbaikan Anda belum berhasil.
Ada satu pengaturan per engine yang perlu diperhatikan. retry_on_http_error mengulangi permintaan ketika engine memberikan respons dengan kode status yang Anda cantumkan. Jika engine sedang memblokir Anda, pengulangan permintaan akan mengirim lebih banyak trafik ke sistem yang sudah menganggap server Anda sebagai bot. Biarkan pengaturan ini apa adanya, kecuali Anda sedang menangani engine yang memang tidak stabil.
Dokumentasi upstream SSH tunnel dan hal yang tidak diperbaikinya
Diperiksa pada 2 September 2026, dokumentasi admin SearXNG menjawab masalah ini dengan tunnel manual. Anda membuka proxy SOCKS melalui server, mengarahkan browser desktop ke proxy tersebut, lalu menjawab challenge secara manual saat engine melihat alamat server.
ssh -q -N -D 8080 user@example.org-D 8080 membuka server SOCKS lokal pada port 8080 yang meneruskan koneksi melalui koneksi SSH. -N tidak menjalankan perintah remote dan -q membuatnya tetap senyap. Karena itu, tunnel yang berfungsi tidak menampilkan apa pun dan tidak kembali ke prompt. Periksa tunnel tersebut dari terminal kedua:
curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plainPerintah pertama harus menampilkan alamat server Anda, sedangkan perintah kedua harus menampilkan alamat desktop Anda. Jika kedua hasilnya identik, berarti request tidak melalui tunnel. Selanjutnya, atur pengaturan jaringan browser agar menggunakan proxy SOCKS5 di 127.0.0.1 port 8080. Buka address checker yang sama di browser untuk memastikan bahwa alamat server yang dilaporkan, lalu kunjungi engine yang menampilkan challenge kepada Anda. Jawab challenge tersebut di sana.
Sekarang, bagian yang perlu diperhatikan. Ada empat hal yang membatasi metode ini. Cookie yang diberikan engine tersimpan di browser desktop Anda, sedangkan SearXNG tidak dapat mengakses cookie browser Anda. Jadi, satu-satunya hal yang dapat membantu instance Anda adalah informasi yang dicatat engine untuk alamat tersebut. Informasi itu akan kedaluwarsa sesuai jadwal yang ditentukan engine dan tidak dipublikasikan. Tidak ada bagian dari prosedur ini yang otomatis, sehingga Anda harus kembali ke keyboard saat masalah muncul lagi. Selain itu, pada instance yang digunakan orang lain, laju query yang memicu challenge masih berjalan, sehingga challenge akan muncul kembali.
Gunakan metode ini untuk membuat satu instance berfungsi sore ini. Jangan membangun instance dengan mengandalkan metode ini.
Perbaikan yang bertahan lama: hapus atau ubah bobot engine yang menghambat Anda
Solusi berkelanjutan yang paling sederhana adalah berhenti meminta hasil dari engine yang tidak dapat melayani server Anda. settings.yml Anda diawali dengan use_default_settings: true di dalam image container, sehingga entri di bawah engines: dengan name yang sesuai hanya menimpa kunci yang Anda cantumkan dan membiarkan definisi default lainnya tetap berlaku.
use_default_settings: true
engines:
- name: <engine name from your stats page>
disabled: true
- name: <another engine name>
weight: 0.3disabled: true menonaktifkan engine secara default, tetapi tetap menampilkannya pada halaman preferensi. Dengan demikian, pengguna yang memerlukannya dapat mengaktifkannya kembali untuk pencarian mereka sendiri. inactive: true menghapus engine tersebut sepenuhnya dari pengaturan pengguna. Gunakan opsi ini untuk engine yang tidak akan pernah berfungsi dari alamat Anda. weight memiliki fungsi berbeda: opsi ini menentukan seberapa besar hasil dari engine tersebut diperhitungkan saat SearXNG menggabungkan dan mengurutkan hasil. Bobot di bawah 1 mempertahankan engine yang kurang andal tanpa membiarkannya mendominasi halaman pertama.
Restart container setelah melakukan perubahan, jalankan beberapa pencarian, lalu periksa kembali /stats. Halaman statistik yang bersih dengan enam engine yang berfungsi lebih berguna daripada halaman penuh error dengan dua puluh engine.
Solusi yang bertahan: kirim permintaan keluar melalui proxy
SearXNG dapat mengirim permintaan keluar ke engine melalui proxy. Dengan demikian, alamat yang dilihat engine akan berubah. Tetapkan proxy secara global di outgoing:, atau per engine jika hanya satu engine yang bermasalah.
outgoing:
request_timeout: 2.0
extra_proxy_timeout: 10.0
proxies:
all://:
- socks5h://user:password@proxy:1080engines:
- name: <engine name>
proxies:
http: socks5h://user:password@proxy:1080
https: socks5h://user:password@proxy:1080Pilih socks5h:// daripada socks5:// jika Anda ingin proxy melakukan resolusi hostname, karena h berarti nama tersebut dikirim ke proxy, bukan dicari di server Anda. Naikkan batas waktu pada saat yang sama. Secara default, request_timeout adalah 2.0 detik. Proxy menambahkan satu perjalanan pulang-pergi pada setiap permintaan, sehingga engine yang sebelumnya merespons tepat waktu dapat mulai gagal karena timeout. extra_proxy_timeout memang disediakan untuk kondisi ini dan menambahkan detik saat proxy digunakan.
Biaya penggunaan proxy:
- Operator proxy dapat melihat engine mana yang dikueri oleh instance Anda dan kapan permintaan tersebut dilakukan. TLS (keamanan lapisan transport) mencegah istilah pencarian masuk ke log mereka karena kueri berada di dalam permintaan terenkripsi. Namun, pola dan waktu trafik Anda tetap dapat mereka baca.
- Alamat keluar bersama digunakan bersama oleh pihak lain yang membayar layanan tersebut. Jika mereka melakukan scraping, Anda ikut menanggung reputasi mereka. Pemblokiran itu dapat terjadi lebih cepat daripada pemblokiran yang ingin Anda hindari.
- Pool proxy residential murah sering dibangun dari perangkat konsumen yang pemiliknya tidak memberikan persetujuan secara sadar untuk meneruskan trafik. Pahami layanan yang Anda beli.
using_tor_proxy: truemeneruskan trafik melalui Tor, tetapi alamat exit node dipublikasikan sepenuhnya. Engine yang menantang rentang alamat datacenter biasanya memberikan tantangan setidaknya sama ketatnya kepada exit node.- Pencarian kini bergantung pada layanan di luar server Anda. Layanan tersebut dapat gagal sesuai jadwalnya sendiri dan membuat hasil Anda ikut tidak tersedia.
Proxy memindahkan pemblokiran, bukan menghilangkannya. Aspek privasi instance Anda kini juga mencakup pihak ketiga. Jika alasan utama Anda melakukan self-hosting adalah privasi, pertimbangkan hal tersebut terhadap apa yang sebenarnya disembunyikan oleh instance self-hosted dan apa yang tidak disembunyikannya sebelum mendaftar ke layanan apa pun.
Perbaikan yang bertahan: sengaja gunakan set engine yang lebih kecil
Pilihan yang paling sering diabaikan adalah menerima jumlah engine yang lebih sedikit. Nilai SearXNG terletak pada penggabungan hasil. Penggabungan enam engine yang selalu merespons lebih baik daripada dua puluh engine yang separuhnya ditangguhkan selama berhari-hari. Pantau /stats selama seminggu dan pertahankan engine yang memiliki riwayat baik dari alamat Anda.
Engine yang memerlukan autentikasi dengan API key berperilaku berbeda. Engine tersebut mengetahui identitas Anda dan menerapkan kuota, bukan memperkirakan apakah Anda pengguna manusia. Konsekuensinya adalah Anda memerlukan akun dan harus menyimpan key dalam file pengaturan. Biasanya Anda juga harus membayar. Untuk satu atau dua engine yang penting bagi Anda, cara ini sering kali paling praktis.
Pertimbangkan hal ini bersama tool lain yang Anda gunakan. Engine yang ditangguhkan tidak terlihat oleh apa pun yang membaca hasil melalui API, karena API JSON yang digunakan Open WebUI dan tool serupa hanya mengembalikan lebih sedikit hasil, bukan error yang dapat dideteksi oleh tool Anda. Jika ada proses otomatis yang bergantung pada instance Anda, lakukan polling terhadap /stats/errors secara berkala, bukan menunggu seseorang mengeluhkan bahwa kualitas jawabannya menurun.
Apakah masalah ini layak diperjuangkan?
Jawabannya bergantung pada jumlah pengguna. Instance untuk satu orang hanya mengirim beberapa pencarian per hari dari satu alamat, dengan laju yang tidak pernah dipermasalahkan oleh banyak mesin pencari. Jika salah satu mesin memberikan challenge, solusinya mudah: hapus mesin tersebut dan Anda hampir tidak akan menyadari kehilangannya. Itulah pengalaman umum menjalankan SearXNG untuk diri sendiri pada VPS kecil, dan Anda tidak memerlukan tunnel atau proxy.
Instance publik atau bersama adalah server berbeda yang menjalankan perangkat lunak yang sama. Laju kueri menjadi pemicunya dan meningkat setiap kali Anda menambahkan pengguna, sehingga challenge datang lebih cepat daripada yang dapat ditangani oleh konfigurasi apa pun. Rencanakan penggunaan set mesin pencari yang lebih kecil sejak awal. Ingat bahwa proxy apa pun yang Anda tambahkan sekarang akan membawa pencarian pengguna lain melalui akun Anda.
Klien otomatis berada di antara keduanya, tetapi cenderung mengarah ke kasus yang lebih sulit. Agen yang menjalankan beberapa pencarian untuk menjawab satu pertanyaan menghasilkan lonjakan yang tidak dihasilkan manusia. Karena itu, instance yang Anda arahkan untuk digunakan oleh coding agent dan alat riset akan menerima challenge lebih cepat daripada instance yang digunakan secara manual. Jika itu adalah kebutuhan Anda, pilih set mesin berdasarkan keandalan, bukan cakupan. Biarkan agen bekerja dengan hasil yang benar-benar dapat diperolehnya.
Aturan yang berlaku: pertahankan mesin jika mesin tersebut menjadi alasan Anda melakukan self-hosting, dan hapus jika tidak.
FAQ
Mengapa engine SearXNG tetap tidak mengembalikan hasil setelah masalahnya diperbaiki?
Karena engine tersebut masih ditangguhkan. Saat SearXNG mengenali challenge atau penolakan dari suatu engine, SearXNG berhenti mengkueri engine tersebut selama periode yang ditetapkan dalam search.suspended_times. Nilai default periode ini berkisar antara satu jam hingga lima belas hari, bergantung pada jenis penolakannya. Status penangguhan disimpan dalam proses yang sedang berjalan. Karena itu, me-restart container akan menghapus status tersebut, dan pencarian berikutnya akan mencoba engine itu lagi. Jika engine kembali gagal segera setelah restart, perbaikan Anda tidak berhasil.
Apakah error CAPTCHA dari engine sama dengan 429 yang dikembalikan instance saya?
Keduanya berjalan dalam arah yang berlawanan. Kode 429 dari instance Anda ke browser adalah limiter milik SearXNG yang memutuskan bahwa permintaan Anda terlihat seperti permintaan otomatis. Limiter tersebut dapat Anda konfigurasi. CAPTCHA atau error pemblokiran adalah penolakan dari engine upstream terhadap server Anda. Keputusan itu dibuat pada infrastruktur yang tidak dapat Anda kendalikan. Jika halaman hasil dimuat dan hanya beberapa engine yang tidak muncul, berarti Anda menghadapi kasus kedua.
Apakah VPN atau proxy pada server saya dapat mengatasi CAPTCHA engine?
Terkadang bisa, tetapi ada biayanya. Merutekan permintaan keluar melalui outgoing.proxies mengubah alamat yang dilihat engine. Cara ini dapat menghapus blokir yang terkait dengan rentang alamat pusat data Anda. Operator proxy kemudian dapat melihat engine mana yang Anda kueri dan kapan Anda melakukannya. Selain itu, alamat keluar bersama membawa reputasi pelanggan lain, dan latensi tambahan dapat menyebabkan timeout kecuali Anda menaikkan request_timeout dan extra_proxy_timeout. Tor tersedia melalui using_tor_proxy, tetapi alamat keluarnya dipublikasikan dan sering mendapat challenge.
Apakah saya dapat membuat SearXNG menyelesaikan CAPTCHA secara otomatis?
Tidak ada pengaturan untuk itu. Metode yang didokumentasikan oleh proyek ini bersifat manual: tunnel SSH SOCKS, browser Anda sendiri, dan Anda sendiri yang menyelesaikan challenge. Apa pun yang Anda buat untuk menjawab challenge secara otomatis bertentangan dengan kebijakan yang dinyatakan oleh engine. Cara tersebut juga akan berhenti berfungsi setiap kali challenge berubah. Akibatnya, Anda harus memelihara scraper, bukan menjalankan instance pencarian. Menghapus engine yang memblokir alamat Anda adalah solusi yang tetap berfungsi.