SearXNG CAPTCHA Hataları Nasıl Düzeltilir?

SearXNG CAPTCHA hatası ne anlama gelir

SearXNG CAPTCHA hataları, sunucunuzun sorguladığı arama motorlarından kaynaklanır. Sunucunuz bir arama motorundan sonuç talep etmiş, ancak arama motoru sonuç yerine bir doğrulama sayfası döndürmüştür. Yanıtta ayrıştırılabilecek bir veri bulunmadığı için SearXNG bu arama motoru için bir hata kaydı oluşturmuştur. Sunucunuzun durumu sağlıklıdır. Kontrolünüz dışındaki bir sistem, isteğinizin bir insan tarafından yapılmadığına karar vermiştir.

Aşağıdaki tüm çözüm yöntemleri bu gerçek üzerine kuruludur. Karar, arama motorunun kendi altyapısında verildiği için settings.yml içerisindeki hiçbir ayar bu kararı geçersiz kılamaz. Değiştirebileceğiniz unsurlar; isteğin hangi adresten çıkış yapacağı, hangi arama motorlarının sorgulanacağı ve bir arama motoru reddetmeye başladığında sunucunuzun nasıl davranacağıdır.

Birbirine benzeyen iki hata ve bunları ayırt etme yöntemleri

İlk hata, kendi tarayıcınıza kendi örneğinizin HTTP 429 (çok fazla istek) yanıtı vermesidir. Bu, arama uç noktasının önünde yer alan bot algılama katmanı olan SearXNG sınırlayıcısıdır. Kendi sunucunuzda çalışır ve yapılandırması size aittir. kendi kullanıcılarınıza 429 döndüren sınırlayıcı, farklı ayarlara sahip ayrı bir sorundur ve aşağıdaki tavsiyelerin hiçbiri bunun için geçerli değildir.

İkinci hata ise yukarı akış (upstream) kaynaklıdır. Sonuç sayfası normal şekilde yüklenir ancak bir veya daha fazla arama motoru sonuçlarda görünmez ya da bir hata bildirimi içerir. Sizin örneğinizde hiçbir şey reddedilmemiştir; bir arama motoru sunucunuzu reddetmiştir.

• Sayfa yüklenmiyor veya arama uç noktası 429 yanıtı veriyorsa: sınırlayıcınızı kontrol edin.
• Sayfa yükleniyor ancak sonuçlar eksikse veya bir arama motoru hata ile işaretlenmişse: yukarı akışı kontrol edin ve okumaya devam edin.

Her iki durum da aynı örnekte meydana gelebilir ve birbirlerini tetiklerler; çünkü çok gevşek ayarlanmış bir sınırlayıcı, giden sorgu hızınızı artıran trafiğin geçmesine izin verir. Bunları tek tek teşhis edin.

SearXNG motorları neden dizüstü bilgisayarımda değil de VPS üzerinde CAPTCHA hataları veriyor?

Bunun nedeni, isteğin geldiği adrestir. Ev bağlantınız, zaman içinde birçok sıradan kullanıcıyla paylaşılan bir tüketici İSS (internet servis sağlayıcısı) aralığından bir adrese sahiptir. VPS'niz ise bir veri merkezi aralığından bir adrese sahiptir ve bu aralıklar herkese açıktır: herkes hangi adreslerin bir barındırma sağlayıcısına ait olduğunu sorgulayabilir. Kazıyıcıları (scraper) uzak tutmak isteyen bir motor, barındırma aralıklarından gelen istekleri şüpheli olarak değerlendirerek işe başlar; çünkü bu aralıklarda tarayıcı kullanan gerçek bir insan olma olasılığı çok düşüktür.

