SearXNG błąd CAPTCHA: jak naprawić blokady wyszukiwarek

Co oznacza błąd CAPTCHA w SearXNG

Błędy CAPTCHA w SearXNG wynikają z działania wyszukiwarek, z których korzysta instancja. Serwer wysłał zapytanie o wyniki, lecz wyszukiwarka odpowiedziała stroną z wyzwaniem zamiast danymi. SearXNG zarejestrowało błąd dla tej wyszukiwarki, ponieważ odpowiedź nie zawierała treści możliwych do przetworzenia. Instancja jest sprawna. Zewnętrzny system, nad którym nie sprawujesz kontroli, uznał, że zapytanie nie pochodzi od człowieka.

Ten fakt determinuje wszystkie poniższe rozwiązania. Decyzja zapadła na infrastrukturze wyszukiwarki, więc żadne ustawienie w settings.yml nie może jej zmienić. Można natomiast zmienić adres IP, z którego wychodzi zapytanie, ograniczyć listę używanych wyszukiwarek lub zmodyfikować sposób zachowania instancji w przypadku odmowy dostępu.

Dwie awarie o podobnych objawach i sposób ich rozróżnienia

Pierwsza awaria polega na tym, że własna instancja zwraca błąd HTTP 429 (zbyt wiele żądań) do przeglądarki użytkownika. Jest to mechanizm ograniczający SearXNG, czyli warstwa wykrywania botów znajdująca się przed punktem końcowym wyszukiwania. Działa ona na serwerze i podlega samodzielnej konfiguracji. ogranicznik zwracający 429 własnym użytkownikom to odrębny problem z odrębnymi ustawieniami, do którego poniższe porady nie mają zastosowania.

Druga awaria dotyczy źródła zewnętrznego (upstream). Strona z wynikami ładuje się poprawnie, lecz brakuje na niej jednego lub kilku silników wyszukiwania albo wyświetlany jest komunikat o błędzie. Instancja nie odrzuciła żadnego żądania. To silnik zewnętrzny odrzucił żądanie serwera.

• Strona nie ładuje się lub punkt końcowy wyszukiwania zwraca 429: należy sprawdzić ogranicznik.
• Strona ładuje się, wyniki są niepełne lub silnik jest oznaczony błędem: należy sprawdzić źródło zewnętrzne i kontynuować lekturę.

Oba problemy mogą wystąpić na tej samej instancji i wzajemnie na siebie wpływać, ponieważ zbyt luźno skonfigurowany ogranicznik przepuszcza ruch, który zwiększa częstotliwość zapytań wychodzących. Należy diagnozować je pojedynczo.

Dlaczego silniki SearXNG zwracają błędy CAPTCHA na VPS, a nie na moim laptopie?

Wynika to z adresu, z którego pochodzi żądanie. Twoje domowe łącze posiada adres z puli konsumenckiego dostawcy usług internetowych (ISP), współdzielony w czasie z wieloma zwykłymi użytkownikami. Twój VPS posiada adres z puli centrum danych, a te zakresy są publicznie dostępne: każdy może sprawdzić, które adresy należą do dostawcy hostingu. Silnik, który chce ograniczyć dostęp dla scraperów, traktuje żądania z zakresów hostingowych jako podejrzane, ponieważ w tych zakresach rzadko przebywa człowiek korzystający z przeglądarki.

Na ocenę adresu wpływa również kilka innych czynników. Twoja instancja wysyła jedno żądanie na silnik przy każdym wyszukiwaniu użytkownika, więc nawet niewielka liczba użytkowników generuje natężenie ruchu z jednego adresu, którego nie wygenerowałaby pojedyncza osoba. SearXNG z założenia nie utrzymuje sesji z silnikiem ani nie przechowuje długotrwałych plików cookie, więc każde żądanie dociera bez żadnej historii. Ponadto adres może posiadać historię, której nie stworzyłeś, ponieważ dostawcy poddają adresy recyklingowi, a poprzedni użytkownik mógł przez miesiące wykorzystywać je do scrapowania.

Sama odmowa nie zawsze jest oczywistą awarią. Silnik może odpowiedzieć kodem 403, 429 lub kodem HTTP 200 z treścią strony weryfikacyjnej w ciele odpowiedzi. Ten ostatni przypadek wprowadza użytkowników w błąd, ponieważ sprawdzenie kodu statusu sugeruje, że silnik działa poprawnie, podczas gdy SearXNG nie znajduje żadnych wyników w odpowiedzi. Dlatego należy analizować raport błędów własnej instancji, zamiast używać polecenia curl wobec silnika i sprawdzać jedynie linię statusu.

