Cara Mengatasi Error CAPTCHA pada SearXNG

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 core

Jalankan 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.

Bagaimana SearXNG mencoba ulang dan menangguhkan engine yang gagal

SearXNG tidak terus-menerus mencoba 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, dan keduanya berada di bawah search: dalam settings.yml. Pastikan nama kunci dan nilainya sesuai dengan searx/settings.yml untuk versi yang benar-benar Anda jalankan sebelum menempelkan konfigurasi apa pun. Nama dan nilai tersebut telah berpindah antar-rilis. Selain itu, contoh pada halaman dokumentasi pengaturan masih menunjukkan durasi penangguhan yang lebih lama daripada file yang benar-benar dimuat SearXNG. Pada searx/settings.yml yang dirilis pada 17 October 2026, nilai default-nya adalah:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 180
    SearxEngineCaptcha: 3600
    SearxEngineTooManyRequests: 180
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

Lapisan pertama menangani kegagalan biasa, seperti timeout. Pemblokiran dimulai setelah ban_time_on_fail detik dan bertambah pada setiap kegagalan berturut-turut, hingga max_ban_time_on_fail. Secara default, batasnya adalah dua menit. Jadi, engine yang tidak stabil akan pulih sendiri dalam beberapa menit setelah masalah berhenti.

Lapisan kedua menangani kegagalan yang dibahas dalam panduan ini. Saat SearXNG mengenali respons sebagai challenge atau penolakan, bukan sebagai error umum, SearXNG menerapkan entri yang sesuai dari suspended_times. Sebagian besar nilainya jauh lebih besar. 180 detik adalah tiga menit, untuk penolakan biasa atau 429. 3600 adalah satu jam, untuk CAPTCHA umum. 86400 adalah satu hari penuh. 604800 adalah satu minggu. 1296000 adalah lima belas hari. Kunci yang diawali cf_ berlaku saat challenge dikenali sebagai challenge Cloudflare. Kunci yang diawali recaptcha_ berlaku saat challenge dikenali sebagai reCAPTCHA.

Hal ini menjelaskan gejala yang paling banyak membuang waktu. Anda menemukan penyebabnya, memperbaikinya, tetapi engine tetap tidak mengembalikan apa pun selama satu jam atau selama beberapa hari setelah challenge Cloudflare. Engine tersebut masih ditangguhkan. 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. Restart biasa sudah cukup untuk kasus ini. Sebelum mulai membangun ulang image tanpa alasan, baca kapan restart sudah cukup dan kapan container perlu dibuat ulang. Jika engine kembali gagal segera setelah restart, perbaikan Anda tidak berhasil.

Satu pengaturan per engine perlu diperhatikan. retry_on_http_error mencoba ulang permintaan jika engine merespons dengan kode status yang Anda cantumkan. Jika engine sedang memblokir Anda, percobaan ulang akan mengirim lebih banyak trafik ke sistem yang sudah memutuskan bahwa server Anda adalah 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 17 October 2026, dokumentasi admin SearXNG menjawab masalah ini dengan tunnel manual. Anda membuka SOCKS proxy melalui server, mengarahkan browser desktop ke proxy tersebut, lalu menjawab challenge secara manual sementara engine melihat alamat server.

ssh -q -N -D 8080 user@example.org

-D 8080 membuka SOCKS server lokal pada port 8080 yang meneruskan koneksi melalui koneksi SSH. -N tidak menjalankan perintah remote dan -q membuatnya tetap senyap, sehingga tunnel yang berfungsi tidak mencetak apa pun dan tidak berhenti. Periksa tunnel dari terminal kedua:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

Perintah pertama seharusnya mencetak alamat server Anda, sedangkan perintah kedua mencetak alamat desktop Anda. Jika kedua hasilnya sama, berarti request tidak melewati tunnel. Selanjutnya, atur network settings browser untuk menggunakan SOCKS5 proxy pada 127.0.0.1 port 8080, buka address checker yang sama di browser untuk memastikan hasilnya menunjukkan server, 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 memiliki akses ke cookie browser tersebut. Karena itu, satu-satunya hal yang dapat membantu instance Anda adalah informasi yang dicatat engine berdasarkan alamat itu sendiri. Catatan tersebut kedaluwarsa sesuai jadwal yang ditentukan engine dan tidak dipublikasikan. Tidak ada bagian dari prosedur ini yang otomatis, sehingga lain kali Anda harus kembali ke depan keyboard. Selain itu, pada instance yang digunakan orang lain, query rate yang memicu challenge masih berjalan, sehingga challenge akan muncul kembali.

Gunakan metode ini untuk membuat satu instance berfungsi sore ini. Jangan membangun instance dengan mengandalkannya.

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.3

disabled: 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.

Perbaikan yang bertahan: kirim permintaan keluar melalui proxy

SearXNG dapat mengirim permintaan keluar ke engine melalui proxy. Dengan demikian, alamat yang dilihat oleh engine berubah. Atur proxy secara global di outgoing:, atau per engine jika hanya satu engine yang bermasalah.

outgoing:
  request_timeout: 3.0
  extra_proxy_timeout: 10
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

