SearXNG는 정말 안전할까? 프라이버시 보호 원리와 한계

SearXNG는 안전한가? 짧은 답변

SearXNG는 어떤 방향에서 보느냐에 따라 안전할 수도, 안전하지 않을 수도 있습니다. 따라서 "SearXNG가 안전한가"라는 질문은 누구로부터 자신을 숨기려 하는지 명확히 할 때만 답할 수 있습니다. SearXNG는 메타 검색 엔진입니다. 사용자의 검색어를 받아 Google, Bing, DuckDuckGo 및 사용자가 활성화한 다른 엔진으로 전달한 뒤, 돌아오는 결과를 하나의 페이지로 통합합니다. 검색 엔진은 SearXNG 인스턴스를 보며, 인스턴스는 사용자를 봅니다.

낯선 사람이 운영하는 공개 인스턴스를 사용하면, 그 운영자는 사용자가 입력하는 모든 검색어를 평문으로 수신합니다. 인스턴스의 소개 페이지에 적힌 내용은 그들이 데이터를 어떻게 처리하는지 증명할 수 없습니다. 반면 직접 서버를 운영하면, 상위 검색 엔진들은 사용자의 가정집 주소 대신 서버의 주소를 보게 됩니다. 이 주소 교체가 프라이버시 보호의 핵심이며, 그 가치는 해당 서버의 신뢰도와 정확히 일치합니다.

이 과정 중 어느 부분도 사용자의 네트워크로부터 검색 활동을 숨겨주지는 않습니다. 인터넷 서비스 제공업체(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자에게 전송되거나 판매되는지" 알 수 없다고 명시되어 있습니다. 랜딩 페이지의 로그 미기록 주장은 하나의 주장일 뿐입니다. 외부에서는 이를 검증할 방법이 없으므로, 신뢰하거나 아니면 사용하지 않는 것 외에는 선택지가 없습니다.

기본 설정으로 쿼리가 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 권한을 가진 사람은 모든 것을 볼 수 있습니다. 여기에는 귀하 본인과 추후 시스템에 침입하는 모든 공격자가 포함됩니다.

사람들이 간과하는 한 가지가 더 있습니다. 서버의 아웃바운드 요청은 서버가 속한 네트워크에서 확인 가능하므로, 제공업체는 귀하의 머신이 하루 종일 Google이나 Bing과 통신한다는 사실을 알 수 있습니다. 이는 쿼리 내용이라기보다 트래픽 패턴에 해당하며, 이 역시 특정 정보를 노출합니다.

이 지점에서 VPN에 대한 의문이 생깁니다. VPN(virtual private network)은 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이며, 공개 서비스용으로 의도된 동작을 제어하기 때문입니다.

리미터는 여러 프로브(probe)를 실행합니다. http_user_agent은 User-Agent가 설정되지 않았거나 curl, wget 같은 알려진 도구와 일치할 경우 봇으로 간주합니다. 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 주소는 엔진이 속도 제한을 걸기 쉬워 응답하는 엔진 수가 줄어들고 결과 페이지가 빈약해질 수 있습니다. 둘째, 개인화된 랭킹 기능이 사라지므로 광고 기반의 재정렬이나 지역적 의도가 반영되지 않습니다. 따라서 환경 설정에서 지역을 직접 지정하기 전까지는 위치 기반 검색 결과가 다소 부정확할 수 있습니다.