Adresin üzerine eklenen birkaç faktör daha vardır. Örneğiniz, her kullanıcı araması için motor başına bir istek gönderir; bu nedenle az sayıda kullanıcı bile, tek bir kişinin asla oluşturamayacağı bir istek yoğunluğu yaratır. SearXNG, tasarımı gereği motorla herhangi bir oturum tutmaz ve uzun ömürlü çerez taşımaz; bu yüzden her istek, arkasında hiçbir geçmiş olmadan ulaşır. Ayrıca adres, sizin oluşturmadığınız bir geçmişe sahip olabilir; çünkü sağlayıcılar adresleri geri dönüştürür ve önceki kiracı aylarca o adresten veri kazımış olabilir.

Reddetme işleminin kendisi her zaman bariz bir hata değildir. Bir motor 403, 429 veya HTTP 200 koduyla birlikte gövdede bir doğrulama sayfasıyla yanıt verebilir. Son durum insanların kafasını karıştırır; çünkü durum kodu kontrolü motorun düzgün çalıştığını söylerken, SearXNG yanıt içinde sıfır sonuç bulur. İşte bu yüzden motoru curl ile sorgulayıp durum satırına bakmak yerine, kendi örneğinizin hata raporunu okumalısınız.

Herhangi bir değişiklik yapmadan önce instance raporlarını inceleyin

Aşağıdaki her çözüm, başarısız olan motorun adı ve instance tarafından kaydedilen hata gerekçesi ile başlar. SearXNG her ikisini de sunar. /stats sayfası, motorları hata sayıları ve güvenilirlikleri ile listeler; /stats/errors ise hata detaylarını JSON formatında döndürür; bu formatı saklamak ve gelecek hafta ile karşılaştırmak daha kolaydır. Bu sayfaları, instance için normalde kullandığınız tarayıcıda açın.

Container logları, olaylar gerçekleştiği anda aynı kayıtları tutar. Buradaki servis adı, container dokümantasyonu ile birlikte yayınlanan compose dosyasında kullanılan isimdir; bu nedenle eğer farklıysa kendi servis adınızı kullanın.

docker compose logs -f core

Log takibi devam ederken başarısız olan bir arama gerçekleştirin. Arama çalıştığı sırada başarısız olan motor için bir girdi görmelisiniz. Motor adını ve instance tarafından yazdırılan tam hata gerekçesini not edin. Bir blog yazısından, bu yazı da dahil olmak üzere, motor adı kopyalamayın. Veri merkezi IP adreslerine kısıtlama getiren motorlar aydan aya değişir; sizin için başarısız olan bir motor, bu yazıyı kaleme alan kişi için sorunsuz çalışıyor olabilir.

Eğer sonuç sayfası hiçbir hata göstermiyor ancak sonuçlar yetersiz kalıyorsa, o motor için display_error_messages ayarını kontrol edin. Bu ayar varsayılan olarak true değerindedir; bu özelliği kapatmış bir instance, ihtiyacınız olan tek mesajı gizliyor olabilir.

SearXNG'nin başarısız bir motoru yeniden deneme ve askıya alma süreci

SearXNG, kendisini reddeden bir motoru zorlamaya devam etmez. Başarısız olan motor askıya alınır ve askıda kaldığı süre boyunca tamamen devre dışı bırakılır; bozuk bir motorun sessizce kaybolan bir motora dönüşme şekli budur.

Bu süreci iki katman kontrol eder ve her ikisi de settings.yml içindeki search: altında yer alır. Herhangi bir ayarı yapıştırmadan önce bu anahtar adlarını ve değerlerini, kullandığınız sürüm için searx/settings.yml ile doğrulayın; çünkü bu ayarlar sürümler arasında yer değiştirmiştir ve ayarlar dokümantasyon sayfasındaki örnek, SearXNG'nin gerçekte yüklediği dosyadan daha uzun askıya alma süreleri göstermektedir. 17 Ekim 2026 itibarıyla searx/settings.yml içinde sunulan varsayılan değerler şöyledir:

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

İlk katman, zaman aşımı gibi olağan hataları yönetir. Yasaklama ban_time_on_fail saniyede başlar ve her ardışık hatada max_ban_time_on_fail değerine kadar artar. Varsayılan tavan süresi iki dakikadır; bu nedenle kararsız bir motor, sorun ortadan kalktıktan sonra birkaç dakika içinde kendiliğinden düzelir.

