SearXNG é seguro? Quem vê suas buscas

O SearXNG é seguro? A resposta curta

O SearXNG é seguro numa direção e inseguro noutra. Por isso, a pergunta «o SearXNG é seguro?» só tem resposta depois de indicar de quem pretende esconder-se. O SearXNG é um metamoto de pesquisa: recebe a sua consulta, envia-a para o Google, o Bing, o DuckDuckGo e quaisquer outros motores que tenha ativado e depois combina os resultados numa única página. Os motores veem a instância. A instância vê o utilizador.

Numa instância pública gerida por um desconhecido, essa pessoa recebe todas as consultas que introduz, em texto simples. Nada na página about pode provar o que essa pessoa faz com esses dados. No seu próprio servidor, os motores upstream veem o endereço do servidor em vez do endereço da sua casa. Essa troca é toda a história de privacidade. O seu valor depende exatamente do servidor onde o SearXNG está a executar.

Nada disto esconde as suas pesquisas da sua própria rede. O seu fornecedor de serviços de Internet (ISP) continua a ver uma ligação à instância. O seu resolvedor de DNS (domain name system) continua a ver o hostname. Tenha este limite presente ao ler o restante conteúdo.

O que o SearXNG altera numa solicitação de pesquisa

Ao pesquisar diretamente no Google, o Google recebe o seu endereço IP, os seus cookies, o cabeçalho User-Agent e a página de origem, todos associados a um perfil que sobrevive à sessão. O SearXNG fica entre o utilizador e o motor de pesquisa. A documentação descreve as duas funções que desempenha: "remover dados privados das solicitações enviadas para os serviços de pesquisa" e "gerar um perfil de navegador aleatório para cada solicitação". Os seus cookies nunca são encaminhados para um motor de pesquisa. As suas preferências ficam armazenadas no seu próprio navegador, e não numa conta no servidor.

Dois cabeçalhos de resposta são enviados por predefinição, e ambos têm uma função concreta:

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

Referrer-Policy: no-referrer significa que, quando clica num resultado, o site de destino nunca fica a saber qual foi a página de pesquisa que o encaminhou, porque o navegador omite o cabeçalho Referer. X-Robots-Tag: noindex, nofollow impede que a sua instância e as respetivas páginas de resultados sejam incluídas nos índices dos motores de pesquisa.

O que o SearXNG não altera é a própria consulta. Ela chega completa e legível à instância, porque o TLS (transport layer security) é terminado nesse ponto. Todos os pontos abaixo resultam desse facto.

Em uma instância pública, o operador vê todas as consultas

A própria documentação do projeto afirma isso claramente: os utilizadores de uma instância pública "têm de confiar no administrador dessa instância" e não podem saber "se os seus pedidos são registados, agregados e enviados ou vendidos a terceiros". Uma afirmação de ausência de logs numa página inicial continua a ser apenas uma afirmação. Do exterior, não há forma de a testar. Ou se confia, ou não.

O registo também é o caminho de menor esforço, porque a configuração padrão distribuída coloca a sua consulta no URL:

server:
  method: "GET"

Com GET, a consulta é enviada como ?q=... na linha do pedido. Qualquer reverse proxy comum grava essa linha no access log. Assim, as consultas ficam registadas sem que alguém tenha de decidir explicitamente registá-las:

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 sua própria instância, confirme:

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

As suas pesquisas aparecem nesse log porque o formato de log combined do nginx grava $request, que é a linha completa do pedido, incluindo a query string. O SearXNG não pode impedir isso. Alterar a instância para method: "POST" coloca a consulta no corpo do pedido. Assim, ela deixa de aparecer no access log e no histórico do navegador. A documentação reconhece que o POST tem desvantagens que "restringem severamente a facilidade de utilização para o utilizador final", sobretudo devido ao botão de voltar do navegador. É uma escolha consciente entre vantagens e desvantagens.

