Czy SearXNG jest bezpieczny? Analiza prywatności

Czy SearXNG jest bezpieczny? Krótka odpowiedź

SearXNG jest bezpieczny w jednym aspekcie, a niebezpieczny w innym, dlatego pytanie „czy SearXNG jest bezpieczny” ma sens tylko wtedy, gdy określisz, przed kim chcesz się ukryć. SearXNG to metawyszukiwarka: pobiera zapytanie, wysyła je do Google, Bing, DuckDuckGo oraz innych włączonych wyszukiwarek, a następnie łączy wyniki na jednej stronie. Wyszukiwarki widzą instancję. Instancja widzi Ciebie.

W przypadku publicznej instancji prowadzonej przez nieznajomą osobę, administrator otrzymuje każde wpisane zapytanie w postaci czystego tekstu, a żadna informacja na stronie „o nas” nie stanowi dowodu na to, co jest z tymi danymi robione. Na własnym serwerze wyszukiwarki widzą adres Twojego serwera zamiast adresu domowego. Ta zamiana stanowi istotę prywatności i jest warta dokładnie tyle, co serwer, na którym uruchomiono usługę.

Żaden z tych mechanizmów nie ukrywa wyszukiwań przed własną siecią. Twój dostawca usług internetowych (ISP) nadal widzi połączenie z instancją. Twój resolver DNS (Domain Name System) nadal widzi nazwę hosta. Pamiętaj o tej granicy podczas czytania dalszej części.

Jak SearXNG zmienia żądanie wyszukiwania

Wyszukiwanie bezpośrednio w Google powoduje, że Google otrzymuje adres IP, pliki cookie, nagłówek User-Agent oraz adres strony, z której nastąpiło przejście. Wszystkie te dane są przypisywane do profilu, który istnieje dłużej niż pojedyncza sesja. SearXNG działa jako pośrednik. Dokumentacja wskazuje na dwa główne działania: „usuwanie danych prywatnych z żądań wysyłanych do usług wyszukiwania” oraz „generowanie losowego profilu przeglądarki dla każdego żądania”. Pliki cookie nigdy nie są przekazywane do wyszukiwarki. Preferencje użytkownika są przechowywane w jego przeglądarce, a nie na koncie na serwerze.

Domyślnie wysyłane są dwa nagłówki odpowiedzi, z których oba pełnią istotną funkcję:

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

Referrer-Policy: no-referrer oznacza, że po kliknięciu wyniku docelowa witryna nigdy nie otrzymuje informacji, z której strony wyszukiwania nastąpiło przejście, ponieważ przeglądarka pomija nagłówek Referer. X-Robots-Tag: noindex, nofollow chroni instancję oraz jej strony z wynikami przed indeksowaniem przez wyszukiwarki.

SearXNG nie zmienia samego zapytania. Dociera ono do instancji w formie pełnej i czytelnej, ponieważ to tam następuje terminacja TLS (transport layer security). Każdy z poniższych punktów wynika bezpośrednio z tego faktu.

W publicznej instancji operator widzi każde zapytanie

Własna dokumentacja projektu stwierdza to jasno: użytkownicy publicznej instancji „muszą ufać administratorowi tej instancji” i nie mogą wiedzieć, „czy ich żądania są rejestrowane, agregowane oraz wysyłane lub sprzedawane stronie trzeciej”. Deklaracja braku logów na stronie docelowej pozostaje tylko deklaracją. Z zewnątrz nie można jej zweryfikować, więc pozostaje zaufanie albo jego brak. Niektóre publiczne instancje nadal uruchamiają oryginalny Searx zamiast tego forka. Ma to znaczenie, ponieważ Searx nie otrzymał żadnego zatwierdzenia kodu od 2023 roku, a nieutrzymywane oprogramowanie wyszukiwarki jest kolejnym elementem, któremu trzeba ufać bez możliwości weryfikacji.

Logowanie jest również ścieżką najmniejszego oporu, ponieważ domyślna konfiguracja umieszcza zapytanie w adresie URL:

server:
  method: "GET"

W przypadku GET zapytanie przesyłane jest jako ?q=... w linii żądania. Każdy standardowy reverse proxy zapisuje tę linię żądania w swoim logu dostępu, więc zapytania są rejestrowane bez konieczności podejmowania przez kogokolwiek decyzji o ich zapisie:

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)"

Na własnej instancji sprawdź to samodzielnie:

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

Twoje wyszukiwania znajdują się w tym pliku, ponieważ format logów combined serwera nginx zapisuje $request, czyli pełną linię żądania wraz z ciągiem zapytania. SearXNG nie ma na to żadnego wpływu. Przełączenie instancji na method: "POST" przenosi zapytanie do treści żądania (request body), dzięki czemu przestaje ono pojawiać się w logu dostępu oraz w historii przeglądarki. Dokumentacja uczciwie wskazuje, że metoda POST ma wady, które „znacząco ograniczają wygodę użytkowania dla użytkownika końcowego”, głównie w odniesieniu do przycisku wstecz w przeglądarce. Jest to kompromis, na który decydujesz się świadomie.

Dla każdej publicznej instancji wynikają z tego dwie konsekwencje. Operator może odczytać Twoje zapytania niezależnie od tego, czy zamierzał je gromadzić, czy nie. Kopia zapasowa lub włamanie do serwera dają dostęp do tych samych logów.

Na własnym VPS wyszukiwarki widzą serwer, a nie użytkownika

Uruchomienie własnej instancji na VPS (virtual private server) zmienia sytuację w prosty sposób. Google nie otrzymuje już adresu IP Twojego domu wraz z zapytaniem. Otrzymuje adres IP Twojego serwera. Nie może powiązać tego wyszukiwania z zalogowanym kontem, telefonem ani profilem reklamowym przypisanym do domowego łącza. Proces budowy opisano w przewodniku uruchamiania własnej instancji SearXNG na VPS.

Należy jasno określić, co się nie zmieniło. Wyszukiwarki nadal widzą treść zapytania, czas jego wysłania, język, region oraz profil wszystkich wyszukiwań z wielu miesięcy, zgrupowane pod jednym stałym adresem. Jeśli jesteś jedynym użytkownikiem, adres ten stanowi strumień danych przypisany do jednej osoby, choć niepodpisany imieniem i nazwiskiem. Przerwanie tego grupowania wymaga, aby instancja łączyła się z wyszukiwarkami przez zewnętrzny proxy lub sieć Tor, co SearXNG obsługuje, lecz stanowi osobne zagadnienie techniczne.

Co nadal widzą dostawca usług internetowych, resolver i host

Czterech obserwatorów pozostaje poza wpływem powyższych rozwiązań.

• Dostawca usług internetowych (ISP) widzi połączenie TLS z adresem IP instancji oraz nazwę hosta w polu SNI (Server Name Indication), przesyłanym otwartym tekstem podczas nawiązywania połączenia. Nie widzi jednak samego zapytania.
• Resolver DNS widzi zapytanie o tę nazwę hosta. Można monitorować to na kliencie za pomocą sudo tcpdump -ni any port 53 podczas ładowania strony; pojawi się tam żądanie rekordu A dla instancji.
• Dostawca VPS zarządza sprzętem, więc ma dostęp do odczytu dysku i pamięci maszyny wirtualnej. Szyfrowanie dysku wewnątrz wynajmowanej maszyny wirtualnej nie eliminuje tego ryzyka, ponieważ działający system przechowuje klucz.
• Każdy użytkownik z uprawnieniami root na instancji widzi wszystko. Dotyczy to administratora oraz każdego, kto uzyska nieautoryzowany dostęp w przyszłości.

Dostęp do instancji jako usługa Tor onion eliminuje pierwsze dwa punkty, ponieważ nie istnieje publiczna nazwa hosta do rozwiązania ani pole SNI do odczytania. W instrukcji dodawania usługi v3 onion do VPS opisano konfigurację oraz wycieki, które w przeciwnym razie mogłyby powiązać ten adres z publicznym adresem IP serwera.

