Apakah SearXNG Aman? Siapa yang Melihat Kueri Anda

Apakah SearXNG aman? Jawaban singkatnya

SearXNG aman dalam satu hal dan tidak aman dalam hal lain. Karena itu, pertanyaan "apakah SearXNG aman" baru dapat dijawab setelah Anda menjelaskan dari siapa Anda ingin menyembunyikan aktivitas. SearXNG adalah mesin metasearch: SearXNG menerima kueri Anda, mengirimkannya ke Google, Bing, DuckDuckGo, dan mesin lain yang Anda aktifkan, lalu menggabungkan hasilnya menjadi satu halaman hasil. Mesin-mesin tersebut melihat instance. Instance melihat Anda.

Pada instance publik yang dijalankan oleh orang lain, orang tersebut menerima setiap kueri yang Anda ketik dalam bentuk teks biasa. Tidak ada informasi pada halaman about mereka yang dapat membuktikan apa yang mereka lakukan terhadap data tersebut. Pada server milik Anda sendiri, mesin upstream melihat alamat server Anda, bukan alamat rumah Anda. Pertukaran itulah inti privasinya, dan nilainya sepenuhnya bergantung pada server tempat SearXNG berjalan.

Tidak ada bagian dari konfigurasi ini yang menyembunyikan aktivitas pencarian Anda dari jaringan Anda sendiri. Penyedia layanan Internet (ISP) Anda tetap melihat koneksi ke instance tersebut. Resolver DNS (domain name system) Anda tetap melihat hostname-nya. Ingat batasan ini saat membaca bagian selanjutnya.

Perubahan yang dibuat SearXNG pada permintaan pencarian

Jika Anda mencari langsung di Google, Google menerima alamat IP, cookie, header User-Agent, dan halaman asal Anda. Semua informasi tersebut dikaitkan dengan profil yang tetap tersimpan setelah sesi berakhir. SearXNG berada di antara Anda dan mesin pencari. Dokumentasinya menjelaskan dua hal yang dilakukan SearXNG: "menghapus data pribadi dari permintaan yang dikirim ke layanan pencarian" dan "membuat profil browser acak untuk setiap permintaan". Cookie Anda tidak pernah diteruskan ke mesin pencari. Preferensi Anda disimpan di browser sendiri, bukan di akun pada server.

Dua header respons aktif secara default, dan keduanya menjalankan fungsi penting:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer berarti bahwa ketika Anda mengeklik hasil pencarian, situs tujuan tidak pernah mengetahui halaman pencarian yang mengarahkan Anda ke sana karena browser tidak menyertakan header Referer. X-Robots-Tag: noindex, nofollow mencegah instance Anda dan halaman hasilnya masuk ke indeks mesin pencari.

SearXNG tidak mengubah kueri itu sendiri. Kueri tiba di instance dalam bentuk lengkap dan dapat dibaca karena TLS (transport layer security) dihentikan di sana. Semua poin di bawah ini berasal dari fakta tersebut.

Pada instance publik, operator dapat melihat setiap kueri

Dokumentasi proyek menyatakannya dengan jelas: pengguna instance publik "harus mempercayai administrator instance tersebut", dan mereka tidak dapat mengetahui "apakah permintaan mereka dicatat, diagregasi, lalu dikirim atau dijual kepada pihak ketiga". Klaim tanpa log pada halaman landing adalah sebuah klaim. Dari luar, tidak ada cara untuk mengujinya, sehingga pilihannya hanya percaya atau tidak sama sekali. Beberapa instance publik juga masih menjalankan Searx asli, bukan fork ini. Hal itu penting karena Searx tidak menerima commit kode sejak 2023 dan software pencarian yang tidak dipelihara adalah satu hal lagi yang harus Anda percayai tanpa dapat memverifikasinya.

Logging juga merupakan pilihan dengan upaya paling rendah karena default yang disertakan menempatkan kueri Anda di URL:

server:
  method: "GET"

Dengan GET, kueri dikirim sebagai ?q=... dalam request line. nginx secara default menulis request line tersebut ke access log, sehingga kueri tercatat tanpa ada yang perlu memutuskan untuk mencatatnya. Caddy tidak menyimpan access log sampai operator menambahkan directive log. Setelah directive tersebut diaktifkan, URI yang dicatat memuat query string, kecuali operator memfilternya:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

