SearXNG는 정말 안전할까? 개인정보 보호의 한계와 진실

SearXNG는 안전한가? 짧은 답변

SearXNG는 어떤 대상을 기준으로 숨기려 하는지에 따라 안전할 수도, 그렇지 않을 수도 있습니다. 따라서 "SearXNG는 안전한가"라는 질문은 누구로부터 정보를 보호하려는지 명확히 할 때만 답할 수 있습니다. SearXNG는 메타 검색 엔진입니다. 사용자의 검색어를 받아 Google, Bing, DuckDuckGo 및 사용자가 활성화한 다른 엔진으로 전달한 뒤, 반환된 결과를 하나의 페이지로 통합합니다. 이때 검색 엔진은 SearXNG 인스턴스를 보게 되고, 인스턴스는 사용자를 보게 됩니다.

낯선 사람이 운영하는 공개 인스턴스를 사용할 경우, 운영자는 사용자가 입력한 모든 검색어를 평문으로 수신합니다. 해당 인스턴스의 소개 페이지에 적힌 내용만으로는 운영자가 그 데이터를 어떻게 처리하는지 증명할 방법이 없습니다. 반면 직접 서버를 운영하면, 상위 검색 엔진은 사용자의 가정집 IP 주소 대신 서버의 주소를 보게 됩니다. 이 주소 교체가 개인정보 보호의 핵심이며, 그 가치는 해당 서버를 얼마나 신뢰할 수 있는지에 달려 있습니다.

이 과정 중 어느 부분도 사용자의 네트워크로부터 검색 활동을 숨겨주지는 않습니다. 인터넷 서비스 제공업체(ISP)는 여전히 사용자가 해당 인스턴스로 연결하고 있다는 사실을 알 수 있습니다. DNS(Domain Name System) 리졸버 또한 사용자가 접속하는 호스트 이름을 확인합니다. 이어지는 내용을 읽을 때 이 경계를 항상 염두에 두어야 합니다.

SearXNG가 검색 요청을 처리하는 방식

Google을 직접 검색하면 Google은 사용자의 IP 주소, 쿠키, User-Agent 헤더, 이전 페이지 정보를 수집합니다. 이 정보들은 세션이 종료된 후에도 유지되는 프로필과 연결됩니다. SearXNG는 그 사이에 위치합니다. SearXNG 문서에 따르면 이 서비스는 "검색 엔진으로 전달되는 요청에서 개인 정보를 제거"하고 "모든 요청마다 무작위 브라우저 프로필을 생성"하는 두 가지 역할을 수행합니다. 쿠키는 검색 엔진으로 전달되지 않습니다. 사용자 설정은 서버의 계정이 아닌 사용자의 브라우저에 저장됩니다.

기본적으로 두 개의 응답 헤더가 포함되며, 각각 다음과 같은 기능을 수행합니다.

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

Referrer-Policy: no-referrer는 검색 결과를 클릭할 때 브라우저가 Referer 헤더를 생략하도록 하여, 목적지 사이트가 어떤 검색 페이지에서 유입되었는지 알 수 없게 합니다. X-Robots-Tag: noindex, nofollow은 사용자의 인스턴스와 결과 페이지가 검색 엔진 인덱스에 포함되지 않도록 방지합니다.

SearXNG가 변경하지 않는 것은 검색어 그 자체입니다. TLS(전송 계층 보안)가 인스턴스에서 종료되므로, 검색어는 인스턴스에 도달할 때 온전하고 읽을 수 있는 상태로 전달됩니다. 아래의 모든 내용은 이 사실에서 비롯됩니다.

공용 인스턴스에서는 운영자가 모든 쿼리를 볼 수 있습니다

프로젝트 자체 문서에도 명확히 나와 있다. 공개 인스턴스 사용자는 “해당 인스턴스의 관리자”를 신뢰해야 하며, “요청이 기록·집계되어 제3자에게 전송되거나 판매되는지” 알 수 없다. 랜딩 페이지의 로그를 남기지 않는다는 주장은 어디까지나 주장이다. 외부에서는 이를 검증할 방법이 없으므로, 결국 신뢰하거나 사용하지 않는 수밖에 없다. 일부 공개 인스턴스는 여전히 이 포크가 아니라 기존 Searx를 실행한다. 이는 Searx에 2023년 이후 코드 커밋이 없기 때문에 중요하다. 유지 관리되지 않는 검색 소프트웨어는 사용자가 아무런 검증 없이 신뢰해야 하는 대상이 하나 더 늘어난다는 의미다.