Zapoznaj się z raportami instancji przed wprowadzeniem zmian

Każda z poniższych metod naprawy rozpoczyna się od nazwy silnika, który uległ awarii, oraz przyczyny zarejestrowanej przez instancję. SearXNG udostępnia oba te elementy. Strona /stats zawiera listę silników wraz z liczbą błędów i ich niezawodnością, a /stats/errors zwraca szczegóły błędu w formacie JSON, co ułatwia przechowywanie i porównywanie danych w kolejnym tygodniu. Otwórz je w przeglądarce, której zazwyczaj używasz do obsługi instancji.

Dziennik kontenera zawiera te same zdarzenia w czasie rzeczywistym. Nazwa usługi w tym miejscu odpowiada nazwie użytej w pliku compose opublikowanym wraz z dokumentacją kontenera, więc użyj własnej nazwy, jeśli jest inna.

docker compose logs -f core

Uruchom wyszukiwanie, które kończy się niepowodzeniem, podczas gdy dziennik jest w trybie śledzenia. Podczas wykonywania wyszukiwania powinien pojawić się wpis dotyczący niedziałającego silnika. Zapisz nazwę silnika oraz dokładny ciąg przyczyny wyświetlony przez instancję. Nie kopiuj nazw silników z wpisów na blogach, w tym z tego artykułu. Zestaw silników blokujących adresy centrów danych zmienia się z miesiąca na miesiąc, a silnik, który nie działa u Ciebie, może funkcjonować bez zarzutu u autora czytanego tekstu.

Jeśli strona z wynikami nie wykazuje żadnego błędu, a wyników jest niewiele, sprawdź display_error_messages dla danego silnika. Domyślnie ustawiona jest wartość true, a instancja, która ją wyłączyła, ukrywa komunikat, którego potrzebujesz.

W jaki sposób SearXNG ponawia próby i zawiesza niedziałający silnik

SearXNG nie wysyła wielokrotnie zapytań do silnika, który odrzuca połączenia. Niedziałający silnik zostaje zawieszony i w tym czasie jest całkowicie pomijany. W ten sposób uszkodzony silnik staje się silnikiem, który po prostu nie zwraca wyników.

Dwie warstwy kontrolują ten proces, obie znajdują się w search: w pliku settings.yml. Przed wklejeniem jakichkolwiek zmian należy sprawdzić nazwy kluczy i wartości w searx/settings.yml dla aktualnie używanej wersji, ponieważ były one przenoszone między wydaniami, a przykłady w dokumentacji mogą wskazywać dłuższe czasy zawieszenia niż te, które faktycznie ładuje SearXNG. W wersji dostarczonej w searx/settings.yml z dnia 10 października 2026 r. wartości domyślne to:

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

Pierwsza warstwa obsługuje typowe awarie, takie jak przekroczenie limitu czasu (timeout). Blokada rozpoczyna się od ban_time_on_fail sekund i rośnie wraz z każdą kolejną awarią, aż do osiągnięcia max_ban_time_on_fail. Dwie minuty to domyślny limit, więc niestabilny silnik odzyskuje sprawność automatycznie w ciągu kilku minut od ustąpienia problemu.

Druga warstwa obsługuje awarie, których dotyczy ten przewodnik. Gdy SearXNG rozpozna odpowiedź jako wyzwanie (challenge) lub odmowę, a nie jako ogólny błąd, stosuje odpowiedni wpis z suspended_times, a większość tych wartości jest znacznie wyższa. 180 sekund to trzy minuty w przypadku zwykłej odmowy lub błędu 429. 3600 to godzina w przypadku ogólnego CAPTCHA. 86400 to pełna doba. 604800 to tydzień. 1296000 to piętnaście dni. Klucze z prefiksem cf_ mają zastosowanie, gdy wyzwanie jest rozpoznawane jako Cloudflare, a recaptcha_, gdy jest rozpoznawane jako reCAPTCHA.

To wyjaśnia objaw, który powoduje największą stratę czasu. Znalezienie przyczyny i jej naprawienie nie powoduje natychmiastowego działania silnika, jeśli ten pozostaje zawieszony przez godzinę lub kilka dni po wyzwaniu Cloudflare. Stan zawieszenia jest przechowywany w działającym procesie, więc restart kontenera czyści ten stan, a kolejne wyszukiwanie ponownie próbuje użyć silnika. Zwykły restart jest tutaj wystarczający i warto wiedzieć, kiedy restart wystarczy, a kiedy należy odtworzyć kontener, zanim rozpocznie się bezcelowe przebudowywanie obrazów. Jeśli silnik ponownie zawiedzie natychmiast po restarcie, oznacza to, że naprawa była nieskuteczna.

