SearXNG błąd CAPTCHA od wyszukiwarek jak naprawić

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 ponawia bez końca prób wobec silnika, który odrzuca żądania. Niedziałający silnik zostaje zawieszony. Podczas zawieszenia jest całkowicie pomijany. W ten sposób uszkodzony silnik staje się silnikiem po cichu niedostępnym.

Sterują tym dwie warstwy. Obie znajdują się w search: w settings.yml. Przed wklejeniem czegokolwiek należy potwierdzić nazwy tych kluczy i ich wartości w searx/settings.yml dla używanej wersji, ponieważ zmieniały się między wydaniami. Przykład na stronie dokumentacji ustawień nadal pokazuje dłuższe zawieszenia niż plik faktycznie wczytywany przez SearXNG. W wersji dostarczanej w searx/settings.yml, 17 października 2026, wartości domyślne są następujące:

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 zwykłe błędy, takie jak przekroczenie limitu czasu. Blokada zaczyna się po ban_time_on_fail sekundach i wydłuża się po każdym kolejnym błędzie, maksymalnie do max_ban_time_on_fail. Domyślnie limit wynosi dwie minuty, dlatego niestabilny silnik sam odzyskuje działanie w ciągu kilku minut od ustąpienia problemu.

Druga warstwa obsługuje błędy opisane w tym poradniku. Gdy SearXNG rozpozna odpowiedź jako challenge lub odmowę, a nie jako ogólny błąd, stosuje odpowiadający jej wpis z suspended_times. Większość tych wartości jest znacznie większa. 180 sekund to trzy minuty i dotyczy zwykłej odmowy lub kodu 429. 3600 oznacza godzinę i dotyczy ogólnego CAPTCHA. 86400 oznacza pełną dobę. 604800 oznacza tydzień. 1296000 oznacza piętnaście dni. Klucze z prefiksem cf_ są używane, gdy challenge zostanie rozpoznany jako związany z Cloudflare. Klucze z prefiksem recaptcha_ są używane, gdy zostanie rozpoznany jako reCAPTCHA.

Wyjaśnia to objaw, który powoduje największą stratę czasu. Przyczyna zostaje znaleziona i usunięta, ale silnik nadal nie zwraca wyników przez godzinę albo przez kilka dni po challenge Cloudflare. Nadal jest zawieszony. Zawieszenie jest przechowywane w działającym procesie, więc ponowne uruchomienie kontenera je usuwa. Następne wyszukiwanie ponownie wypróbuje ten silnik. W tym przypadku wystarczy zwykłe ponowne uruchomienie. Przed niepotrzebnym przebudowywaniem obrazów warto wiedzieć kiedy wystarczy ponowne uruchomienie, a kiedy trzeba odtworzyć kontener. Jeśli silnik ponownie przestanie działać natychmiast po restarcie, zastosowana poprawka nie zadziałała.

Jedno ustawienie dotyczące poszczególnych silników wymaga ostrzeżenia. retry_on_http_error ponawia żądanie, gdy silnik odpowiada kodami stanu podanymi na liście. Wobec silnika, który blokuje serwer, ponowienia wysyłają dodatkowy ruch do systemu, który już uznał serwer za bota. To ustawienie należy pozostawić bez zmian, chyba że rozwiązywany jest problem z silnikiem, który rzeczywiście działa niestabilnie.

Dokumentacja dotycząca tunelu SSH upstream oraz to, czego on nie naprawia

Według dokumentacji administracyjnej SearXNG sprawdzonej 17 października 2026 problem ten rozwiązuje się za pomocą tunelu konfigurowanego ręcznie. Należy otworzyć proxy SOCKS przez serwer, ustawić je w przeglądarce na komputerze i ręcznie przejść weryfikację, podczas gdy silnik będzie widzieć adres serwera.

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

-D 8080 otwiera lokalny serwer SOCKS na porcie 8080 i przekazuje ruch przez połączenie SSH. -N nie wykonuje żadnego polecenia zdalnego, a -q wycisza jego działanie, dlatego działający tunel niczego nie wypisuje i nie kończy działania. Sprawdź go w drugim terminalu:

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. Dwa identyczne wyniki oznaczają, że żądanie nie przechodzi przez tunel. Następnie ustaw w przeglądarce proxy sieciowe SOCKS5 pod adresem 127.0.0.1 na porcie 8080, otwórz w niej ten sam serwis sprawdzający adres, aby potwierdzić, że raportuje adres serwera, i przejdź do silnika, który wyświetla weryfikację. Wykonaj ją w tym miejscu.