Pada instance Anda sendiri, periksa hasilnya:

sudo tail -n 5 /var/log/nginx/access.log

Pencarian yang dikirim dengan GET tercatat di sana karena format log combined milik nginx menulis $request, yaitu request line lengkap yang mencakup query string. SearXNG tidak dapat mengendalikannya. Mengubah instance ke method: "POST" memindahkan kueri ke request body, sehingga kueri tidak lagi muncul dalam access log atau riwayat browser. Dokumentasi menjelaskan bahwa POST memiliki kekurangan yang "sangat membatasi kemudahan penggunaan bagi pengguna akhir", terutama terkait tombol kembali pada browser. Ini adalah trade-off yang Anda pilih secara sadar.

Dua konsekuensi berlaku pada setiap instance publik. Operator dapat membaca kueri Anda, baik mereka bermaksud mengumpulkannya maupun tidak. Backup atau pembobolan dapat mengakses log yang sama.

Di VPS Anda sendiri, mesin pencari melihat server Anda, bukan Anda

Jalankan instance Anda sendiri pada VPS (virtual private server). Perubahannya mudah dijelaskan. Google tidak lagi menerima alamat IP rumah Anda bersama kueri Anda. Google menerima alamat IP server Anda bersama kueri tersebut. Google tidak dapat mengaitkan pencarian itu dengan akun Anda yang sedang login, ponsel Anda, atau profil iklan yang terkait dengan koneksi rumah Anda. Proses pembuatannya dibahas dalam panduan menjalankan instance SearXNG sendiri pada VPS.

Pahami hal-hal yang tidak berubah. Mesin pencari tetap melihat teks kueri, waktu pengiriman, bahasa dan wilayah yang Anda minta, serta pola seluruh pencarian Anda selama berbulan-bulan, yang semuanya dikelompokkan berdasarkan satu alamat yang stabil. Jika Anda adalah satu-satunya pengguna, alamat tersebut menjadi aliran data per orang tanpa nama yang melekat padanya. Untuk memutus pengelompokan tersebut, instance harus mengakses mesin pencari melalui proxy keluar atau Tor. SearXNG mendukung kedua metode ini, tetapi penerapannya merupakan pekerjaan terpisah.

Hal yang masih dapat dilihat ISP, resolver, dan host Anda

Empat pengamat tidak terpengaruh oleh semua ini.

• ISP Anda melihat koneksi TLS ke alamat IP instance Anda dan melihat hostname pada kolom SNI (server name indication), yang dikirim dalam bentuk plaintext selama handshake. ISP tidak melihat query tersebut.
• Resolver DNS Anda melihat pencarian untuk hostname tersebut. Pantau pencarian itu pada client dengan sudo tcpdump -ni any port 53 saat Anda memuat halaman, dan permintaan record A untuk instance Anda akan muncul. Jika browser menggunakan DNS over HTTPS, pencarian tersebut dienkripsi dan dikirim ke resolver DoH itu. Dengan demikian, tidak ada yang muncul pada port 53, dan resolver DoH tersebutlah yang melihat hostname.
• Provider VPS Anda menjalankan perangkat kerasnya, sehingga dapat membaca disk dan memori mesin virtual. Enkripsi disk di dalam VM sewaan tidak menghilangkan risiko ini karena sistem yang sedang berjalan menyimpan key tersebut.
• Siapa pun yang memiliki akses root pada instance dapat melihat semuanya. Itu termasuk Anda dan siapa pun yang berhasil masuk nanti.

Mengakses instance sebagai layanan onion Tor menutup dua hal pertama karena tidak ada hostname publik yang perlu di-resolve dan tidak ada kolom SNI yang dapat dibaca. Panduan menambahkan layanan onion v3 ke VPS membahas penyiapannya serta kebocoran yang jika tidak ditangani dapat mengaitkan alamat tersebut kembali ke IP publik server Anda.

Ada satu hal lagi yang sering dilupakan. Request outbound server Anda terlihat dari jaringan server itu sendiri. Dengan demikian, provider dapat melihat bahwa mesin Anda terus berkomunikasi dengan Google dan Bing sepanjang hari. Ini merupakan pola trafik, bukan query, tetapi tetap mengungkapkan sesuatu.