İkinci katman, bu kılavuzun konusunu oluşturan hataları yönetir. SearXNG, yanıtı genel bir hata yerine bir doğrulama (challenge) veya reddetme olarak tanımladığında, suspended_times içindeki eşleşen girdiyi uygular ve bu sayıların çoğu çok daha büyüktür. 180 saniye, basit bir reddetme veya 429 hatası için üç dakikadır. 3600, genel bir CAPTCHA için bir saattir. 86400 tam bir gündür. 604800 bir haftadır. 1296000 on beş gündür. cf_ ön ekine sahip anahtarlar, doğrulama Cloudflare olarak tanımlandığında; recaptcha_ ise reCAPTCHA olarak tanımlandığında geçerli olur.

Bu durum, en çok zaman kaybettiren belirtiyi açıklar. Nedeni bulursunuz, düzeltirsiniz ancak motor bir saat boyunca veya bir Cloudflare doğrulamasından sonra günlerce hiçbir sonuç döndürmez. Motor hala askıdadır. Askıya alma durumu çalışan süreçte tutulur, bu nedenle container'ı yeniden başlatmak bu durumu temizler ve bir sonraki arama motoru tekrar dener. Burada basit bir yeniden başlatma iş görür; görüntüleri boş yere yeniden oluşturmaya başlamadan önce ne zaman yeniden başlatmanın yeterli olduğunu ve ne zaman container'ı yeniden oluşturmanız gerektiğini bilmek faydalıdır. Eğer motor yeniden başlatmadan hemen sonra tekrar başarısız olursa, yaptığınız düzeltme işe yaramamış demektir.

Motor başına yapılan bir ayar uyarı gerektirir. retry_on_http_error, motor listelediğiniz durum kodlarıyla yanıt verdiğinde isteği yeniden dener. Sizi engelleyen bir motora karşı yeniden denemeler, sunucunuzun bot olduğuna zaten karar vermiş sisteme daha fazla trafik gönderir. Gerçekten kesintili çalışan bir motoru aşmaya çalışmıyorsanız bu ayarı değiştirmeyin.

SSH tüneli upstream belgelerini ve düzeltemediği noktaları açıklar

17 October 2026 tarihinde kontrol edilen SearXNG yönetici belgeleri bu soruna manuel tünel kullanarak çözüm getirir. Sunucunuz üzerinden bir SOCKS proxy açar, masaüstü tarayıcınızı bu proxy'yi kullanacak şekilde ayarlar ve motor sunucunun adresini görürken doğrulamayı elle tamamlarsınız.

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

-D 8080, SSH bağlantısı üzerinden yönlendirme yapan yerel bir SOCKS sunucusunu 8080 portunda açar. -N uzak bir komut çalıştırmaz ve -q tüneli sessiz tutar; bu nedenle sağlıklı bir tünel hiçbir çıktı vermez ve sonlanmaz. Tüneli ikinci bir terminalden kontrol edin:

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

İlk komut sunucunuzun adresini, ikinci komut ise masaüstünüzün adresini yazdırmalıdır. İki sonuç aynıysa istek tünel üzerinden gitmiyordur. Ardından tarayıcınızın ağ ayarlarını 127.0.0.1 adresindeki 8080 portuna SOCKS5 proxy kullanacak şekilde ayarlayın, sunucuyu bildirdiğini doğrulamak için aynı adres kontrol hizmetini tarayıcıda açın ve sizi doğrulamaya yönlendiren motoru ziyaret edin. Doğrulamayı orada tamamlayın.