Teraz ważne ograniczenia. Tę metodę ograniczają cztery kwestie. Plik cookie przekazany przez silnik trafia do przeglądarki na komputerze, a SearXNG nie ma dostępu do plików cookie przeglądarki, dlatego jedyną rzeczą, która może pomóc instancji, jest informacja zapisana przez silnik dla tego adresu. Informacja ta wygasa zgodnie z harmonogramem ustalanym przez silnik, którego nie publikuje. Żadna część tej procedury nie jest zautomatyzowana, więc przy następnym wystąpieniu problemu trzeba ponownie usiąść przy klawiaturze. Ponadto na instancji używanej przez inne osoby nadal działa częstotliwość zapytań, która wywołała weryfikację, dlatego weryfikacja pojawi się ponownie.

Użyj tej metody, aby uruchomić jedną instancję jeszcze dziś po południu. Nie buduj na niej instancji.

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 może kierować wychodzące żądania do silników przez proxy, zmieniając adres widoczny dla silnika. Ustawienie globalne znajduje się w outgoing:. Można też skonfigurować je dla pojedynczego silnika, gdy problem dotyczy tylko jednego silnika.

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

Należy preferować socks5h:// zamiast socks5://, gdy hostname ma być rozwiązywany przez proxy, ponieważ h oznacza, że nazwa jest wysyłana do proxy, zamiast być wyszukiwana na serwerze. Jednocześnie należy zwiększyć budżet czasu oczekiwania. request_timeout ma domyślnie wartość 3.0 sekundy. Proxy dodaje dodatkową podróż w obie strony przy każdym żądaniu, więc silniki, które wcześniej odpowiadały na czas, zaczynają kończyć się błędem przekroczenia czasu oczekiwania. extra_proxy_timeout służy właśnie do tego i dodaje sekundy, gdy używane jest proxy. Należy podać liczbę całkowitą, na przykład 10. W przeciwieństwie do request_timeout, które przyjmuje wartości dziesiętne, extra_proxy_timeout jest liczbą całkowitą w schemacie ustawień. Dlatego wartość taka jak 10.0 zostaje odrzucona jako nieprawidłowy settings.yml, mimo że w komentowanym przykładzie na stronie dokumentacji ustawień połączeń wychodzących zapisano ją właśnie w ten sposób.

Koszty korzystania z proxy:

• Operator proxy widzi, o jakie silniki pyta instancja i kiedy to robi. TLS (transport layer security) chroni wyszukiwane hasła przed jego dziennikami, ponieważ zapytanie znajduje się wewnątrz zaszyfrowanego żądania, ale operator może odczytać charakter i czas ruchu.
• Współdzielony adres wyjściowy jest współdzielony z innymi osobami, które za niego płacą. Jeśli prowadzą scraping, instancja dziedziczy ich reputację, czasami szybciej niż blokada, przed którą miała się uchronić.
• Tanie pule residential proxy często są tworzone z urządzeń konsumenckich, których właściciele nie wyrazili świadomej zgody na przekazywanie ruchu. Należy wiedzieć, co jest kupowane.
• using_tor_proxy: true kieruje ruch przez Tor, ale adresy węzłów wyjściowych są publikowane w całości, a silnik, który stosuje wyzwania wobec zakresów centrów danych, zwykle co najmniej równie skutecznie stosuje je wobec węzłów wyjściowych.
• Wyszukiwanie zależy teraz od usługi znajdującej się poza serwerem. Usługa może przestać działać według własnego harmonogramu, zabierając ze sobą wyniki.

Proxy przenosi blokadę, zamiast ją usuwać, a kwestia prywatności instancji obejmuje teraz również stronę trzecią. Jeśli powodem samodzielnego hostowania jest ograniczenie ilości informacji ujawnianych o użytkowniku, przed rejestracją należy zestawić to z tym, co instancja hostowana samodzielnie rzeczywiście ukrywa, a czego nie ukrywa.

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.