Jedno ustawienie dla każdego silnika wymaga ostrzeżenia. retry_on_http_error ponawia żądanie, gdy silnik odpowiada kodami statusu wymienionymi na liście. W przypadku silnika, który blokuje dostęp, ponawianie prób wysyła więcej ruchu do systemu, który już uznał serwer za bota. Nie należy zmieniać tego ustawienia, chyba że celem jest obejście silnika, który działa w sposób rzeczywiście przerywany.

Dokumentacja upstream tunelu SSH i czego ona nie naprawia

Zweryfikowano 10 października 2026 r. Dokumentacja administracyjna SearXNG rozwiązuje ten problem za pomocą ręcznego tunelu. Należy otworzyć proxy SOCKS przez serwer, skierować na nie przeglądarkę na komputerze stacjonarnym i ręcznie rozwiązać wyzwanie (challenge), podczas gdy silnik widzi adres serwera.

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

-D 8080 otwiera lokalny serwer SOCKS na porcie 8080, który przesyła ruch przez połączenie SSH. -N nie uruchamia żadnego zdalnego polecenia, a -q zapewnia pracę w tle, więc poprawnie działający tunel nie wypisuje żadnych komunikatów i nie kończy działania. Należy sprawdzić to z poziomu drugiego terminala:

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

Pierwsze polecenie powinno wyświetlić adres serwera, a drugie adres komputera stacjonarnego. Dwie identyczne odpowiedzi oznaczają, że żądanie nie przechodzi przez tunel. Następnie należy skonfigurować ustawienia sieciowe przeglądarki na proxy SOCKS5 pod adresem 127.0.0.1 na porcie 8080, wczytać ten sam sprawdzacz adresu w przeglądarce, aby potwierdzić, że wskazuje on serwer, a następnie odwiedzić silnik, który wyświetla wyzwanie. Należy tam rozwiązać wyzwanie.

Teraz kwestia uczciwości. Cztery czynniki ograniczają tę metodę. Ciasteczko (cookie) przekazane przez silnik trafia do przeglądarki na komputerze stacjonarnym, a SearXNG nie ma dostępu do ciasteczek przeglądarki, więc jedyną rzeczą, która może pomóc instancji, jest to, co silnik zapisuje w powiązaniu z samym adresem. Ten zapis wygasa zgodnie z harmonogramem wybranym przez silnik, który nie jest publikowany. Żaden etap tej procedury nie jest zautomatyzowany, więc następnym razem konieczna będzie ponowna interakcja z klawiaturą. Ponadto w przypadku instancji używanej przez inne osoby, częstotliwość zapytań, która wywołała wyzwanie, nadal występuje, więc wyzwanie powróci.

Należy użyć tego rozwiązania, aby uruchomić jedną instancję jeszcze dzisiaj. Nie należy budować instancji w oparciu o tę metodę.

Trwałe rozwiązanie: wyłączenie lub zmiana wagi silników powodujących błędy

Najtańszym trwałym rozwiązaniem jest zaprzestanie wysyłania zapytań do silnika, który nie obsługuje danego serwera. Plik settings.yml zaczyna się od use_default_settings: true w obrazie kontenera, co oznacza, że wpis w engines: z pasującym name nadpisuje tylko wymienione klucze, pozostawiając resztę domyślnej definicji bez zmian.

use_default_settings: true

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

Opcja disabled: true domyślnie wyłącza silnik, pozostawiając go jednak na stronie preferencji, dzięki czemu użytkownik może go samodzielnie włączyć dla własnych wyszukiwań. Opcja inactive: true całkowicie usuwa go z ustawień użytkownika, co jest zalecanym działaniem w przypadku silnika, który nigdy nie będzie działał z danego adresu IP. Opcja weight pełni inną funkcję: skaluje znaczenie wyników danego silnika podczas ich łączenia i szeregowania przez SearXNG. Waga poniżej 1 pozwala zachować marginalny silnik bez ryzyka, że zdominuje on pierwszą stronę wyników.

Po edycji należy zrestartować kontener, wykonać kilka wyszukiwań, a następnie ponownie sprawdzić /stats. Przejrzysta strona statystyk z sześcioma działającymi silnikami jest bardziej użyteczna niż strona pełna błędów z dwudziestoma.

Trwałe rozwiązanie: kierowanie żądań wychodzących przez proxy

SearXNG umożliwia kierowanie wychodzących żądań do silników wyszukiwania przez proxy, co zmienia adres IP widoczny dla silnika. Ustawienie to można skonfigurować globalnie w outgoing: lub dla poszczególnych silników, jeśli problem dotyczy tylko jednego z nich.

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