Di sinilah pertanyaan tentang VPN muncul. VPN (virtual private network) memindahkan informasi yang dapat dilihat ISP Anda menjadi informasi yang dapat dilihat perusahaan VPN. VPN tidak mengubah apa pun terkait operator instance dan tidak mengubah apa pun terkait engine pencarian karena engine tersebut berkomunikasi dengan server Anda, bukan dengan Anda. Keduanya dibandingkan secara tepat dalam perbandingan VPS dan VPN.

Mengapa SearXNG memblokir Anda, dan arti sebenarnya dari 429

Dua kejadian berbeda sering sama-sama disebut sebagai "SearXNG memblokir saya", padahal penanganannya berbeda.

Yang pertama adalah limiter Anda sendiri yang merespons dengan HTTP 429. Ini adalah perlindungan bot SearXNG, dan secara default dinonaktifkan:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

Per Oktober 2026, limiter memerlukan database Valkey dan membaca aturannya dari /etc/searxng/limiter.toml. Tetapkan server.public_instance: true juga jika orang lain benar-benar menggunakan server tersebut, karena secara default nilainya adalah false dan pengaturan ini mengaktifkan perilaku yang ditujukan untuk penggunaan publik. Pengaturan ini juga otomatis mengaktifkan limiter dan memaksa link_token aktif, apa pun isi limiter.toml.

Limiter menjalankan beberapa pemeriksaan. http_user_agent menganggap User-Agent yang tidak ditetapkan, atau yang cocok dengan tool yang dikenal seperti curl dan wget, sebagai bot. http_accept menganggap request sebagai bot jika header Accept tidak berisi text/html. link_token menandai client sebagai mencurigakan jika client tersebut tidak pernah mengambil URL /client<token>.css yang dimuat oleh browser sungguhan. Jika sebuah pemeriksaan terpenuhi, SearXNG mengembalikan 429 dan mencatat pemblokiran pada level DEBUG. Jadi, pada level log default, kecocokan pemeriksaan biasa tidak menghasilkan log apa pun. Baris ERROR hanya digunakan untuk kecocokan block_ip dan database Valkey yang tidak tersedia.

Jadi, ini gagal, dan memang seharusnya gagal:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

curl mengirim User-Agent: curl/8.5.0 dan Accept: */*. Wildcard */* dianggap menerima text/html, sehingga pemeriksaan Accept berhasil dan pemeriksaan User-Agent yang terpenuhi. Namun, curl tetap terdeteksi lebih dari satu kali berdasarkan header yang tidak dikirimnya: http_accept_encoding menolak pencarian tanpa gzip atau deflate di dalam Accept-Encoding, sedangkan http_accept_language menolak pencarian tanpa Accept-Language. Itulah sebabnya script dan agen AI mendapatkan 429 dari instance yang berfungsi normal di browser. Hal ini perlu diperbaiki sebelum mengarahkan skill pencarian agen ke instance Anda sendiri. Daftar lengkap penyebab dan pengaturannya tersedia dalam panduan tentang rate limit SearXNG dan error 429.

Ada satu jebakan limiter yang perlu disebutkan. Di belakang reverse proxy, SearXNG melihat alamat proxy, bukan alamat pengunjung, kecuali proxy tersebut dipercaya:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

Daftar default mencakup proxy pada host yang sama. Proxy di jaringan Docker terpisah akan datang dari alamat seperti 172.18.0.5, yang tidak ada dalam daftar. Akibatnya, semua pengunjung dihitung sebagai satu client, dan pengguna pertama yang sibuk dapat mengunci akses untuk semua pengguna lainnya. Tambahkan subnet tersebut ke trusted_proxies.

Jenis pemblokiran kedua terjadi di sisi upstream. Sebuah engine menganggap alamat datacenter yang menjalankan banyak pencarian sebagai scraper, lalu berhenti merespons server Anda. Untuk kasus ini, Anda tidak mendapatkan 429. Anda mendapatkan halaman hasil yang tidak memuat hasil dari engine tersebut, disertai catatan kegagalan pada engine itu. Setelah kegagalan berulang, SearXNG akan menangguhkan engine tersebut untuk sementara. Penyebabnya adalah alamat tempat VPS Anda berada. Karena itu, solusinya adalah memilih engine lain dan menunggu, bukan mengubah limiter.

