SearXNG e privacidade: quem vê suas pesquisas?

O SearXNG é seguro? A resposta curta

O SearXNG é seguro num sentido e inseguro noutro. Por isso, a pergunta «o SearXNG é seguro?» só tem resposta depois de indicar de quem está a tentar ocultar a sua atividade. O SearXNG é um motor de metapesquisa: recebe a sua consulta, envia-a para o Google, Bing, DuckDuckGo e quaisquer outros motores que tenha ativado e combina as respostas numa única página de resultados. Os motores veem a instância. A instância vê quem fez a consulta.

Numa instância pública administrada por um desconhecido, essa pessoa recebe todas as consultas que escreve, em texto simples. Nada na página de informações da instância consegue 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 resume toda a questão da privacidade e vale exatamente tanto quanto o servidor onde a instância é executada.

Isto não oculta 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 DNS (domain name system) continua a ver o nome do host. Tenha este limite presente ao ler o restante conteúdo.

O que o SearXNG altera num pedido 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 si e o motor de pesquisa. A documentação descreve as duas funções que desempenha: «remover dados privados dos pedidos enviados para serviços de pesquisa» e «gerar um perfil de navegador aleatório para cada pedido». Os seus cookies nunca são encaminhados para um motor. 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 efetiva:

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 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 nessa instância. Todos os pontos abaixo resultam desse facto.

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

A documentação do próprio projeto é clara: 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 declaração de ausência de registos numa página inicial continua a ser apenas uma declaração. Do exterior, não há forma de a testar. Ou se confia, ou nada feito. Algumas instâncias públicas também continuam a executar o Searx original em vez deste fork. Isto é relevante porque o Searx não recebe commits de código desde 2023 e software de pesquisa sem manutenção é mais um componente em que teria de confiar sem possibilidade de verificação.

O registo também é o caminho de menor esforço, porque o valor predefinido distribuído coloca a sua consulta no URL:

server:
  method: "GET"

Com GET, a consulta segue como ?q=... na linha do pedido. Qualquer reverse proxy comum escreve essa linha no access log. Assim, as consultas ficam registadas sem que alguém precise de decidir 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 estão lá porque o formato de log combined do nginx escreve $request, que é a linha completa do pedido, incluindo a query string. O SearXNG não tem qualquer controlo sobre isso. Mudar 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 browser. A documentação afirma claramente que o POST tem desvantagens que "restringem severamente a facilidade de utilização para o utilizador final", sobretudo relacionadas com o botão Voltar do browser. É uma decisão consciente com custos e benefícios.

Isto tem duas consequências para qualquer instância pública. O operador pode ler as suas consultas, mesmo que não tenha intenção de as recolher. Uma cópia de segurança ou uma intrusão permite aceder ao mesmo log.

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

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

É importante esclarecer o que não mudou. Os mecanismos continuam a ver o texto da consulta, o momento em que a fez, o idioma e a região solicitados e o padrão de tudo o que pesquisa ao longo de meses, sempre associado ao mesmo endereço estável. Se for o único utilizador, esse endereço representa um fluxo por pessoa sem um nome associado. Para impedir essa associação, a instância tem de aceder aos mecanismos através de um proxy de saída ou do Tor. O SearXNG suporta ambas as opções, mas isso requer trabalho separado.

O que o seu ISP, o seu resolver e o seu host ainda conseguem ver

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 resolver DNS vê a pesquisa por esse nome do host. Monitorize-a no cliente com sudo tcpdump -ni any port 53 enquanto carrega a página, e verá aparecer o pedido do registo A para a sua instância.
• O seu fornecedor 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 qualquer pessoa que consiga entrar mais tarde.

Aceder à instância como um serviço onion do Tor elimina os dois primeiros pontos, porque deixa de existir um nome do host público para resolver e um campo SNI para ler. O guia para adicionar um serviço onion v3 a uma VPS explica a configuração e os leaks que, de outro modo, associariam esse endereço ao IP público do seu servidor.

Há ainda outro ponto que é frequentemente esquecido. Os pedidos de saída do seu servidor são visíveis a partir da própria rede do servidor. Por isso, o seu fornecedor pode ver que a sua máquina comunica com o Google e o Bing durante todo o dia. Isso é um padrão de tráfego, não uma consulta, mas continua a revelar informação.

