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.

Jak SearXNG ponawia próby i zawiesza niedziałający silnik

SearXNG nie wysyła wielokrotnych zapytań do silnika, który odmawia współpracy. Niedziałający silnik zostaje zawieszony i całkowicie pominięty w procesie wyszukiwania. W ten sposób uszkodzony silnik staje się niewidoczny dla użytkownika.

Dwie warstwy kontrolują ten proces; obie znajdują się w search: w pliku settings.yml. Przed wklejeniem jakichkolwiek zmian należy sprawdzić nazwy tych kluczy w dokumentacji ustawień dla używanej wersji, ponieważ były one przenoszone między wydaniami. Według stanu na 2 września 2026 r. wartości domyślne to:

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: 604800

Pierwsza warstwa obsługuje typowe awarie, takie jak przekroczenie czasu oczekiwania (timeout). Blokada rozpoczyna się od ban_time_on_fail sekund i rośnie wraz z każdą kolejną awarią, aż do osiągnięcia wartości max_ban_time_on_fail. Domyślny limit wynosi dwie minuty, 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, gdzie wartości są znacznie wyższe. 86400 sekund 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.

Wyjaśnia to objaw, który pochłania najwięcej czasu. Znajdujesz przyczynę, naprawiasz ją, a silnik nadal nie zwraca wyników przez wiele godzin. Jest on nadal zawieszony. Stan zawieszenia jest przechowywany w działającym procesie, więc restart kontenera czyści ten stan, a kolejne wyszukiwanie ponownie odpytuje silnik. Zwykły restart jest tutaj wystarczający. Warto wiedzieć, kiedy restart wystarczy, a kiedy należy odtworzyć kontener, zanim zaczniesz bez potrzeby przebudowywać obrazy. Jeśli silnik ponownie zawiedzie natychmiast po restarcie, oznacza to, że wprowadzona poprawka nie zadziałała.

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 dodatkowy ruch do systemu, który już zaklasyfikował serwer jako bota. Nie należy zmieniać tego ustawienia, chyba że rozwiązuje się problem z silnikiem, który jest autentycznie niestabilny.

Dokumentacja upstream tunelu SSH i ograniczenia tego rozwiązania

Zweryfikowano 2 września 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 polecenia zdalnego, a -q zapewnia tryb cichy, więc poprawnie działający tunel nie wyświetla żadnych komunikatów i nie kończy pracy. 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 tester 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 kwestie istotne. Ta metoda ma cztery ograniczenia. Plik cookie wydany przez silnik trafia do przeglądarki na komputerze stacjonarnym, a SearXNG nie ma dostępu do plików cookie przeglądarki, więc jedyną rzeczą, która może pomóc instancji, jest to, co silnik przypisze do samego adresu IP. Ten wpis wygasa zgodnie z harmonogramem ustalonym przez silnik, który nie jest publikowany. Żaden etap tej procedury nie jest zautomatyzowany, więc przy kolejnym wystąpieniu problemu konieczna będzie ponowna interwencja ręczna. W przypadku instancji używanej przez inne osoby, częstotliwość zapytań, która wywołała wyzwanie, nadal pozostaje wysoka, więc wyzwanie pojawi się ponownie.

Metodę tę należy stosować w celu uruchomienia instancji w danym momencie. Nie należy budować instancji w oparciu o to rozwiązanie.

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 ruchu wychodzącego przez proxy

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

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

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

Preferuj socks5h:// zamiast socks5://, gdy chcesz, aby to proxy rozwiązywało nazwę hosta, ponieważ h powoduje wysłanie nazwy do proxy zamiast jej sprawdzania na własnym serwerze. Jednocześnie zwiększ limit czasu oczekiwania. request_timeout domyślnie wynosi 2.0 sekundy; proxy dodaje dodatkowy czas na każdy cykl żądania, przez co wyszukiwarki, 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, gdy używane jest proxy.

Koszty korzystania z proxy:

• Operator proxy widzi, które wyszukiwarki i kiedy odpytuje Twoja instancja. TLS (transport layer security) chroni zapytania przed wglądem w ich treść, ponieważ są one zaszyfrowane, jednak operator może analizować charakterystykę i czas występowania ruchu.
• 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 często prowadzi do blokad szybciej niż w przypadku bezpośredniego połączenia.
• 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. Należy weryfikować źródło usług.
• using_tor_proxy: true kieruje ruch przez Tor, jednak adresy węzłów wyjściowych są publicznie znane, a wyszukiwarki blokujące zakresy centrów danych zazwyczaj blokują węzły wyjściowe w co najmniej równym stopniu.
• Wyszukiwanie staje się zależne od zewnętrznej usługi, która może ulec awarii niezależnie od Twojego serwera, co spowoduje brak wyników.

Proxy przenosi problem blokady w inne miejsce, zamiast go usuwać, a polityka prywatności Twojej instancji musi teraz uwzględniać stronę trzecią. Jeśli głównym powodem self-hostingu jest minimalizacja śladów, rozważ to w kontekście co faktycznie ukrywa instancja self-hosted, a czego nie przed podjęciem decyzji o zakupie usługi.

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

Opcją, którą większość użytkowników pomija, jest akceptacja mniejszej liczby silników. Wartość SearXNG tkwi w 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 cały dzień. 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 wie, kim jesteś i egzekwuje limit zamiast zgadywać, czy jesteś człowiekiem. Ceną jest konieczność posiadania konta, klucz przechowywany w pliku ustawień oraz zazwyczaj opłaty. W przypadku jednego lub dwóch istotnych dla Ciebie silników jest to często najmniej uciążliwa droga.

Podejmij tę decyzję, mając na uwadze inne używane narzędzia. Zawieszony silnik jest niewidoczny dla wszystkiego, co odczytuje 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 cokolwiek zautomatyzowanego zależy od Twojej instancji, odpytuj /stats/errors zgodnie z harmonogramem, zamiast czekać, aż ktoś zgłosi, że jakość odpowiedzi uległa pogorszeniu.

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 usunięciu problemu?

Ponieważ silnik nadal znajduje się w stanie zawieszenia. Gdy SearXNG wykryje wyzwanie (challenge) lub odmowę ze strony silnika, przestaje wysyłać do niego zapytania na czas określony w search.suspended_times. Wartości domyślne wynoszą od jednej godziny do piętnastu dni, w zależności od rodzaju odmowy. Stan zawieszenia jest przechowywany w pamięci uruchomionego procesu, więc restart kontenera czyści ten stan, 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 Twojej instancji do przeglądarki to wynik działania własnego mechanizmu ograniczającego SearXNG, który uznał żądanie za zautomatyzowane; konfiguracja tego limitu zależy od użytkownika. Błąd CAPTCHA lub zablokowanie dostępu to odmowa ze strony zewnętrznego silnika, o której decyduje infrastruktura, nad którą nie masz kontroli. Jeśli strona z wynikami ładuje się, a brakuje tylko niektórych silników, masz do czynienia z tym drugim przypadkiem.

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 IP widoczny dla silnika, co może usunąć blokadę przypisaną do zakresu adresów Twojego centrum danych. Operator proxy zyskuje jednak wgląd w to, jakie silniki i kiedy odpytujesz, współdzielony adres wyjściowy posiada reputację wypracowaną przez innych klientów, a dodatkowe opóźnienia powodują przekroczenia czasu oczekiwania (timeouts), chyba że zwiększysz 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 mogę sprawić, aby SearXNG automatycznie rozwiązywał CAPTCHA?

Nie ma takiego ustawienia. Metoda dokumentowana przez projekt jest ręczna: tunel SOCKS przez SSH, własna przeglądarka i samodzielne rozwiązanie wyzwania. Każde rozwiązanie zbudowane w celu automatycznego odpowiadania na wyzwania jest sprzeczne z polityką silników i przestaje działać przy każdej zmianie mechanizmu weryfikacji. W efekcie zamiast utrzymywać instancję wyszukiwarki, utrzymujesz scraper. Jedynym trwałym rozwiązaniem jest usunięcie silników, które blokują Twój adres IP.