Şimdi yöntemin sınırlarını açıkça belirtelim. Bu yöntemi sınırlayan dört nokta vardır. Motorun verdiği cookie masaüstü tarayıcınıza kaydedilir ve SearXNG tarayıcınızdaki cookie'lere erişemez. Bu nedenle örneğinize yardımcı olabilecek tek unsur, motorun adresle ilişkilendirerek kaydettiği bilgidir. Bu kayıt, motorun belirlediği ve yayımlamadığı bir takvime göre sona erer. Prosedürün hiçbir bölümü otomatik değildir; bir sonraki sefer yine klavyenin başına geçmeniz gerekir. Ayrıca başkalarının kullandığı bir örnekte doğrulamayı tetikleyen sorgu hızı devam eder ve doğrulama yeniden gelir.

Bu yöntemi bugün bir örneği çalışır duruma getirmek için kullanın. Ancak örneğinizi bunun üzerine kurmayın.

Kalıcı çözüm: sizi engelleyen motorları devre dışı bırakın veya ağırlıklarını değiştirin

En ucuz ve kalıcı çözüm, sunucunuza yanıt vermeyen bir motora sorgu göndermeyi durdurmaktır. settings.yml dosyanız, container imajı içindeki use_default_settings: true ile başlar; bu, engines: altında eşleşen bir name girdisinin yalnızca listelediğiniz anahtarları geçersiz kıldığı ve varsayılan tanımın geri kalanını olduğu gibi bıraktığı anlamına gelir.

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

disabled: true, motoru tercihler sayfasında tutarken varsayılan olarak kapatır; böylece motoru isteyen bir kullanıcı, kendi aramaları için tekrar açabilir. inactive: true ise motoru kullanıcı ayarlarından tamamen kaldırır; adresinizden asla çalışmayacak bir motor için yapmanız gereken budur. weight farklı bir işlev görür: SearXNG sonuçları birleştirip sıralarken o motorun sonuçlarının ne kadar etkili olacağını ölçeklendirir; 1'in altındaki bir ağırlık, marjinal bir motoru tutmanızı sağlar ancak ilk sayfayı domine etmesini engeller.

Düzenleme yaptıktan sonra container'ı yeniden başlatın, birkaç arama yapın ve ardından /stats kısmını tekrar kontrol edin. Altı çalışan motora sahip temiz bir istatistik sayfası, yirmi motorlu ve hatalarla dolu bir sayfadan daha kullanışlıdır.

Kalıcı çözüm: giden istekleri bir proxy üzerinden yönlendirin

SearXNG, giden motor isteklerini bir proxy üzerinden gönderebilir; bu durum, motorun gördüğü adresi değiştirir. Ayarı outgoing: altında genel olarak yapın veya yalnızca tek bir motor sorun çıkarıyorsa motor bazında yapılandırın.

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

Proxy'nin ana bilgisayar adını çözümlemesini istediğinizde socks5:// yerine socks5h:// tercih edin; çünkü h, adın sunucunuzda çözümlenmek yerine doğrudan proxy'ye gönderilmesi anlamına gelir. Aynı zamanda zaman aşımı bütçesini artırın. request_timeout varsayılan olarak 3.0 saniyedir; bir proxy her isteğe ek bir gidiş-dönüş süresi ekler ve normalde zamanında yanıt veren motorlar zaman aşımı nedeniyle başarısız olmaya başlar. extra_proxy_timeout tam olarak bu amaçla mevcuttur ve bir proxy kullanıldığında süre ekler. Bunu 10 gibi bir tam sayı olarak yazın. Ondalık sayıları kabul eden request_timeout'nın aksine, extra_proxy_timeout ayar şeması içinde bir tam sayıdır; bu nedenle, giden ayarları dokümantasyon sayfasındaki yorumlanmış örnekte öyle yazılmış olsa bile, 10.0 gibi bir değer geçersiz settings.yml olarak reddedilir.

Bir proxy'nin size maliyeti:

• Proxy operatörü, örneğinizin hangi motorlara ve ne zaman sorgu gönderdiğini görür. TLS (taşıma katmanı güvenliği), arama terimlerini günlüklerinden uzak tutar çünkü sorgu şifreli isteğin içindedir; ancak trafiğinizin şekli ve zamanlaması operatör tarafından görülebilir.
• Paylaşımlı bir çıkış adresi, o adrese ödeme yapan diğer herkesle paylaşılır. Eğer bu kişiler veri kazıma yapıyorsa, onların itibarını devralırsınız; bu durum bazen kaçmaya çalıştığınız engellemeden daha hızlı gerçekleşir.
• Ucuz konut tipi proxy havuzları, genellikle sahiplerinin trafik taşımayı bilerek kabul etmediği tüketici cihazlarından oluşturulur. Ne satın aldığınızı bilin.
• using_tor_proxy: true, Tor üzerinden yönlendirme yapar ancak çıkış düğümü adresleri tamamen yayınlanmıştır ve veri merkezi aralıklarını engelleyen bir motor, genellikle çıkış düğümlerini de en az o kadar sert engeller.
• Arama artık sunucunuzun dışındaki bir servise bağımlıdır; bu servis kendi takvimine göre başarısız olabilir ve sonuçlarınızı da beraberinde götürebilir.

Bir proxy, engellemeyi kaldırmak yerine yerini değiştirir ve örneğinizin gizlilik hikayesi artık üçüncü bir tarafı da içerir. Eğer kısa bir gizlilik hikayesi self-host etmenizin nedeni ise, herhangi bir hizmete kaydolmadan önce bunu self-hosted bir örneğin gerçekte neyi gizleyip neyi gizlemediği ile karşılaştırın.

Kalıcı çözüm: bilinçli olarak daha küçük bir motor kümesi çalıştırmak

Çoğu kullanıcının göz ardı ettiği seçenek, daha az motorla yetinmektir. SearXNG'nin değeri birleştirmeden gelir; her seferinde yanıt veren altı motorun birleşimi, yarısı saatlerce veya günlerce askıda kalan yirmi motorun birleşiminden daha iyidir. /stats kısmını bir hafta boyunca izleyin ve IP adresinizden temiz bir kayıt tutan motorları koruyun.

API anahtarı ile kimlik doğruladığınız motorlar farklı davranır; çünkü motor kim olduğunuzu bilir ve sizin bir insan olup olmadığınızı tahmin etmek yerine bir kota uygular. Bunun karşılığında bir hesap, ayar dosyanızda duran bir anahtar ve genellikle bir fatura ödemeniz gerekir. Sizin için önemli olan bir veya iki motor için bu genellikle en zahmetsiz yoldur.

Bu kararı diğer araçlarınızı göz önünde bulundurarak verin. Askıya alınan bir motor, sonuçları API üzerinden okuyan herhangi bir uygulama için görünmezdir; çünkü Open WebUI ve benzeri araçların sorguladığı JSON API bir hata döndürmek yerine sadece daha az sonuç döndürür. Eğer otomatize edilmiş bir süreç örneğinizden besleniyorsa, sonuçların kötüleştiğine dair şikayet gelmesini beklemek yerine /stats/errors kısmını düzenli aralıklarla sorgulayın.

Bununla uğraşmaya gerçekten değer mi?

Bunu kullanıcı sayısını hesaplayarak yanıtlayın. Tek kişinin kullandığı bir örnek, tek bir adresten günde az sayıda arama gönderir. Birçok motor bu hızda doğrulama istemez. Bir motor doğrulama istediğinde çözüm basittir: motoru kaldırın; yokluğunu neredeyse fark etmezsiniz. Bu, küçük bir VPS üzerinde SearXNG'yi kendiniz çalıştırmanın olağan deneyimidir ve tünel veya proxy gerektirmez.

Herkese açık veya paylaşımlı bir örnek, aynı yazılımı çalıştıran farklı bir makinedir. Tetikleyici sorgu hızıdır ve eklediğiniz her kullanıcıyla bu hız artar. Bu nedenle doğrulamalar herhangi bir yapılandırmanın karşılayabileceğinden daha hızlı gelir. Başlangıçtan itibaren daha küçük bir motor kümesi planlayın. Ayrıca şimdi eklediğiniz herhangi bir proxy'nin, hesabınız üzerinden diğer kişilerin aramalarını taşıyacağını unutmayın.