Pilih socks5h:// daripada socks5:// jika Anda ingin proxy menyelesaikan hostname, karena h berarti nama tersebut dikirim ke proxy, bukan dicari di server Anda. Naikkan batas waktu pada saat yang sama. request_timeout secara default bernilai 3.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 ditujukan untuk kondisi ini dan menambahkan detik saat proxy digunakan. Tulis nilainya sebagai bilangan bulat, seperti 10. Berbeda dengan request_timeout yang menerima nilai desimal, extra_proxy_timeout adalah bilangan bulat dalam skema pengaturan. Karena itu, nilai seperti 10.0 ditolak sebagai settings.yml yang tidak valid, meskipun contoh berkomentar pada halaman dokumentasi pengaturan outgoing menuliskannya dengan cara tersebut.

Konsekuensi penggunaan proxy:

• Operator proxy dapat melihat engine mana yang ditanyakan oleh instance Anda dan kapan permintaan tersebut dikirim. TLS (transport layer security) menyembunyikan istilah pencarian dari log mereka karena kueri berada di dalam permintaan terenkripsi, tetapi pola dan waktu trafik Anda tetap dapat mereka baca.
• Alamat keluar bersama digunakan bersama oleh pihak lain yang juga membayarnya. Jika mereka melakukan scraping, Anda mewarisi reputasi mereka, terkadang lebih cepat daripada blokir yang ingin Anda hindari.
• Pool proxy residential murah sering dibangun dari perangkat konsumen yang pemiliknya tidak pernah menyetujui penggunaan perangkat tersebut untuk membawa trafik. Pahami layanan yang Anda beli.
• using_tor_proxy: true merutekan trafik melalui Tor, tetapi alamat exit node dipublikasikan sepenuhnya. Engine yang biasanya menantang rentang alamat datacenter umumnya akan menantang exit node setidaknya sama ketatnya.
• Pencarian kini bergantung pada layanan di luar server Anda. Layanan tersebut dapat gagal sesuai jadwalnya sendiri dan menyebabkan hasil Anda ikut tidak tersedia.

Proxy memindahkan blokir, bukan menghapusnya. Selain itu, privasi instance Anda kini juga melibatkan pihak ketiga. Jika alasan Anda melakukan self-hosting adalah kebutuhan akan privasi yang sederhana, 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 lama: sengaja gunakan set engine yang lebih kecil

Pilihan yang sering dilewatkan adalah menerima jumlah engine yang lebih sedikit. Nilai SearXNG terletak pada penggabungan hasil, dan gabungan enam engine yang selalu merespons lebih baik daripada dua puluh engine yang setengahnya ditangguhkan selama berjam-jam atau 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 karena engine tersebut mengetahui identitas Anda dan menerapkan kuota, bukan menebak apakah Anda adalah manusia. Konsekuensinya adalah akun, key yang tersimpan dalam file settings Anda, dan biasanya biaya. Untuk satu atau dua engine yang penting bagi Anda, cara ini sering kali paling mudah.

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 dikueri oleh Open WebUI dan tool sejenis hanya mengembalikan lebih sedikit hasil, bukan error yang dapat diketahui oleh tool Anda. Jika ada proses otomatis yang bergantung pada instance Anda, lakukan polling ke /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 yang disertakan berkisar dari tiga menit hingga lima belas hari, bergantung pada jenis penolakan. Penangguhan disimpan dalam proses yang sedang berjalan. Karena itu, me-restart container akan menghapus penangguhan tersebut, dan pencarian berikutnya akan mencoba engine itu lagi. Jika engine kembali gagal segera setelah restart, berarti perbaikan Anda belum berhasil.

Apakah error CAPTCHA dari engine sama dengan 429 yang dikembalikan instance saya?

Keduanya berjalan ke arah yang berlawanan. Error 429 dari instance Anda ke browser terjadi karena limiter bawaan SearXNG menilai permintaan Anda terlihat seperti permintaan otomatis. Limiter tersebut dapat Anda konfigurasi. Error CAPTCHA atau block terjadi karena engine upstream menolak server Anda. Keputusan itu dibuat pada infrastruktur yang tidak Anda kendalikan. Jika halaman hasil dimuat tetapi hanya beberapa engine yang tidak muncul, berarti yang Anda hadapi adalah 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. Hal ini dapat menghapus pemblokiran yang terkait dengan rentang alamat datacenter Anda. Operator proxy kemudian dapat melihat engine mana yang Anda kueri dan kapan Anda mengkuerinya. Alamat exit bersama juga 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 exit dipublikasikan dan sering mendapat challenge.

Apakah saya dapat membuat SearXNG menyelesaikan CAPTCHA secara otomatis?

Tidak ada pengaturan untuk itu. Metode yang didokumentasikan project adalah manual: tunnel SSH SOCKS, browser milik Anda sendiri, dan interaksi manual Anda pada challenge tersebut. Apa pun yang Anda buat untuk menjawab challenge secara otomatis bertentangan dengan kebijakan yang ditetapkan engine. Cara itu juga akan gagal tanpa pemberitahuan setiap kali challenge berubah. Akibatnya, Anda harus memelihara scraper, bukan menjalankan instance pencarian. Menghapus engine yang memblokir alamat Anda adalah solusi yang tetap berfungsi.