Há duas consequências para qualquer instância pública. O operador pode ler as suas consultas, mesmo que não tenha pretendido recolhê-las. Um backup ou uma intrusão permite aceder ao mesmo log.

No seu próprio VPS, os motores veem o seu servidor em vez de si

Execute a sua própria instância num VPS (servidor privado virtual). A alteração é simples de descrever. O Google deixa de receber o endereço IP da sua ligação doméstica com a consulta. Passa a receber o endereço IP do seu servidor com a consulta. Não consegue associar essa pesquisa à sua conta autenticada, ao seu telemóvel nem ao perfil de publicidade associado à ligação da sua residência. A configuração está descrita em guia para executar a sua própria instância do SearXNG num VPS.

É importante perceber o que não mudou. Os motores continuam a ver o texto da consulta, o momento em que a fez, o idioma e a região que pediu, além do padrão de tudo o que pesquisa ao longo de meses, agrupado sob um único endereço estável. Se for o único utilizador, esse endereço corresponde a uma sequência de atividade individual sem o seu nome. Para impedir esse agrupamento, a instância tem de aceder aos motores através de um proxy de saída ou do Tor. O SearXNG suporta ambas as opções, mas isso exige trabalho adicional.

O que o seu ISP, o seu resolvedor e o seu host ainda veem

Quatro observadores não são afetados por nada disso.

• O seu ISP vê uma ligação TLS para o endereço IP da sua instância e vê o nome do host no campo SNI (indicação do nome do servidor), que é enviado em texto simples durante o handshake. Não vê a consulta.
• O seu resolvedor DNS vê a consulta para esse nome do host. Monitorize-a no cliente com sudo tcpdump -ni any port 53 enquanto carrega a página, e o pedido do registo A da sua instância aparece.
• O seu provedor de VPS gere o hardware, por isso pode ler o disco e a memória da máquina virtual. A encriptação do disco dentro de uma VM alugada não elimina este acesso, porque o sistema em execução mantém a chave.
• Qualquer pessoa com root na instância vê tudo. Isso inclui você e inclui quem conseguir entrar mais tarde.

Há mais um observador que muitas pessoas esquecem. Os pedidos de saída do seu servidor são visíveis na própria rede do servidor, por isso o provedor pode ver que a sua máquina comunica com o Google e o Bing durante todo o dia. Isto é um padrão de tráfego, não uma consulta, mas ainda revela alguma informação.

É neste ponto que surge a questão da VPN. Uma VPN (rede privada virtual) transfere a perspetiva do seu ISP para a perspetiva da empresa de VPN. Não altera nada para o operador da instância nem para os motores de pesquisa, porque os motores comunicam com o seu servidor, não consigo. As duas opções são comparadas corretamente em a comparação entre uma VPS e uma VPN.

Por que o SearXNG bloqueia as suas pesquisas e o que significa realmente um 429

Dois eventos diferentes são descritos como "o SearXNG bloqueou-me", e cada um tem uma correção diferente.

O primeiro é o seu próprio limitador a responder com HTTP 429. Esta é a proteção contra bots do SearXNG e está desativada por predefinição:

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

Desde August 2026, o limitador precisa de uma base de dados Valkey e lê as regras a partir de /etc/searxng/limiter.toml. Defina também server.public_instance: true se pessoas externas realmente usarem o servidor, porque, por predefinição, está definido como false e controla o comportamento destinado ao uso público.

O limitador executa várias verificações. http_user_agent considera um User-Agent ausente, ou um User-Agent correspondente a ferramentas conhecidas como curl e wget, como um bot. http_accept considera um pedido cujo cabeçalho Accept não contenha text/html como proveniente de um bot. link_token marca um cliente como suspeito quando este nunca consulta o URL /client<token>.css que um navegador real carrega. Quando uma verificação é acionada, o SearXNG devolve 429 e escreve uma linha ERROR no logger botdetection.