Wybierz socks5h:// zamiast socks5://, jeśli chcesz, aby to proxy rozwiązywało nazwę hosta, ponieważ h oznacza, że nazwa jest przesyłana do proxy zamiast być sprawdzana na Twoim serwerze. Jednocześnie zwiększ limit czasu oczekiwania. request_timeout domyślnie wynosi 3.0 sekundy, a proxy dodaje dodatkowy czas na komunikację w każdym żądaniu, przez co silniki, które wcześniej odpowiadały w terminie, mogą zacząć zwracać błędy przekroczenia czasu. extra_proxy_timeout służy dokładnie do tego celu i dodaje sekundy w przypadku korzystania z proxy. Wartość należy podać jako liczbę całkowitą, na przykład 10: schemat ustawień wymaga liczby całkowitej, a wartość taka jak 10.0 zostanie odrzucona jako nieprawidłowy settings.yml.

Koszty korzystania z proxy:

• Operator proxy widzi, które silniki odpytuje Twoja instancja i kiedy to robi. TLS (transport layer security) chroni zapytania przed wglądem w ich treść, ponieważ zapytanie znajduje się wewnątrz zaszyfrowanego żądania, jednak wzorce i czas występowania ruchu są dla operatora widoczne.
• Współdzielony adres wyjściowy jest używany przez wszystkich innych użytkowników danej usługi. Jeśli inni użytkownicy wykonują scraping, przejmujesz ich reputację, co czasem prowadzi do blokady szybciej, niż w przypadku adresu, którego próbujesz uniknąć.
• Tanie pule proxy typu residential często bazują na urządzeniach konsumenckich, których właściciele nie wyrazili świadomej zgody na przesyłanie cudzego ruchu. Sprawdź źródło kupowanej usługi.
• using_tor_proxy: true kieruje ruch przez Tor, jednak adresy węzłów wyjściowych są w pełni publiczne, a silniki, które blokują zakresy adresów centrów danych, zazwyczaj blokują węzły wyjściowe z co najmniej taką samą surowością.
• Wyszukiwanie staje się zależne od usługi zewnętrznej, która może ulec awarii niezależnie od Twojego serwera, co spowoduje brak wyników wyszukiwania.

Proxy przenosi problem blokady w inne miejsce zamiast go usuwać, a kwestia prywatności Twojej instancji obejmuje teraz stronę trzecią. Jeśli głównym powodem samodzielnego hostowania jest ograniczona liczba podmiotów mających dostęp do danych, rozważ to w kontekście tego, co faktycznie ukrywa instancja self-hosted, a czego nie, zanim zdecydujesz się na jakiekolwiek rozwiązanie.

Trwałe rozwiązanie: celowe ograniczenie liczby silników

Opcją pomijaną przez większość użytkowników jest akceptacja mniejszej liczby silników. Wartość SearXNG wynika z agregacji wyników, a połączenie sześciu silników, które odpowiadają za każdym razem, jest lepsze niż dwudziestu, z których połowa jest zawieszona przez wiele godzin lub dni. Monitoruj /stats przez tydzień i zachowaj silniki z czystą historią dla Twojego adresu IP.

Silniki, do których uwierzytelniasz się za pomocą klucza API, zachowują się inaczej, ponieważ silnik identyfikuje użytkownika i egzekwuje limity zamiast zgadywać, czy zapytanie pochodzi od człowieka. Ceną jest konieczność posiadania konta, przechowywania klucza w pliku konfiguracyjnym oraz zazwyczaj opłaty. W przypadku jednego lub dwóch kluczowych dla Ciebie silników jest to często najmniej uciążliwa droga.

Podejmij decyzję, biorąc pod uwagę pozostałe narzędzia. Zawieszony silnik jest niewidoczny dla procesów odczytujących wyniki przez API, ponieważ interfejs JSON API, z którego korzysta Open WebUI i podobne narzędzia po prostu zwraca mniej wyników zamiast błędu, który narzędzie mogłoby wykryć. Jeśli od Twojej instancji zależą procesy automatyczne, odpytuj /stats/errors zgodnie z harmonogramem, zamiast czekać na zgłoszenia o pogorszeniu jakości odpowiedzi.

Czy warto podejmować tę walkę?