Istnieje jeszcze jeden aspekt, o którym często się zapomina. Wychodzące żądania serwera są widoczne z poziomu jego sieci, więc dostawca może zaobserwować, że maszyna nieustannie komunikuje się z Google i Bing. Jest to wzorzec ruchu, a nie zapytanie, który również dostarcza pewnych informacji.

W tym miejscu pojawia się kwestia VPN. VPN (Virtual Private Network) przenosi perspektywę dostawcy usług internetowych na firmę oferującą VPN. Nie zmienia to niczego w relacji z operatorem instancji ani z wyszukiwarkami, ponieważ to one komunikują się z serwerem, a nie z użytkownikiem. Porównanie obu rozwiązań znajduje się w analizie porównawczej VPS i VPN.

Dlaczego SearXNG blokuje dostęp i co w rzeczywistości oznacza błąd 429

Dwa różne zdarzenia są określane mianem „SearXNG mnie zablokował”, jednak wymagają one odmiennych działań naprawczych.

Pierwszym z nich jest odpowiedź własnego limitera serwera z kodem HTTP 429. Jest to mechanizm ochrony przed botami wbudowany w SearXNG, domyślnie wyłączony:

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

Od sierpnia 2026 roku limiter wymaga bazy danych Valkey i odczytuje reguły z pliku /etc/searxng/limiter.toml. Należy również skonfigurować server.public_instance: true, jeśli z instancji korzystają osoby trzecie, ponieważ domyślnie ustawiona jest wartość false, która ogranicza zachowania przeznaczone do użytku publicznego.

Limiter przeprowadza kilka testów. http_user_agent traktuje brak nagłówka User-Agent lub nagłówek pasujący do znanych narzędzi, takich jak curl czy wget, jako bota. http_accept uznaje za bota żądanie, którego nagłówek Accept nie zawiera text/html. link_token oznacza klienta jako podejrzanego, jeśli nigdy nie pobiera adresu URL /client<token>.css, który jest ładowany przez każdą prawdziwą przeglądarkę. Gdy test wykaże naruszenie, SearXNG zwraca błąd 429 i zapisuje linię ERROR w logu botdetection.

Dlatego poniższe polecenie kończy się niepowodzeniem, co jest zachowaniem zamierzonym:

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

