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” zyskuje odpowiedź dopiero po określeniu, przed kim użytkownik chce się ukryć. SearXNG to metawyszukiwarka: pobiera zapytanie, wysyła je do Google, Bing, DuckDuckGo oraz innych włączonych wyszukiwarek, a następnie łączy otrzymane wyniki na jednej stronie. Wyszukiwarki widzą instancję. Instancja widzi użytkownika.

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 nadrzędne widzą adres serwera zamiast adresu domowego użytkownika. Ta zamiana stanowi istotę prywatności i jest warta dokładnie tyle, co serwer, na którym działa oprogramowanie.

Żaden z tych elementów nie ukrywa wyszukiwań przed własną siecią. Dostawca usług internetowych (ISP) nadal widzi połączenie z instancją. Resolver DNS (Domain Name System) nadal widzi nazwę hosta. Należy pamiętać o tej granicy podczas czytania dalszej części materiału.

Jak SearXNG zmienia zapytanie wyszukiwania

Bezpośrednie wyszukiwanie 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 zadania: „usuwanie danych prywatnych z zapytań wysyłanych do usług wyszukiwania” oraz „generowanie losowego profilu przeglądarki dla każdego zapytania”. 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 dowiaduje się, która strona wyszukiwania wysłała użytkownika, 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 pełnej i czytelnej formie, ponieważ to właśnie tam następuje terminacja TLS (transport layer security). Każdy z poniższych punktów wynika bezpośrednio z tego faktu.

W instancji publicznej operator widzi każde zapytanie

Dokumentacja projektu stwierdza to wprost: użytkownicy instancji publicznej „muszą zaufać administratorowi tej instancji” i nie mogą wiedzieć, „czy ich zapytania są logowane, agregowane oraz wysyłane lub sprzedawane podmiotom trzecim”. Deklaracja braku logów na stronie głównej to tylko deklaracja. Z zewnątrz nie da się jej zweryfikować, więc pozostaje albo zaufanie, albo rezygnacja.

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

We 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 w 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, 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 zakresie działania 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 pozostaje bez zmian. Wyszukiwarki nadal widzą treść zapytania, czas jego wysłania, język, region oraz wzorce wyszukiwania gromadzone przez miesiące, a wszystko to przypisane do jednego, stałego adresu. Jeśli jesteś jedynym użytkownikiem, adres ten stanowi strumień danych przypisany do konkretnej osoby, choć nieposiadający imienia. Przerwanie tego grupowania wymaga, aby instancja łączyła się z wyszukiwarkami przez zewnętrzny proxy lub sieć Tor, co SearXNG obsługuje, lecz stanowi odrębne zagadnienie techniczne.

Co nadal widzi dostawca usług internetowych, resolver oraz host

Czterech obserwatorów pozostaje poza wpływem tych działań.

• Twój dostawca usług internetowych (ISP) widzi połączenie TLS z adresem IP Twojej instancji oraz nazwę hosta w polu SNI (server name indication), które jest przesyłane otwartym tekstem podczas nawiązywania połączenia. Nie widzi on jednak samego zapytania.
• Twój resolver DNS widzi zapytanie o tę nazwę hosta. Monitoruj je na kliencie za pomocą sudo tcpdump -ni any port 53 podczas ładowania strony, a zobaczysz żądanie rekordu A dla Twojej instancji.
• Twój dostawca VPS zarządza sprzętem, więc może odczytać zawartość dysku oraz pamięci maszyny wirtualnej. Szyfrowanie dysku wewnątrz wynajmowanej maszyny wirtualnej nie eliminuje tego ryzyka, ponieważ działający system przechowuje klucz.
• Każdy, kto posiada uprawnienia root na instancji, widzi wszystko. Dotyczy to Ciebie oraz każdego, kto uzyska dostęp w przyszłości.

Istnieje jeszcze jeden aspekt, o którym często się zapomina. Wychodzące żądania z Twojego serwera są widoczne z poziomu sieci, w której działa serwer, więc dostawca może zauważyć, że Twoja maszyna przez cały dzień komunikuje się z Google i Bing. Jest to wzorzec ruchu, a nie konkretne zapytanie, jednak nadal dostarcza pewnych informacji.

W tym miejscu pojawia się kwestia VPN. Sieć VPN (virtual private network) przenosi punkt widzenia Twojego dostawcy ISP na firmę oferującą VPN. Nie zmienia to nic w kwestii operatora instancji ani wyszukiwarek, ponieważ wyszukiwarki komunikują się z Twoim serwerem, a nie z Tobą. Obie te kwestie zostały szczegółowo porównane w zestawieniu VPS kontra 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ł”, a każde z nich wymaga innego rozwiązania.

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 swoje 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 i 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 ładuje każda prawdziwa przeglądarka. Gdy test wykaże naruszenie, SearXNG zwraca kod 429 i zapisuje linię ERROR w swoim loggerze 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 są uruchamiane jednocześnie. To właśnie dlatego 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 po limitach zapytań i błędach 429 w SearXNG.