É aqui que surge a questão da VPN. Uma VPN (rede privada virtual) transfere a visão do seu ISP para a visão 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, e não consigo. Os dois casos são comparados corretamente em A comparação entre uma VPS e uma VPN.

Por que o SearXNG bloqueia os pedidos 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

Em agosto de 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 utilizarem o servidor, porque, por predefinição, é 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 sendo de um bot. http_accept considera que um pedido é de um bot quando o cabeçalho Accept não contém text/html. link_token marca um cliente como suspeito quando este nunca obtém 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 seu 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: */*, por isso duas verificações são correspondidas ao mesmo tempo. É por isso que scripts e agentes de IA recebem um 429 de uma instância que funciona normalmente num navegador. Este é o problema a corrigir antes de apontar a capacidade de pesquisa de um agente para a sua própria instância. O conjunto completo de causas e definições está em o 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, exceto quando esse proxy é considerado 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 abrange 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 muito tráfego bloqueia todos os outros. Adicione essa sub-rede a trusted_proxies.

O segundo tipo de bloqueio ocorre no upstream. Um engine pode decidir 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, e o SearXNG suspende-o durante algum tempo depois de falhas repetidas. A causa é o endereço onde o seu VPS está alojado. Por isso, as correções são escolher outro engine e aguardar, não alterar o limitador.

Partilhar uma instância com desconhecidos ajuda ou prejudica?

As duas coisas, em sentidos opostos, por isso 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 milhares de consultas de outras pessoas, por isso nenhum motor consegue distingui-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 detém as consultas em texto simples de toda a multidão, incluindo as suas. No seu próprio servidor, é você que detém as suas consultas e as de mais ninguém.

Por isso, escolha com base na ameaça que realmente enfrenta. Se a sua preocupação é a criação de perfis para publicidade e o rastreamento entre sites, a multidão funciona bem e o risco do operador é pequeno. 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 sem proteção. Uma boa solução intermédia é uma instância para algumas pessoas que conhece. Tem 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 tem um índice próprio, por isso todos os resultados apresentados vieram de um motor externo, e o limite de qualidade é definido pelos 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 tratamento aplicado às suas pesquisas. Nenhum serviço cria um perfil de publicidade a partir da consulta, e nenhum reordena os resultados com base naquilo em 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 menos relevantes através do SearXNG, porque o motor não tem qualquer sinal de localização do 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, por isso 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 através da instância, com um custo adicional de largura de banda e memória. Além disso, formats só é fornecido 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 gratuita para scraping. Esta é a forma mais rápida de fazer com que os motores 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 aquilo que está a fazer. Daí resultam quatro limites.

• O seu tráfego não muda em nenhum ponto, exceto na 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 contém um nome, e esse é todo o benefício.
• O operador de qualquer instância lê a consulta em texto simples. Ser você próprio o operador é a única versão desta situaçã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 que permaneçam vazios.

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

FAQ

O SearXNG é seguro 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 o valor predefinido fornecido de method: "GET", a consulta também fica no log de acesso do reverse proxy como parte da linha do pedido, quer o operador pretendesse isso 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 meu 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 sua instância e o nome de host no campo SNI em texto simples do handshake. O resolvedor DNS também vê a consulta para esse nome de host. Nenhum dos dois vê o que pesquisou, porque a ligação está cifrada. O SearXNG não é uma VPN e não protege qualquer outra atividade da sua máquina.

Por que motivo o SearXNG devolve um erro 429?

O erro 429 vem do limitador da própria instância. É uma proteção contra bots, não 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. Atrás de um reverse proxy que não está incluído em trusted_proxies em /etc/searxng/limiter.toml, todos os visitantes são contados 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 erro 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. Portanto, se os motores limitarem um endereço de datacenter, menos motores respondem e a página fica mais limitada. Além disso, o ranking personalizado desaparece. Isto elimina a reordenação baseada em publicidade e também o contexto local. Como resultado, as pesquisas sensíveis à localização devolvem respostas menos adequadas até definir a sua região nas preferências.