기본 설정 상태에서는 쿼리가 URL에 포함되므로, 로그 기록은 가장 쉽게 발생할 수 있는 문제입니다.

server:
  method: "GET"

GET을 사용하면 쿼리는 요청 라인의 ?q=...에 포함되어 전송됩니다. 일반적인 리버스 프록시는 해당 요청 라인을 액세스 로그에 기록하므로, 별도의 기록 의도가 없더라도 쿼리는 자동으로 저장됩니다.

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

직접 운영하는 인스턴스에서 이를 확인하려면 다음을 실행하십시오.

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

nginx의 combined 로그 형식은 쿼리 문자열을 포함한 전체 요청 라인인 $request를 기록하기 때문에 검색어가 로그에 남게 됩니다. SearXNG는 이 과정에 관여할 수 없습니다. 인스턴스 설정을 method: "POST"로 변경하면 쿼리가 요청 본문으로 이동하므로, 액세스 로그나 브라우저 기록에 쿼리가 남지 않게 됩니다. 문서에서도 언급하듯이 POST 방식은 브라우저 뒤로 가기 버튼 사용 등 "최종 사용자의 편의성을 크게 제한하는" 단점이 있습니다. 이는 사용자가 의도적으로 선택해야 하는 절충안입니다.

모든 공용 인스턴스에는 두 가지 결과가 따릅니다. 운영자는 데이터를 수집할 의도가 있었는지와 관계없이 사용자의 쿼리를 읽을 수 있습니다. 또한 백업 파일이나 서버 침해 사고 발생 시에도 동일한 로그가 노출될 위험이 있습니다.

직접 운영하는 VPS에서는 검색 엔진이 사용자가 아닌 서버를 인식합니다

VPS(가상 사설 서버)에서 직접 인스턴스를 실행하면 변화는 간단합니다. Google은 더 이상 사용자의 가정용 IP 주소를 쿼리와 함께 수신하지 않습니다. 대신 서버의 IP 주소를 쿼리와 함께 수신합니다. 따라서 검색 기록을 사용자의 로그인 계정, 휴대폰, 또는 가정용 네트워크에 연결된 광고 프로필과 결합할 수 없습니다. 구축 방법은 VPS에서 SearXNG 인스턴스를 직접 운영하는 가이드에 자세히 설명되어 있습니다.

무엇이 바뀌지 않았는지 명확히 이해해야 합니다. 검색 엔진은 여전히 쿼리 텍스트, 시간, 요청한 언어 및 지역, 그리고 수개월에 걸친 검색 패턴을 모두 하나의 고정된 주소 아래에서 파악할 수 있습니다. 사용자가 혼자라면, 해당 주소는 이름이 없는 개인별 검색 흐름이 됩니다. 이러한 그룹화를 방지하려면 인스턴스가 아웃바운드 프록시나 Tor를 통해 검색 엔진에 연결되어야 합니다. SearXNG는 이를 지원하지만, 이는 별도의 설정 작업이 필요합니다.

ISP, 리졸버, 호스트가 여전히 확인 가능한 정보

다음 네 곳의 관찰자는 이 설정의 영향을 받지 않습니다.

• ISP는 귀하의 인스턴스 IP 주소로 연결되는 TLS 연결을 확인하며, 핸드셰이크 과정에서 평문으로 전송되는 SNI(server name indication) 필드의 호스트명을 볼 수 있습니다. 다만 실제 쿼리 내용은 확인할 수 없습니다.
• DNS 리졸버는 해당 호스트명에 대한 조회 요청을 확인합니다. 페이지를 로드하는 동안 클라이언트에서 sudo tcpdump -ni any port 53 명령으로 모니터링하면 인스턴스에 대한 A 레코드 요청이 나타나는 것을 볼 수 있습니다.
• VPS 제공업체는 하드웨어를 운영하므로 가상 머신의 디스크와 메모리를 읽을 수 있습니다. 실행 중인 시스템이 키를 보유하고 있으므로, 임대된 VM 내부의 디스크 암호화는 이를 방지하지 못합니다.
• 인스턴스의 root 권한을 가진 사람은 모든 것을 볼 수 있습니다. 여기에는 귀하 본인과 추후 침입하는 모든 공격자가 포함됩니다.

Tor onion 서비스로 인스턴스에 접속하면 앞의 두 가지 문제는 해결됩니다. 해결해야 할 공개 호스트명이 없고 읽을 SNI 필드도 존재하지 않기 때문입니다. VPS에 v3 onion 서비스를 추가하는 가이드에서는 설정 방법과 함께, 해당 주소가 서버의 공인 IP와 연결되는 것을 방지하는 누출 방지 대책을 다룹니다.