Jedna pułapka związana z limiterem 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. Ruch z proxy w oddzielnej sieci Docker pochodzi z adresu takiego jak 172.18.0.5, który nie znajduje się na liście. W rezultacie wszyscy odwiedzający są liczeni 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 skanera (scraping) i przestaje odpowiadać na zapytania serwera. W takim przypadku nie otrzymuje się błędu 429. Użytkownik widzi stronę wyników, na której brakuje danych z danej wyszukiwarki, a przy niej odnotowany jest błąd. SearXNG zawiesi działanie tej wyszukiwarki na pewien czas po wielokrotnych niepowodzeniach. 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, w przeciwnych kierunkach, dlatego odpowiedź wydaje się niejednoznaczna. Anonimowość jest efektem tłumu. Na popularnej instancji publicznej zapytanie użytkownika wychodzi z tego samego adresu, co zapytania tysięcy innych osób, więc żaden silnik nie jest w stanie wyodrębnić konkretnego użytkownika z tej grupy. W przypadku instancji jednoosobowej każde zapytanie z tego adresu należy do właściciela, a silniki otrzymują czysty strumień danych od jednej osoby, bez przypisanej nazwy.

Z perspektywy operatora sytuacja wygląda odwrotnie. Duża grupa oznacza, że obca osoba ma dostęp do zapytań w formie tekstowej, w tym do zapytań użytkownika. Własny serwer oznacza, że użytkownik zarządza własnymi zapytaniami i nikt inny nie ma do nich wglądu.

Należy zatem dokonać wyboru w oparciu o realne zagrożenie. Czy 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. Czy obawiasz się, że konkretna osoba lub firma może odczytać konkretne wyszukiwanie? Tłum w tym przypadku w ogóle nie pomaga, ponieważ operator widzi surowy tekst. Dobrym rozwiązaniem pośrednim jest instancja dla kilku znanych osób. Zapewnia to niewielką grupę oraz operatora, którego można zweryfikować, ponieważ jest nim sam użytkownik.

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 poziom jakości jest ograniczony przez możliwości włączonych silników. Wyłączenie Google i Bing powoduje natychmiastowy spadek jakości, ponieważ większość wyników dla ogólnego internetu pochodzi właśnie z tych źródeł.

Zmienia się natomiast sposób przetwarzania danych użytkownika. Żaden mechanizm nie tworzy profilu reklamowego na podstawie zapytania ani nie zmienia kolejności wyników w oparciu o historię kliknięć. Działa to w obie strony, ponieważ personalizacja uwzględnia również lokalne intencje. Wyszukiwanie typu "apteka otwarta teraz" daje słabsze rezultaty 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 istotne są wyniki lokalne.

Dwa ustawienia decydują o tym, ile 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 większym zużyciem pasma i pamięci. Z kolei 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 najszybszym sposobem na zablokowanie 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ść w SearXNG

SearXNG ukrywa przed wyszukiwarkami tożsamość osoby zadającej pytanie. Nie ukrywa jednak przed siecią tego, co użytkownik robi. Wynikają z tego cztery ograniczenia.

• Ruch sieciowy pozostaje niezmieniony wszędzie poza samym polem wyszukiwania. Wszystkie inne 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 zapytanie jako zwykły tekst. Samodzielne prowadzenie instancji to jedyny wariant, który można zweryfikować.
• Własne logi dostępu odtwarzają historię, której użytkownik starał się uniknąć. Należy je monitorować i przejść na method: "POST", jeśli logi mają pozostać puste.

SearXNG przesuwa punkt obserwacji. Nie eliminuje samej 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 publicznej instancji SearXNG jest bezpieczne?

Jest bezpieczne w relacji z wyszukiwarkami, ale nie w relacji z operatorem instancji. Zapytanie dociera do serwera jako tekst jawny, a dokumentacja projektu wskazuje, że użytkownicy „muszą ufać administratorowi danej instancji” i nie mają możliwości sprawdzenia, „czy ich zapytania są logowane, agregowane, 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 typowego wyszukiwania, gdy głównym zagrożeniem jest profilowanie reklamowe. Nie należy wpisywać w nich żadnych danych, których nie przekazałoby się bezpośrednio właścicielowi serwera.

Czy SearXNG ukrywa moje wyszukiwania przed dostawcą internetu?

Treść zapytania jest ukryta, ale sama aktywność 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 zabezpieczenie przed botami, a nie komunikat od Google. Mechanizmy sprawdzające oznaczają żądanie jako podejrzane, jeśli nagłówek Accept nie zawiera text/html, a User-Agent jest nieustawiony lub pasuje do narzędzi takich jak curl czy wget. Trzeci mechanizm, token linku, oznacza klienta, który nigdy nie pobiera adresu URL /client<token>.css, ładowanego standardowo przez przeglądarkę. Jeśli za reverse proxy brakuje wpisu 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, wyniki z tego silnika po prostu znikają ze strony, a błąd 429 nie występuje.

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

Czasami tak, z dwóch powodów. Wyniki pochodzą z zewnętrznych silników, 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 także usuwa kontekst lokalny, przez co wyszukiwania zależne od lokalizacji zwracają mniej trafne odpowiedzi, dopóki region nie zostanie ustawiony w preferencjach.