Apakah berbagi sebuah instance dengan orang yang tidak dikenal membantu atau justru merugikan?

Keduanya, dalam arah yang berlawanan. Karena itu, jawabannya terasa tidak pasti. Anonimitas merupakan efek kerumunan. Pada instance publik yang sibuk, query Anda berasal dari alamat yang sama dengan query milik ribuan orang lain. Dengan demikian, tidak ada engine yang dapat memisahkan query Anda dari kumpulan tersebut. Pada instance untuk satu pengguna, setiap query dari alamat itu adalah milik Anda. Engine menerima aliran query yang bersih dari satu orang, tanpa nama yang terlampir.

Dari sisi operator, situasinya berbalik. Kerumunan besar berarti seorang asing menyimpan query teks biasa milik seluruh kerumunan, termasuk milik Anda. Dengan server Anda sendiri, Anda menyimpan query Anda dan tidak menyimpan query milik orang lain.

Jadi, tentukan pilihan berdasarkan ancaman yang benar-benar Anda hadapi. Khawatir terhadap pembuatan profil iklan dan pelacakan lintas situs? Kerumunan menangani hal itu dengan baik, dan risiko dari operator relatif kecil. Khawatir bahwa orang atau perusahaan tertentu dapat membaca satu pencarian tertentu yang Anda lakukan? Kerumunan sama sekali tidak membantu, karena operator melihat teks mentahnya. Pilihan tengah yang baik adalah menggunakan instance untuk beberapa orang yang Anda kenal. Anda mendapatkan kerumunan kecil dan operator yang dapat diverifikasi, karena operatornya adalah Anda.

Apakah hasil SearXNG lebih baik daripada Google?

Tidak. SearXNG tidak memiliki indeks sendiri, sehingga setiap hasil pada halaman berasal dari mesin upstream, dan batas kualitasnya ditentukan oleh kualitas mesin yang Anda aktifkan. Jika Google dan Bing dinonaktifkan, kualitas turun pada hari yang sama karena sebagian besar cakupan web umum berasal dari kedua mesin tersebut.

Yang berubah adalah pemrosesan yang diterapkan terhadap Anda. Tidak ada pihak yang membuat profil iklan berdasarkan kueri, dan tidak ada pihak yang mengurutkan ulang hasil berdasarkan hal yang Anda klik minggu lalu. Hal ini memiliki dua sisi, karena personalisasi juga membawa konteks lokal. Pencarian seperti "pharmacy open now" menghasilkan hasil yang lebih lemah melalui SearXNG karena mesin tersebut tidak memiliki sinyal lokasi untuk server Anda selain pusat data tempat server itu berada. Atur wilayah di preferensi jika hasil lokal diperlukan.

Dua pengaturan menentukan seberapa banyak instance Anda membocorkan informasi saat Anda membaca hasil tersebut. image_proxy secara default adalah false, sehingga thumbnail dimuat langsung dari situs yang menyediakannya dan situs tersebut dapat melihat alamat browser Anda. Dengan menetapkan image_proxy: true, thumbnail dialihkan melalui instance, dengan konsekuensi penggunaan bandwidth dan memori yang lebih tinggi. Selain itu, formats hanya tersedia sebagai html, sehingga permintaan JSON (JavaScript object notation) ditolak dengan 403 Forbidden:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

Aktifkan json pada instance publik, dan Anda telah menyediakan API scraping gratis. Ini adalah cara tercepat agar alamat server Anda diblokir oleh mesin yang menjadi dependensi Anda. Biarkan fitur tersebut nonaktif, atau lindungi dengan autentikasi.

Batas perlindungan privasi SearXNG

SearXNG menyembunyikan identitas pihak yang melakukan permintaan dari mesin pencari. SearXNG tidak menyembunyikan aktivitas Anda dari jaringan. Dari sini, ada empat batasan.