사람들이 간과하는 한 가지가 더 있습니다. 서버의 아웃바운드 요청은 서버가 속한 네트워크에서 볼 수 있으므로, 제공업체는 귀하의 머신이 하루 종일 Google이나 Bing과 통신한다는 사실을 알 수 있습니다. 이는 쿼리 내용이 아닌 트래픽 패턴이지만, 여전히 많은 정보를 노출합니다.

이 지점에서 VPN(virtual private network)에 대한 의문이 생깁니다. VPN은 ISP의 관점을 VPN 업체의 관점으로 옮길 뿐입니다. 인스턴스 운영자나 검색 엔진에 대해서는 아무것도 바꾸지 못합니다. 검색 엔진은 귀하가 아닌 서버와 통신하기 때문입니다. 이 두 가지의 차이는 VPS와 VPN의 비교 분석에서 상세히 다룹니다.

SearXNG가 차단하는 이유와 429 오류의 실제 의미

"SearXNG가 나를 차단했다"는 말은 두 가지 서로 다른 상황을 의미하며, 각각 해결 방법이 다릅니다.

첫 번째는 사용자의 리미터(limiter)가 HTTP 429 응답을 보내는 경우입니다. 이는 SearXNG의 봇 방지 기능이며, 기본적으로는 꺼져 있습니다.

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

2026년 8월 기준으로, 리미터는 Valkey 데이터베이스가 필요하며 /etc/searxng/limiter.toml에서 규칙을 읽어옵니다. 외부 사용자가 실제로 서버를 이용한다면 server.public_instance: true도 설정해야 합니다. 이 값은 기본적으로 false이며, 공개 서비스용으로 의도된 동작을 제어하기 때문입니다.

리미터는 여러 가지 검사를 수행합니다. http_user_agent은 설정되지 않은 User-Agent나 curl, wget 같은 알려진 도구와 일치하는 User-Agent를 봇으로 간주합니다. http_accept은 Accept 헤더에 text/html이 포함되지 않은 요청을 봇으로 간주합니다. link_token는 실제 브라우저가 불러오는 /client<token>.css URL을 한 번도 요청하지 않은 클라이언트를 의심스러운 대상으로 표시합니다. 검사가 작동하면 SearXNG는 429를 반환하고 botdetection 로거에 ERROR 줄을 기록합니다.

따라서 다음 명령은 실패하며, 이는 의도된 동작입니다.

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