Otomatik istemciler bu iki durumun arasındadır, ancak daha zor duruma yakındır. Bir soruyu yanıtlamak için birden fazla arama yapan bir agent, hiçbir insanın üretmeyeceği ani istek yoğunlukları oluşturur. Bu nedenle coding agent'ları ve araştırma araçlarını yönlendirdiğiniz bir örnek, elle kullanılan aynı örneğe göre doğrulamalarla daha erken karşılaşır. Kullanımınız buysa motor kümesini kapsam yerine güvenilirliğe göre seçin ve agent'ın gerçekten alabileceği sonuçlarla çalışmasına izin verin.

Geçerli kural şudur: Self-host etme nedeniniz bir motorsa onun için mücadele edin; değilse motoru kaldırın.

FAQ

Bir SearXNG motoru sorunu düzelttikten sonra neden hâlâ sonuç döndürmüyor?

Çünkü motor hâlâ askıya alınmış durumdadır. SearXNG bir motordan gelen doğrulama isteğini veya reddetmeyi algıladığında, search.suspended_times içinde belirtilen süre boyunca bu motora sorgu göndermeyi durdurur. Dağıtılan varsayılan değerler, reddetmenin türüne bağlı olarak üç dakika ile on beş gün arasında değişir. Askıya alma durumu çalışan süreçte tutulur. Bu nedenle container'ı yeniden başlatmak durumu temizler ve sonraki arama motoru yeniden dener. Motor yeniden başlatmanın hemen ardından tekrar başarısız olursa düzeltmeniz işe yaramamıştır.

Bir motorun CAPTCHA hatası, örneğimin döndürdüğü 429 ile aynı mı?

Bunlar zıt yönde gerçekleşir. Örneğinizden tarayıcınıza gönderilen 429, SearXNG'nin isteğinizin otomatik göründüğüne karar veren kendi sınırlayıcısıdır ve bunu siz yapılandırırsınız. CAPTCHA veya block hatası ise upstream motorun sunucunuzu reddetmesidir ve sizin kontrol etmediğiniz donanım üzerinde kararlaştırılır. Sonuçlar sayfası yükleniyor ve yalnızca bazı motorlar eksik görünüyorsa ikinci durumla karşı karşıyasınızdır.

VPN veya sunucumdaki bir proxy motor CAPTCHA'larını düzeltir mi?

Bazen düzeltir, ancak bunun bir bedeli vardır. Giden istekleri outgoing.proxies üzerinden yönlendirmek, motorun gördüğü adresi değiştirir ve veri merkezi aralığınıza bağlı bir engeli kaldırabilir. Proxy operatörü hangi motorları ne zaman sorguladığınızı görür. Ayrıca diğer müşterilerin itibarlarıyla ilişkilendirilmiş ortak bir çıkış adresi kullanılır. Ek gecikme, request_timeout ve extra_proxy_timeout değerlerini artırmadığınız sürece timeout oluşmasına neden olur. Tor, using_tor_proxy üzerinden kullanılabilir; ancak çıkış adresleri yayımlanır ve yaygın biçimde doğrulamaya tabi tutulur.

SearXNG'nin CAPTCHA'yı otomatik olarak çözmesini sağlayabilir miyim?

Bunun için bir ayar yoktur. Projenin belgelediği yöntem manueldir: SSH SOCKS tüneli, kendi tarayıcınız ve doğrulamayı kendi ellerinizle tamamlama. Doğrulamaları otomatik olarak yanıtlamak için geliştireceğiniz her şey motorun belirttiği politikaya aykırı çalışır ve doğrulama her değiştiğinde sessizce bozulur. Bu durumda bir arama örneği çalıştırmak yerine scraper bakımını yapmanız gerekir. Adresinizi engelleyen motorları kaldırmak, çalışmaya devam eden çözümdür.