• Trafik Anda tidak berubah di bagian mana pun selain kotak pencarian. Semua aktivitas lain yang dilakukan mesin tetap keluar dari jaringan Anda seperti sebelumnya.
• Satu pengguna pada satu server merupakan pengenal yang stabil bagi setiap mesin pencari. Pengenal tersebut tidak memuat nama, dan hanya itu manfaatnya.
• Operator instance mana pun dapat membaca kueri dalam teks biasa. Menjadi operator instance itu sendiri adalah satu-satunya cara untuk memverifikasi hal ini.
• Log akses Anda sendiri dapat membangun kembali catatan yang ingin Anda hindari. Baca log tersebut, lalu beralih ke method: "POST" jika Anda ingin log tetap kosong.

SearXNG memindahkan pihak yang melakukan pemantauan. SearXNG tidak menghapus pemantauan. Tentukan pihak mana yang paling mengkhawatirkan Anda, pilih instance yang sesuai, dan jangan menganggap antarmuka pencarian sebagai software anonimitas.

FAQ

Apakah SearXNG aman digunakan pada instance publik?

SearXNG aman dari mesin pencari, tetapi tidak aman dari operator instance. Kueri Anda mencapai server tersebut sebagai teks biasa. Dokumentasi proyek menyatakan bahwa pengguna "harus mempercayai administrator instance tersebut" dan tidak dapat mengetahui "apakah permintaan mereka dicatat, dikumpulkan, lalu dikirim atau dijual kepada pihak ketiga". Dengan konfigurasi default method: "GET" yang disertakan, kueri juga menjadi bagian dari baris permintaan. Karena itu, kueri masuk ke access log reverse proxy jika proxy tersebut menyimpannya, seperti yang dilakukan nginx secara default, terlepas dari apakah operator menginginkannya. Gunakan instance publik untuk pencarian biasa jika kekhawatiran Anda adalah pembuatan profil iklan. Jangan masukkan informasi yang tidak bersedia Anda serahkan kepada pemilik instance tersebut.

Apakah SearXNG menyembunyikan pencarian saya dari penyedia layanan Internet?

Teks kueri disembunyikan. Aktivitasnya tidak. Penyedia layanan Anda dapat melihat koneksi TLS ke alamat instance serta hostname pada field SNI cleartext dalam handshake. Resolver DNS Anda juga dapat melihat pencarian hostname tersebut. Keduanya tidak dapat melihat kueri yang Anda gunakan karena koneksi dienkripsi. SearXNG bukan VPN dan tidak melindungi aktivitas lain pada mesin Anda.

Mengapa SearXNG mengembalikan error 429?

Error 429 berasal dari limiter milik instance itu sendiri. Ini adalah perlindungan terhadap bot, bukan pesan dari Google. Probe-nya menandai permintaan yang header Accept-nya tidak memiliki text/html, serta User-Agent yang tidak disetel atau cocok dengan tool seperti curl dan wget. Permintaan pencarian juga ditandai jika tidak memiliki header Accept-Language, atau memiliki header Accept-Encoding tanpa gzip atau deflate. Probe tambahan, yaitu token tautan, menandai client yang tidak pernah mengambil URL /client<token>.css yang dimuat browser. Jika reverse proxy tidak tercantum dalam trusted_proxies pada /etc/searxng/limiter.toml, setiap pengunjung dihitung sebagai satu client. Akibatnya, satu pengguna yang aktif dapat memblokir pengguna lainnya. Jika yang memblokir server Anda adalah mesin upstream, hasil dari mesin tersebut hanya tidak muncul pada halaman dan Anda tidak akan menerima error 429.

Apakah self-hosting SearXNG memperburuk hasil pencarian saya?

Terkadang, karena dua alasan yang perlu diketahui. Hasil pencarian berasal dari mesin upstream. Jika mesin tersebut membatasi alamat datacenter, lebih sedikit mesin yang memberikan jawaban sehingga halaman hasil menjadi lebih sedikit. Selain itu, pemeringkatan yang dipersonalisasi tidak digunakan. Akibatnya, pengurutan berbasis iklan dan konteks lokal sama-sama hilang. Pencarian yang sensitif terhadap lokasi akan memberikan jawaban yang kurang relevan sampai Anda menetapkan wilayah pada preferensi.