curl은 User-Agent: curl/8.5.0과 Accept: */*을 전송하므로 두 가지 검사에 동시에 걸립니다. 브라우저에서는 잘 작동하는 인스턴스에서 스크립트나 AI 에이전트가 429 오류를 받는 이유가 바로 이것입니다. 에이전트의 검색 기능을 자신의 인스턴스로 연결하기 전에 이 문제를 먼저 해결해야 합니다. 전체 원인과 설정은 SearXNG 속도 제한 및 429 오류 가이드에서 확인할 수 있습니다.

리미터 설정 시 주의해야 할 함정이 하나 있습니다. 리버스 프록시 뒤에 있으면, 프록시가 신뢰할 수 있는 상태가 아닌 한 SearXNG는 방문자의 주소가 아닌 프록시의 주소를 보게 됩니다.

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

기본 목록은 같은 호스트에 있는 프록시를 포함합니다. 별도의 Docker 네트워크에 있는 프록시는 172.18.0.5와 같은 주소에서 들어오는데, 이 주소는 목록에 없으므로 모든 방문자가 하나의 클라이언트로 간주됩니다. 결과적으로 가장 먼저 접속한 사용자가 다른 모든 사용자의 접속을 차단하게 됩니다. 해당 서브넷을 trusted_proxies에 추가하십시오.

두 번째 차단 유형은 업스트림에서 발생합니다. 검색 엔진이 데이터센터 주소에서 많은 검색이 발생하는 것을 보고 스크래퍼로 판단하여 서버에 응답을 중단하는 경우입니다. 이 경우에는 429 오류가 발생하지 않습니다. 대신 해당 엔진의 결과가 누락된 결과 페이지가 표시되고 실패 기록이 남으며, 반복적인 실패가 발생하면 SearXNG는 일정 시간 동안 해당 엔진을 일시 중단합니다. 원인은 VPS가 위치한 주소이므로, 리미터 설정을 변경하는 대신 엔진을 선택적으로 사용하거나 기다리는 것이 해결책입니다.

낯선 사람과 인스턴스를 공유하는 것이 도움이 될까요, 아니면 해가 될까요?

두 가지 측면이 상반된 방향으로 작용하기 때문에 답변이 모호하게 느껴질 수 있습니다. 익명성은 군중 효과에서 비롯됩니다. 사용자가 많은 공개 인스턴스에서는 사용자의 쿼리가 수천 명의 다른 사람들과 같은 주소에서 발생하므로, 어떤 검색 엔진도 그 더미 속에서 사용자의 쿼리를 특정할 수 없습니다. 반면, 1인용 인스턴스를 사용하면 해당 주소에서 발생하는 모든 쿼리가 사용자의 것이 되며, 검색 엔진은 이름이 붙지 않은 한 사람의 깨끗한 데이터 흐름을 받게 됩니다.

운영자 측면에서는 정반대의 결과가 나타납니다. 대규모 군중이 모인 인스턴스에서는 낯선 운영자가 사용자의 쿼리를 포함한 군중의 평문 데이터를 보게 됩니다. 자신의 서버를 직접 운영하면 사용자의 쿼리는 사용자가 직접 관리하며 다른 누구도 볼 수 없습니다.

따라서 실제 직면한 위협에 따라 선택해야 합니다. 광고 프로파일링이나 사이트 간 추적이 걱정되십니까? 군중 속에 섞이는 것이 이를 잘 방어하며, 운영자로 인한 위험은 작습니다. 특정 인물이나 기업이 사용자가 수행한 특정 검색 내용을 읽을까 봐 걱정되십니까? 이 경우 군중 속에 섞이는 것은 전혀 도움이 되지 않습니다. 운영자가 원본 텍스트를 그대로 볼 수 있기 때문입니다. 좋은 절충안은 아는 사람들 몇 명과 함께 인스턴스를 사용하는 것입니다. 적절한 규모의 군중을 형성하면서, 운영자가 바로 본인이므로 검증 가능한 운영자를 확보할 수 있습니다.

SearXNG의 검색 결과가 Google보다 나은가요?

아닙니다. SearXNG는 자체적인 인덱스를 보유하고 있지 않으므로, 페이지에 표시되는 모든 결과는 업스트림 엔진에서 가져온 것입니다. 따라서 검색 품질의 상한선은 사용자가 활성화한 엔진들의 품질에 의해 결정됩니다. Google과 Bing을 비활성화하면 일반적인 웹 검색 범위의 대부분이 이들로부터 나오기 때문에 즉시 품질이 저하됩니다.

변화하는 것은 사용자에게 적용되는 처리 방식입니다. 검색어를 기반으로 광고 프로필을 생성하는 기능은 없으며, 지난주에 클릭한 기록을 바탕으로 결과를 재정렬하지도 않습니다. 이는 양날의 검과 같습니다. 개인화 기능은 지역적 의도를 파악하는 데도 사용되기 때문입니다. "지금 문을 연 약국"과 같은 검색어는 SearXNG를 통하면 결과가 더 부정확하게 나옵니다. 엔진은 서버가 위치한 데이터 센터 외에는 사용자의 위치 정보를 알 수 없기 때문입니다. 지역 검색 결과가 중요하다면 설정에서 지역을 지정하십시오.

결과를 확인하는 동안 인스턴스에서 정보가 얼마나 유출되는지는 두 가지 설정이 결정합니다. image_proxy은 기본적으로 false로 설정되어 있으므로, 썸네일은 해당 이미지를 호스팅하는 사이트에서 직접 로드되며 해당 사이트들은 사용자의 브라우저 주소를 확인하게 됩니다. image_proxy: true을 설정하면 대역폭과 메모리 비용이 발생하지만, 대신 인스턴스를 거쳐서 로드하게 됩니다. 또한 formats는 기본적으로 html로만 제공되므로, JSON(JavaScript object notation) 요청은 403 Forbidden 오류로 거부됩니다.

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

공용 인스턴스에서 json을 활성화하면 무료 스크래핑 API를 공개하는 셈이 되며, 이는 의존하고 있는 검색 엔진들로부터 서버 주소가 차단되는 가장 빠른 방법입니다. 이 기능을 끄거나 인증 뒤에 배치하십시오.

SearXNG의 개인정보 보호가 끝나는 지점

SearXNG는 검색 엔진으로부터 누가 검색을 요청했는지 숨깁니다. 하지만 네트워크상에서 사용자가 무엇을 하는지까지 숨기지는 않습니다. 이로 인해 다음과 같은 네 가지 한계가 발생합니다.

• 검색창을 제외한 모든 곳에서 네트워크 트래픽은 그대로 유지됩니다. 기기가 수행하는 다른 모든 작업은 이전과 동일하게 네트워크를 통과합니다.
• 서버 한 대를 사용하는 사용자 한 명은 모든 검색 엔진에 고정된 식별자로 인식됩니다. 이 식별자에는 이름이 포함되지 않으며, 그것이 제공하는 이점의 전부입니다.
• 인스턴스 운영자는 모든 검색 질의를 평문으로 읽을 수 있습니다. 직접 운영하는 것만이 유일하게 검증 가능한 방식입니다.
• 사용자의 접근 로그는 피하고자 했던 기록을 다시 생성합니다. 로그를 직접 확인해 보고, 기록이 남지 않기를 원한다면 method: "POST"로 전환하십시오.

SearXNG는 관찰자의 위치를 옮길 뿐 관찰 자체를 제거하지는 않습니다. 어떤 관찰자를 허용할지 결정하고 그에 맞는 인스턴스를 선택하십시오. 검색 프론트엔드를 익명화 소프트웨어로 간주해서는 안 됩니다.

FAQ

공개 인스턴스에서 SearXNG를 사용하는 것은 안전합니까?

검색 엔진으로부터는 안전하지만 운영자로부터는 안전하지 않습니다. 사용자의 검색어는 평문으로 서버에 도달하며, 프로젝트 문서에 따르면 사용자는 "해당 인스턴스의 관리자를 신뢰해야" 하며 "요청이 기록, 집계되거나 제3자에게 전송 또는 판매되는지" 알 수 없습니다. method: "GET" 기본 설정이 적용된 경우, 운영자의 의도와 관계없이 검색어는 요청 라인의 일부로서 리버스 프록시의 접근 로그에 남게 됩니다. 광고 프로파일링이 우려되는 일반적인 검색에는 공개 인스턴스를 사용하십시오. 인스턴스 소유자에게 직접 건네줄 수 없는 내용은 입력하지 마십시오.

SearXNG는 인터넷 서비스 제공업체(ISP)로부터 검색 기록을 숨겨줍니까?

검색어는 숨겨지지만 활동 자체는 숨겨지지 않습니다. ISP는 사용자가 인스턴스 주소로 TLS 연결을 맺는 것을 볼 수 있으며, 핸드셰이크 과정의 평문 SNI 필드에서 호스트 이름을 확인할 수 있습니다. 또한 DNS 리졸버는 해당 호스트 이름에 대한 조회 기록을 확인합니다. 연결이 암호화되어 있으므로 ISP는 사용자가 무엇을 검색했는지 알 수 없습니다. SearXNG는 VPN이 아니며, 사용자의 기기에서 발생하는 다른 활동에 대해서는 어떠한 보호도 제공하지 않습니다.

SearXNG에서 429 오류가 발생하는 이유는 무엇입니까?

429 오류는 Google에서 보내는 메시지가 아니라 인스턴스 자체의 제한 장치에서 발생하는 봇 방지 응답입니다. 이 장치는 Accept 헤더에 text/html이 없거나, User-Agent가 설정되지 않았거나 curl 및 wget 같은 도구와 일치하는 요청을 차단합니다. 세 번째 확인 항목인 링크 토큰은 브라우저가 로드하는 /client<token>.css URL을 한 번도 가져오지 않은 클라이언트를 식별합니다. /etc/searxng/limiter.toml 내의 trusted_proxies 설정이 누락된 리버스 프록시 뒤에 있으면 모든 방문자가 하나의 클라이언트로 간주되므로, 한 명의 사용자가 트래픽을 많이 발생시키면 나머지 사용자가 차단됩니다. 반면 업스트림 엔진이 서버를 직접 차단하는 경우에는 해당 엔진의 결과만 페이지에서 누락될 뿐 429 오류는 발생하지 않습니다.

SearXNG를 직접 호스팅하면 검색 결과의 품질이 떨어집니까?

두 가지 이유로 결과가 달라질 수 있습니다. 첫째, 검색 결과는 업스트림 엔진에서 가져오는데, 데이터센터 IP 주소는 엔진들이 속도 제한을 거는 경우가 많아 응답하는 엔진 수가 줄어들고 결과 페이지가 빈약해질 수 있습니다. 둘째, 개인화된 랭킹이 사라지므로 광고 기반의 재정렬이 제거되며 지역적 의도 파악도 되지 않습니다. 따라서 환경 설정에서 지역을 직접 지정하기 전까지는 위치 기반 검색 결과의 정확도가 떨어질 수 있습니다.