Odpowiedź zależy od liczby użytkowników. Instancja dla jednej osoby wysyła kilka zapytań dziennie z jednego adresu, co dla wielu wyszukiwarek nie stanowi problemu. Gdy któraś z nich zacznie blokować ruch, rozwiązanie jest proste: należy zrezygnować z danej wyszukiwarki, co będzie niemal nieodczuwalne. Jest to typowe doświadczenie podczas samodzielnego uruchamiania SearXNG na małym VPS, które nie wymaga tuneli ani proxy.

Instancja publiczna lub współdzielona to inna skala działania przy tym samym oprogramowaniu. Częstotliwość zapytań jest czynnikiem wyzwalającym blokady i rośnie wraz z każdym nowym użytkownikiem, przez co wyzwania pojawiają się szybciej, niż jakakolwiek konfiguracja jest w stanie je obsłużyć. Należy od początku planować mniejszy zestaw wyszukiwarek i pamiętać, że każde dodane proxy przesyła zapytania innych osób w ramach Twojego konta.

Zautomatyzowani klienci znajdują się pomiędzy tymi przypadkami i skłaniają się ku trudniejszym scenariuszom. Agent, który wykonuje wiele wyszukiwań, aby odpowiedzieć na jedno pytanie, generuje serie zapytań, których nie tworzy człowiek, dlatego instancja używana przez agentów programistycznych i narzędzia badawcze napotyka blokady szybciej niż ta obsługiwana ręcznie. Jeśli takie jest przeznaczenie instancji, należy wybrać zestaw wyszukiwarek pod kątem niezawodności, a nie liczebności, i pozwolić agentowi pracować z wynikami, które faktycznie można uzyskać.

Obowiązuje prosta zasada: walcz o wyszukiwarkę, jeśli jest ona powodem, dla którego utrzymujesz własną instancję, i zrezygnuj z niej, jeśli tak nie jest.

FAQ

Dlaczego silnik SearXNG nadal nie zwraca wyników po naprawieniu problemu?

Ponieważ silnik pozostaje zawieszony. Gdy SearXNG wykryje wyzwanie (challenge) lub odmowę ze strony silnika, przestaje wysyłać do niego zapytania na czas określony w search.suspended_times. Domyślne ustawienia dostarczane z oprogramowaniem wynoszą od trzech minut do piętnastu dni, w zależności od rodzaju odmowy. Stan zawieszenia jest przechowywany w pamięci działającego procesu, więc restart kontenera usuwa go, a kolejne wyszukiwanie ponawia próbę połączenia z silnikiem. Jeśli silnik ponownie zgłosi błąd zaraz po restarcie, oznacza to, że wprowadzona poprawka nie zadziałała.

Czy błąd CAPTCHA silnika jest tym samym, co błąd 429 zwracany przez moją instancję?

Są to komunikaty przesyłane w przeciwnych kierunkach. Błąd 429 wysyłany z instancji do przeglądarki to własny mechanizm ograniczający SearXNG, który uznaje żądanie za zautomatyzowane; jego konfiguracja zależy od administratora. Błąd CAPTCHA lub blokada to odmowa ze strony zewnętrznego silnika, nałożona na sprzęcie, nad którym nie ma się kontroli. Jeśli strona z wynikami ładuje się, ale brakuje tylko niektórych silników, występuje drugi z wymienionych przypadków.

Czy VPN lub proxy na serwerze rozwiąże problem z CAPTCHA silników?

Czasami, ale wiąże się to z kosztami. Kierowanie wychodzących żądań przez outgoing.proxies zmienia adres widoczny dla silnika, co może usunąć blokadę przypisaną do zakresu adresów centrum danych. Operator proxy zyskuje wgląd w to, jakie silniki i kiedy są odpytywane, współdzielony adres wyjściowy posiada reputację wypracowaną przez innych klientów, a dodatkowe opóźnienia powodują przekroczenia czasu oczekiwania (timeouts), chyba że zwiększone zostaną wartości request_timeout oraz extra_proxy_timeout. Tor jest dostępny przez using_tor_proxy, jednak adresy wyjściowe są publicznie znane i często poddawane weryfikacji.

Czy można skonfigurować SearXNG tak, aby automatycznie rozwiązywał CAPTCHA?

Nie ma takiego ustawienia. Metoda dokumentowana przez projekt jest ręczna: tunel SSH SOCKS, własna przeglądarka i samodzielne rozwiązanie wyzwania. Każde rozwiązanie zbudowane w celu automatycznego odpowiadania na wyzwania jest sprzeczne z polityką silnika i przestaje działać przy każdej zmianie mechanizmu weryfikacji, co zmusza do utrzymywania skryptu typu scraper zamiast prowadzenia instancji wyszukiwarki. Rozwiązaniem, które pozostaje skuteczne, jest usunięcie silników blokujących dany adres.