Narzędzie curl wysyła User-Agent: curl/8.5.0 oraz Accept: */*, więc dwa testy zostają uruchomione jednocześnie. To powód, dla którego skrypty i agenci AI otrzymują błąd 429 z instancji, która działa poprawnie w przeglądarce. Jest to kwestia, którą należy rozwiązać przed skierowaniem funkcji wyszukiwania agenta na własną instancję. Pełny zestaw przyczyn i ustawień znajduje się w przewodniku dotyczącym limitów SearXNG i błędów 429.

Jedna pułapka limitera wymaga szczególnej uwagi. Za reverse proxy SearXNG widzi adres proxy, a nie adres odwiedzającego, chyba że proxy jest zaufane:

[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 = []

Domyślna lista obejmuje proxy działające na tym samym hoście. Proxy w oddzielnej sieci Docker łączy się z adresu typu 172.18.0.5, który nie znajduje się na liście. W rezultacie każdy odwiedzający jest liczony jako jeden klient, a pierwszy aktywny użytkownik blokuje dostęp wszystkim pozostałym. Należy dodać tę podsieć do trusted_proxies.

Drugi rodzaj blokady występuje po stronie dostawcy zewnętrznego. Wyszukiwarka uznaje, że adres IP centrum danych, z którego pochodzi wiele zapytań, należy do skrapera i przestaje odpowiadać na zapytania serwera. W takim przypadku nie otrzymuje się błędu 429. Zamiast tego strona z wynikami nie zawiera danych z danej wyszukiwarki, a przy jej nazwie widnieje informacja o błędzie. Po wielokrotnych niepowodzeniach SearXNG tymczasowo zawiesi daną wyszukiwarkę. Przyczyną jest adres IP, na którym znajduje się VPS, więc rozwiązaniem jest zmiana wyszukiwarek lub cierpliwość, a nie modyfikacja ustawień limitera.

Czy współdzielenie instancji z nieznajomymi pomaga czy szkodzi?

Oba te zjawiska występują jednocześnie, co sprawia, że odpowiedź wydaje się niejednoznaczna. Anonimowość jest efektem skali. Na popularnej publicznej instancji zapytanie pochodzi z tego samego adresu, co zapytania tysięcy innych osób, więc żaden silnik nie jest w stanie wyodrębnić go z tłumu. W przypadku instancji jednoosobowej każde zapytanie z tego adresu należy do użytkownika, a silniki otrzymują czysty strumień danych od jednej osoby, bez przypisanej tożsamości.

Z perspektywy operatora sytuacja wygląda odwrotnie. Duża grupa użytkowników oznacza, że obca osoba ma dostęp do zapytań tekstowych całego tłumu, w tym Twoich. Własny serwer oznacza, że posiadasz dostęp do własnych zapytań i nikogo więcej.

Wybór zależy od realnego zagrożenia. Obawiasz się profilowania reklamowego i śledzenia między witrynami? Tłum dobrze radzi sobie z tym problemem, a ryzyko związane z operatorem jest niewielkie. Obawiasz się, że konkretna osoba lub firma może odczytać konkretne wyszukiwanie? Tłum w niczym nie pomaga, ponieważ operator widzi tekst jawny. Dobrym rozwiązaniem pośrednim jest instancja dla kilku znanych osób. Zyskujesz niewielką grupę użytkowników oraz operatora, którego możesz zweryfikować, ponieważ operatorem jesteś Ty sam.

Czy wyniki SearXNG są lepsze niż Google?

Nie. SearXNG nie posiada własnego indeksu, więc każdy wynik na stronie pochodzi z zewnętrznej wyszukiwarki, a maksymalna jakość wyników jest ograniczona przez możliwości włączonych silników. Wyłączenie Google i Bing spowoduje natychmiastowy spadek jakości, ponieważ większość pokrycia ogólnego zasobów sieci pochodzi właśnie z tych źródeł.

Zmienia się natomiast sposób przetwarzania danych użytkownika. Żaden mechanizm nie buduje profilu reklamowego na podstawie zapytania i nic nie zmienia kolejności wyników w oparciu o historię kliknięć. Działa to w obie strony, ponieważ personalizacja uwzględnia również intencje lokalne. Wyszukiwanie typu "apteka otwarta teraz" zwraca słabsze wyniki w SearXNG, ponieważ silnik nie posiada informacji o lokalizacji serwera poza danymi centrum danych, w którym się znajduje. Warto ustawić region w preferencjach, gdy wyniki lokalne są istotne.

Dwa ustawienia decydują o tym, jak dużo danych wycieka z instancji podczas przeglądania wyników. image_proxy jest domyślnie ustawione na false, więc miniatury ładują się bezpośrednio ze stron, na których są hostowane, a te strony widzą adres IP przeglądarki użytkownika. Ustawienie image_proxy: true kieruje je przez instancję, co wiąże się z wyższym zużyciem pasma i pamięci. Ponadto formats jest domyślnie ustawione tylko na html, więc żądania JSON (JavaScript object notation) są odrzucane z błędem 403 Forbidden:

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

Włączenie json na publicznej instancji oznacza udostępnienie darmowego API do scrapowania, co jest najszybszą drogą do zablokowania adresu IP serwera przez wyszukiwarki, od których zależy działanie usługi. Należy pozostawić tę opcję wyłączoną lub zabezpieczyć ją uwierzytelnianiem.

Gdzie kończy się prywatność SearXNG

SearXNG ukrywa przed wyszukiwarkami tożsamość użytkownika. Nie ukrywa jednak przed siecią tego, co użytkownik robi. Z tego wynikają cztery ograniczenia.

• Ruch sieciowy pozostaje niezmieniony wszędzie poza samym polem wyszukiwania. Wszystkie pozostałe działania maszyny opuszczają sieć w niezmienionej formie.
• Jeden użytkownik na jednym serwerze stanowi stały identyfikator dla każdej wyszukiwarki. Identyfikator ten nie zawiera imienia ani nazwiska i na tym polega cała korzyść.
• Operator każdej instancji odczytuje zapytania jako tekst jawny. Samodzielne prowadzenie instancji to jedyny sposób, aby to zweryfikować.
• Własne logi dostępu odtwarzają historię, której użytkownik starał się uniknąć. Należy je przeglądać i przejść na method: "POST", jeśli logi mają pozostać puste.

SearXNG zmienia obserwatora. Nie eliminuje jednak obserwacji. Należy zdecydować, który obserwator jest akceptowalny, wybrać odpowiednią instancję i nie traktować interfejsu wyszukiwania jako oprogramowania zapewniającego anonimowość.

FAQ

Czy korzystanie z SearXNG na publicznej instancji jest bezpieczne?

Jest to bezpieczne z punktu widzenia wyszukiwarek, lecz niebezpieczne z punktu widzenia operatora. Zapytanie dociera do serwera jako czysty tekst, a dokumentacja projektu wskazuje, że użytkownicy „muszą ufać administratorowi instancji” i nie mogą wiedzieć, „czy ich zapytania są logowane, agregowane oraz wysyłane lub sprzedawane podmiotom trzecim”. Przy domyślnej konfiguracji method: "GET" zapytanie trafia również do logów dostępu reverse proxy jako część linii żądania, niezależnie od intencji operatora. Publicznych instancji należy używać do zwykłego wyszukiwania, gdzie głównym zagrożeniem jest profilowanie reklamowe. Nie należy wpisywać w nich niczego, czego nie powierzyłoby się bezpośrednio właścicielowi serwera.

Czy SearXNG ukrywa moje wyszukiwania przed dostawcą Internetu?

Treść zapytania jest ukryta. Aktywność użytkownika nie. Dostawca widzi połączenie TLS z adresem instancji oraz nazwę hosta w jawnym polu SNI podczas nawiązywania połączenia, a serwer DNS widzi zapytanie o tę nazwę hosta. Żaden z nich nie widzi treści wyszukiwania, ponieważ połączenie jest szyfrowane. SearXNG nie jest VPN-em i nie zapewnia ochrony dla żadnej innej aktywności urządzenia.

Dlaczego SearXNG zwraca błąd 429?

Błąd 429 pochodzi z wbudowanego mechanizmu ograniczania liczby żądań (limiter) instancji i stanowi ochronę przed botami, a nie komunikat od Google. Mechanizmy sprawdzające oznaczają żądanie, w którym nagłówek Accept nie zawiera text/html, a User-Agent jest nieustawiony lub pasuje do narzędzi takich jak curl i wget. Trzeci test, token linku, oznacza klienta, który nigdy nie pobiera adresu URL /client<token>.css ładowanego przez przeglądarkę. W przypadku działania za reverse proxy, którego brakuje w trusted_proxies w pliku /etc/searxng/limiter.toml, każdy odwiedzający jest liczony jako jeden klient, więc jeden aktywny użytkownik blokuje pozostałych. Gdy to zewnętrzna wyszukiwarka blokuje serwer, jej wyniki po prostu znikają ze strony, a użytkownik nie otrzymuje błędu 429.

Czy samodzielne hostowanie SearXNG pogarsza jakość wyników wyszukiwania?

Czasami tak, z dwóch powodów. Wyniki pochodzą z zewnętrznych wyszukiwarek, więc adres IP centrum danych, który jest przez nie ograniczany, oznacza mniejszą liczbę odpowiadających silników i uboższą stronę wyników. Ponadto znika personalizacja rankingu, co eliminuje sortowanie oparte na reklamach, ale również usuwa kontekst lokalny. W rezultacie wyszukiwania zależne od lokalizacji zwracają słabsze odpowiedzi, dopóki region nie zostanie ustawiony w preferencjach.