Por isso, isto falha, como esperado:

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

O curl envia User-Agent: curl/8.5.0 e Accept: */*, pelo que duas verificações correspondem ao mesmo tempo. É por isso que os scripts e os agentes de IA recebem um 429 de uma instância que funciona corretamente num navegador. Este é o problema a corrigir antes de configurar a capacidade de pesquisa de um agente para usar a sua própria instância. O conjunto completo de causas e definições está em guia sobre limites de pedidos e erros 429 do SearXNG.

Há uma armadilha do limitador que merece ser destacada. Atrás de um reverse proxy, o SearXNG vê o endereço do proxy em vez do endereço do visitante, a menos que esse proxy seja confiável:

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

A lista predefinida inclui um proxy no mesmo host. Um proxy numa rede Docker separada chega a partir de um endereço como 172.18.0.5, que não está na lista. Assim, todos os visitantes são contabilizados como um único cliente, e o primeiro utilizador com muitas pesquisas bloqueia os restantes. Adicione essa sub-rede a trusted_proxies.

O segundo tipo de bloqueio ocorre a montante. Um engine pode determinar que um endereço de datacenter que executa muitas pesquisas é um scraper e deixar de responder ao seu servidor. Nesse caso, não recebe um 429. Recebe uma página de resultados sem os resultados desse engine, com uma falha registada para esse engine. Depois de falhas repetidas, o SearXNG suspende temporariamente o engine. A causa é o endereço onde o seu VPS está alojado. Por isso, as soluções são escolher outros engines e aguardar, não alterar o limitador.

Partilhar uma instância com desconhecidos ajuda ou prejudica?

As duas coisas, em sentidos opostos, e é por isso que a resposta parece difícil. O anonimato resulta do efeito de multidão. Numa instância pública movimentada, a sua consulta sai do mesmo endereço que as consultas de milhares de outras pessoas, por isso nenhum motor consegue isolá-la do conjunto. Na sua instância de utilizador único, todas as consultas desse endereço são suas, e os motores recebem um fluxo limpo de uma só pessoa, sem um nome associado.

Do lado do operador, o efeito é inverso. Uma multidão grande significa que um desconhecido guarda as consultas em texto simples dessa multidão, incluindo as suas. Na sua própria máquina, é você que guarda as suas consultas e as de mais ninguém.

Por isso, escolha com base na ameaça que realmente enfrenta. Se está preocupado com criação de perfis para publicidade e rastreamento entre sites, a multidão funciona bem e o risco do operador é reduzido. Se receia que uma pessoa ou empresa específica possa ler uma pesquisa específica que fez, a multidão não ajuda, porque o operador vê o texto original. Uma boa opção intermédia é usar uma instância para algumas pessoas que conhece. Terá uma pequena multidão e um operador que pode verificar, porque o operador é você.

Os resultados do SearXNG são melhores do que os do Google?

Não. O SearXNG não mantém um índice próprio. Por isso, todos os resultados apresentados vieram de um motor upstream, e o limite de qualidade é o limite dos motores que ativou. Se desativar o Google e o Bing, a qualidade diminui no próprio dia, porque a maior parte da cobertura geral da Web vinha deles.

O que muda é o processamento aplicado à sua pesquisa. Nenhum serviço cria um perfil publicitário a partir da consulta. Nenhum serviço reordena os resultados com base no que clicou na semana passada. Isto tem vantagens e desvantagens, porque a personalização também fornece contexto local. Uma pesquisa como "farmácia aberta agora" apresenta resultados mais fracos através do SearXNG, porque o motor não tem um sinal de localização para o seu servidor além do datacenter onde está alojado. Defina a região nas preferências quando os resultados locais forem importantes.

Duas definições determinam quanto a sua instância expõe enquanto consulta esses resultados. image_proxy é false por predefinição. Assim, as miniaturas são carregadas diretamente dos sites que as alojam, e esses sites veem o endereço do seu navegador. Definir image_proxy: true encaminha as miniaturas através da instância, à custa de largura de banda e memória. Além disso, formats é fornecido apenas como html. Por isso, um pedido JSON (JavaScript object notation) é recusado com 403 Forbidden:

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

Ative json numa instância pública e terá publicado uma API de scraping gratuita. Esta é a forma mais rápida de fazer com que os motores de pesquisa de que depende bloqueiem o endereço do seu servidor. Mantenha-a desativada ou proteja-a com autenticação.

Onde termina a privacidade do SearXNG

O SearXNG oculta dos motores de pesquisa quem está a fazer a consulta. Não oculta da sua rede o que está a fazer. Daqui resultam quatro limites.

• O seu tráfego não muda em nenhum outro ponto além da caixa de pesquisa. Tudo o que a máquina fizer continua a sair da sua rede exatamente como antes.
• Um utilizador num servidor é um identificador estável para todos os motores. O identificador não inclui um nome, e esse é todo o benefício.
• O operador de qualquer instância lê a consulta em texto simples. Ser o próprio operador é a única versão desta afirmação que pode verificar.
• Os seus próprios logs de acesso reconstroem o registo que estava a tentar evitar. Leia-os e mude para method: "POST" se preferir mantê-los vazios.

O SearXNG muda o observador. Não elimina a observação. Decida qual observador quer evitar, escolha a instância correspondente e não trate uma interface de pesquisa como software de anonimato.

FAQ

É seguro usar o SearXNG numa instância pública?

É seguro em relação aos motores de pesquisa, mas não em relação ao operador. A sua consulta chega a esse servidor em texto simples, e a documentação do projeto afirma que os utilizadores "têm de confiar no administrador dessa instância" e não podem saber "se os seus pedidos são registados, agregados e enviados ou vendidos a terceiros". Com a predefinição fornecida de method: "GET", a consulta também fica no log de acesso do reverse proxy como parte da linha do pedido, quer o operador o pretenda ou não. Use uma instância pública para pesquisas comuns quando a preocupação for a criação de perfis para publicidade. Não introduza nela nada que não entregasse ao respetivo proprietário.

O SearXNG oculta as minhas pesquisas do fornecedor de Internet?

O texto da consulta fica oculto. A atividade, não. O fornecedor vê uma ligação TLS para o endereço da instância e o hostname no campo SNI em texto simples do handshake, e o resolvedor DNS vê a consulta desse hostname. Nenhum dos dois vê o que pesquisou, porque a ligação é encriptada. O SearXNG não é uma VPN e não protege nada mais do que a sua máquina faça.

Porque é que o SearXNG devolve um erro 429?

O 429 vem do limitador da própria instância. Trata-se de proteção contra bots, não de uma mensagem do Google. As sondas assinalam um pedido cujo cabeçalho Accept não contém text/html e cujo User-Agent não está definido ou corresponde a ferramentas como curl e wget. Uma terceira sonda, o token de ligação, assinala um cliente que nunca obtém o URL /client<token>.css que um navegador carrega. Quando um reverse proxy não está incluído em trusted_proxies de /etc/searxng/limiter.toml, todos os visitantes são contabilizados como um único cliente. Assim, um utilizador com muita atividade bloqueia os restantes. Quando um motor upstream bloqueia o seu servidor, os resultados desse motor simplesmente deixam de aparecer na página e não recebe qualquer 429.

Alojar o SearXNG por conta própria piora os meus resultados de pesquisa?

Por vezes, por dois motivos importantes. Os resultados vêm de motores upstream. Por isso, se esses motores limitarem um endereço de datacenter, haverá menos motores a responder e a página será menos completa. Além disso, deixa de existir a ordenação personalizada. Isto elimina a reordenação orientada por publicidade, mas também remove a intenção local. Assim, as pesquisas sensíveis à localização devolvem respostas menos relevantes até definir a sua região nas preferências.