가이드

작성자 Matt Connor 2026-08-22 · 업데이트됨 2026-08-29

Searx와 SearXNG 차이점: 현재 사용 가능한 버전은?

Q: 기존 searx의 settings.yml을 SearXNG에서 사용할 수 있습니까?

아니요. 파일 자체가 아닌 설정값만 복사하십시오. SearXNG는 /etc/searxng/settings.yml을 읽으며 파일 상단에 use_default_settings: true이 있을 것으로 예상합니다. 따라서 사용자의 파일은 기본 설정 위에 덮어쓰는 오버레이 방식으로 동작합니다. 오래된 searx 파일은 키 이름이 다르며, limiter, valkey 블록, formats 목록이 없는 전체 설정 파일입니다. utils/templates/etc/searxng/settings.yml에 있는 템플릿에서 시작하여 변경 사항을 하나씩 다시 추가하십시오.

Searx는 2023년 이후 업데이트가 중단되어 사실상 개발이 종료되었습니다. 현재는 활발히 유지보수되는 SearXNG를 사용해야 합니다. 두 프로젝트의 상태 확인 방법과 설정 파일 경로 차이, 최신 인스턴스 구축 시 필수 고려 사항을 상세히 정리했습니다.

Searx와 SearXNG: 무엇을 설치해야 하는가?

Searx와 SearXNG는 이름은 거의 같지만 서로 다른 프로젝트이며, 현재는 둘 중 하나만 업데이트를 지원합니다. SearXNG를 설치하십시오. 원본 Searx는 2023년 4월 이후로 코드 커밋이 없으며, README 파일에도 "Searx는 더 이상 유지보수되지 않습니다(Searx is no longer maintained)"라고 명시되어 있습니다.

이는 철학적인 문제가 아니라 실질적인 문제입니다. 두 프로젝트는 스크린샷, 설정 파일의 대부분, 이름의 절반을 공유하기 때문에 하나를 위해 작성된 가이드가 다른 쪽에도 적용되는 것처럼 보입니다. 하지만 실제로는 그렇지 않습니다. 설정 파일의 위치가 다르고, 봇 방지 기능이 새로 추가되었으며, 최신 Ubuntu 패키지 저장소에서는 원본 패키지가 사라졌습니다. 다음 내용은 두 프로젝트의 차이점, 직접 상태를 확인하는 명령어, 그리고 인스턴스를 구축하는 사용자가 알아야 할 변경 사항을 정리한 것입니다.

Searx란 무엇이며 SearXNG는 어디서 유래했는가

Searx는 메타 검색 엔진입니다. 자체적인 인덱스를 유지하지 않습니다. 사용자의 검색어를 받아 Bing, DuckDuckGo, Wikipedia와 같은 다른 검색 서비스로 전달한 뒤, 돌아오는 결과를 하나의 결과 페이지로 통합합니다. 이 방식의 장점은 해당 서비스들이 사용자의 주소가 아닌 서버의 주소를 보게 된다는 점입니다. 단점은 유지보수 비용입니다. 각 엔진은 타인의 HTML이나 API를 파싱하는 작은 코드 조각이므로, 업스트림이 변경될 때마다 엔진이 고장 납니다. 메타 검색 엔진의 상태는 엔진 모듈을 수정하는 사람들의 역량에 달려 있습니다.

searx 저장소는 2013년 10월에 생성되었습니다. 2021년 4월, 이전 관리자 중 한 명이 이를 포크하여 SearXNG를 시작했습니다. "NG"는 차세대(next generation)를 의미합니다. Searx의 README는 두 프로젝트를 나란히 설명하고 있으며, 그 설명이 분기 이유를 가장 명확하게 요약합니다.

SearXNG는 searx의 이전 관리자가 만든 searx의 포크입니다.

SearXNG는 롤링 릴리스를 채택하고, 의존성을 더 자주 업데이트하며, 엔진 수정이 더 빠릅니다.

포크의 배경이 된 의견 차이는 진단 정보에 관한 것이었습니다. Searx는 사용 데이터를 인스턴스가 보유해서는 안 되는 것으로 간주하며, 기본 설정에서도 이를 명시합니다: enable_stats: False # activate /stats page - note: it may leak usage data. SearXNG는 정반대의 결정을 내렸고, 기본 설정에 enable_metrics: true를 포함하여 배포합니다. 이러한 메트릭은 응답 시간 막대와 오류 페이지를 채우는 정보이며, 이를 통해 고장 난 엔진을 쉽게 찾고 수정할 수 있습니다. 두 입장 모두 타당한 근거가 있습니다. 다만, 그중 하나만이 지속적으로 코드를 배포해 왔습니다.

Searx는 죽었습니까? 직접 확인하는 방법

"죽음"은 GitHub가 보고하는 상태가 아니므로, 존재하는 두 가지 신호를 읽고 직접 판단해야 합니다. 첫 번째는 저장소가 보관(archived) 상태인지, 그리고 마지막으로 푸시가 발생한 시점이 언제인지 확인하는 것입니다.

curl -s https://api.github.com/repos/searx/searx | jq -r '.archived, .pushed_at'
curl -s https://api.github.com/repos/searxng/searxng | jq -r '.archived, .pushed_at'

2026년 8월 22일 기준으로 첫 번째 명령은 false와 2026-05-14T10:02:22Z을 출력합니다. 두 번째 명령은 false과 명령을 실행한 날짜의 타임스탬프를 출력합니다. 첫 번째 값을 확인하십시오. searx 저장소는 보관되지 않았고 아무도 문을 잠그지 않았기 때문에, 이 질문은 계속해서 반복됩니다.

pushed_at은 그 자체로는 약한 신호입니다. 한 줄짜리 문서 변경을 포함하여 어떤 브랜치에든 푸시가 발생하면 값이 변하기 때문입니다. 대신 커밋 목록을 읽으십시오.

curl -s 'https://api.github.com/repos/searx/searx/commits?per_page=5' \
  | jq -r '.[] | .commit.committer.date[:10] + "  " + (.commit.message | split("\n")[0])'

2026년 8월 기준으로 해당 명령은 다음을 출력합니다:

2026-05-14  [doc] add hister reference
2023-09-07  Searx is no longer maintained
2023-04-05  Fix quoting issue in search_operator plugin (#3479)
2023-04-04  Bump pallets-sphinx-themes from 2.0.2 to 2.0.3 (#3450)
2023-04-04  Bump selenium from 4.7.2 to 4.8.3 (#3490)

아래에서 위로 읽으십시오. 일반적인 작업은 2023년 4월에 멈췄습니다. 2023년 9월의 커밋은 관리자가 README에 공지 사항을 작성한 것입니다. 그 이후의 단일 커밋은 문서 작업입니다. 이는 원작자가 Hister로 이동했기 때문인데, Hister는 다른 엔진에 쿼리를 보내는 대신 사용자가 선택한 페이지와 파일을 인덱싱하는 검색 도구입니다. 이는 다른 개념이며, 만약 자신의 콘텐츠를 대상으로 하는 개인 검색 엔진을 원한다면 유용한 도구입니다.

두 번째 신호는 패키징이며, 대부분의 오래된 튜토리얼은 이 패키징에 조용히 의존하고 있습니다.

PyPI는 2020년 7월에 업로드된 버전 0.17.0인 searx 릴리스 하나만을 보유하고 있습니다. pip install searx은 성공하지만, 포크가 존재하기 9개월 전의 코드를 제공합니다.
Debian은 Debian 12 (bookworm)에서 searx 1.1.0을 배포했으며 여전히 unstable 버전에서 유지하고 있습니다. 2023년 10월에 testing에서 제거되었으므로, Debian 13 (trixie)에는 searx 패키지가 전혀 없습니다.
Ubuntu는 22.04 버전에서 1.0.0 버전을 마지막으로 배포했습니다. Ubuntu 24.04에서 sudo apt install searx은 E: Unable to locate package searx로 끝납니다.
프로젝트가 항상 사용자들에게 안내했던 공개 인스턴스 디렉터리인 searx.space는 이제 SearXNG 인스턴스들을 나열합니다.

결론적으로 솔직한 상태는 다음과 같습니다. 코드는 공개되어 있고 여전히 실행 가능하며, 오늘 당장 클론하여 시작할 수 있습니다. 하지만 엔진 수정이나 보안 업데이트는 받을 수 없으며, 메타 검색 엔진에게 그것은 본연의 임무입니다. 엔진은 타인의 일정에 따라 부패합니다. 유지보수되지 않는 인스턴스는 아무도 서버를 건드리지 않아도 매달 더 적은 결과를 반환하게 됩니다.

새로운 인스턴스에서 변경된 사항

설정 파일이 이동했으며 이제 오버레이 방식으로 동작합니다

Searx에서는 searx/settings.yml을 소스 트리 내부에서 직접 수정했습니다. SearXNG에서는 해당 파일이 /etc/searxng/settings.yml에 위치하며, 프로세스는 SEARXNG_SETTINGS_PATH 환경 변수를 통해 이 파일을 찾습니다. 설치 프로그램이 해당 경로에 복사하는 템플릿은 다음과 같이 짧습니다.

use_default_settings: true

general:
  debug: false
  instance_name: "SearXNG"

search:
  safe_search: 2
  autocomplete: 'duckduckgo'
  formats:
    - html

server:
  # Is overwritten by ${SEARXNG_SECRET}
  secret_key: "ultrasecretkey"
  limiter: true
  image_proxy: true

valkey:
  # URL to connect valkey database. Is overwritten by ${SEARXNG_VALKEY_URL}.
  url: valkey://localhost:6379/0

use_default_settings: true은 작업 방식을 바꾸는 핵심 설정입니다. 이 설정이 있으면 파일은 오버레이(덮어쓰기)로만 동작하며, 명시하지 않은 모든 키는 패키지에 포함된 기본값에서 가져옵니다. 이 설정이 없으면 전체 설정을 엔진별로 일일이 기술해야 합니다. 인스턴스가 깔끔하게 시작되지만 아무것도 검색하지 못하는 상황은 주로 여기서 발생합니다. 이전 Searx 설정 파일을 이 경로에 붙여넣으면 키 이름이 달라 전체 설정이 꼬이게 되며, 결국 두 번째 방식을 따르다가 오류가 발생합니다.

secret_key가 없으면 프로세스가 중단됩니다

sudo -H sed -i -e "s/ultrasecretkey/$(openssl rand -hex 16)/g" \
              "/etc/searxng/settings.yml"

템플릿을 복사한 후 위 명령을 한 번 실행하십시오. 이 과정을 건너뛰면 SearXNG는 로그 한 줄을 남기고 상태 코드 1로 종료됩니다. webapp.py이 서비스를 시작하기 전에 키 값을 템플릿 값과 비교하기 때문입니다.

server.secret_key is not changed. Please use something else instead of ultrasecretkey.

general.debug이 true이면 이 검사를 건너뜁니다. 따라서 디버그 세션에서는 인스턴스가 잘 작동하다가도 systemd나 컨테이너 환경에서는 시작을 거부할 수 있습니다. docker compose logs에 해당 설정이 있는 상태에서 컨테이너가 무한 재시작 루프에 빠진다면, 이는 이미지 오류가 아니라 이 검사 과정에서 발생하는 현상입니다.

리미터가 새로 도입되었으며 Valkey가 필요합니다

Searx는 애플리케이션 내부에 속도 제한(rate limiting) 기능이 없었습니다. 공개 Searx 인스턴스는 앞단에 별도의 서비스인 filtron(요청 필터링용)과 morty(결과 콘텐츠 프록시용)를 두었습니다. 두 저장소 모두 2023년 이후로 커밋이 없습니다.

SearXNG는 이 작업을 자체적으로 수행합니다. 속도 제한과 봇 탐지는 limiter 기능을 통해 이루어지며, server.limiter으로 활성화합니다. 기본값은 false이며 설치 프로그램 템플릿에서는 true로 설정되어 있습니다. 이 기능을 사용하려면 카운터를 저장할 Valkey 데이터베이스가 필요합니다. Valkey는 Redis의 포크이며 Ubuntu 24.04에서 패키지로 제공합니다.

sudo apt install -y valkey-server

server:
  limiter: true

valkey:
  url: valkey://localhost:6379/0

이 이름 변경 이전에 작성된 가이드는 redis: 블록을 설정하도록 안내하므로, 현재 limiter 문서에서 키 이름을 확인하여 복사하십시오. 세부 조정은 두 번째 파일인 /etc/searxng/limiter.toml에서 수행하며, server.public_instance: true는 공개 인스턴스에 필요한 더 엄격한 봇 탐지(링크 토큰 방식 포함)를 활성화합니다. 그 결과, 스크립트로 인스턴스에 요청을 보낼 때 결과를 받는 대신 HTTP 429 응답을 받을 수 있습니다. 이에 대한 자세한 내용은 SearXNG 인스턴스가 429 Too Many Requests를 반환하는 이유 페이지를 참조하십시오.

엔진은 스스로 일시 중단되며 타임아웃이 깁니다

업스트림 서비스가 CAPTCHA나 속도 제한 페이지를 반환하면, SearXNG는 재시도하는 대신 해당 엔진에 대해 유형화된 예외를 발생시키고 일정 시간 동안 요청을 중단합니다. 기본값은 searx/settings.yml의 search.suspended_times 아래에 정의되어 있습니다. 2026년 8월 기준으로 게시된 6개의 값은 다음과 같습니다.

ChartSearXNG default engine suspension times, in seconds

label

suspend_seconds

SearxEngineAccessDenied

180

SearxEngineCaptcha

3,600

SearxEngineTooManyRequests

180

cf_SearxEngineCaptcha

1,296,000

cf_SearxEngineAccessDenied

86,400

recaptcha_SearxEngineCaptcha

604,800

The data behind this chart

[
  {
    "label": "SearxEngineAccessDenied",
    "suspend_seconds": "180"
  },
  {
    "label": "SearxEngineCaptcha",
    "suspend_seconds": "3,600"
  },
  {
    "label": "SearxEngineTooManyRequests",
    "suspend_seconds": "180"
  },
  {
    "label": "cf_SearxEngineCaptcha",
    "suspend_seconds": "1,296,000"
  },
  {
    "label": "cf_SearxEngineAccessDenied",
    "suspend_seconds": "86,400"
  },
  {
    "label": "recaptcha_SearxEngineCaptcha",
    "suspend_seconds": "604,800"
  }
]

단순 접근 거부 응답은 해당 엔진을 180초 동안 정지시킵니다. CAPTCHA는 3,600초, Cloudflare CAPTCHA는 1,296,000초(15일) 동안 정지시키며, Google reCAPTCHA는 604,800초(1주일) 동안 정지시킵니다. 이처럼 긴 시간을 설정한 이유는 서비스가 이미 해당 주소를 차단한 상태에서 계속 요청을 보내면 인스턴스 IP가 영구적으로 차단될 수 있기 때문입니다.

엔진이 일시 중단된 동안 결과 페이지는 해당 엔진을 건너뛰고 사이드바의 "검색 엔진 메시지" 블록에 이를 보고하며, /stats/errors에 실패한 항목이 나열됩니다. 새로 설치한 인스턴스에서 결과가 적게 나온다면 설치 오류가 아니라 보통 이 현상 때문입니다.

JSON API는 기본적으로 비활성화되어 있습니다

기본값은 formats: [html]이며 다른 설정은 없습니다. 따라서 모든 스크립트가 필요로 하는 API는 직접 열기 전까지 닫혀 있습니다.

curl -s -o /dev/null -w '%{http_code}\n' \
  'http://127.0.0.1:8888/search?q=test&format=json'

요청한 형식이 search.formats에 나열되어 있지 않으면 검색 경로가 flask.abort(403)을 호출하므로 403이 출력됩니다. 형식을 추가하고 서비스를 재시작하십시오.

search:
  formats:
    - html
    - json

searx 설정 파일에는 formats 키가 아예 없었기 때문에 JSON 출력은 요청만 하면 바로 사용할 수 있었습니다. 당시의 모든 스크립트와 코드 조각은 이를 전제로 작성되었으며, 현재는 아무런 설명 없이 403 오류가 발생하는 것이 실패 모드입니다. 인스턴스를 도구와 연동하려는 경우 에이전트에 SearXNG 검색 엔드포인트 제공하기에서 이 설정부터 확인하십시오.

복사해서 붙여넣은 Searx 튜토리얼이 실패하는 이유

다음 각 항목은 여전히 검색 상위에 노출되는 가이드에 등장하지만, 현재 설치 환경에서는 실패하거나 잘못된 정보를 제공합니다.

Ubuntu 24.04에서 sudo apt install searx를 실행하면 E: Unable to locate package searx에서 멈춥니다. 해당 패키지는 22.04 버전을 끝으로 더 이상 배포되지 않기 때문입니다.
pip install searx은 설치에 성공하지만 2020년 7월에 릴리스된 0.17.0 버전을 설치합니다. 이 버전이 프로젝트 포크 이전의 것임을 경고하는 문구는 어디에도 없습니다.
git clone https://github.com/asciimoo/searx은 여전히 작동합니다. GitHub가 이전 소유자 이름을 리다이렉트해주며, 2023년 4월 시점의 트리로 연결해주기 때문입니다.
소스 트리에서 searx/settings.yml을 수정하는 단계는 SearXNG에 아무런 영향을 주지 않습니다. SearXNG는 /etc/searxng/settings.yml를 읽기 때문입니다.
filtron이나 morty를 설치하는 단계는 SearXNG에 이미 포함된 기능을 중복해서 구축하는 것입니다.
limiter를 위한 redis: URL은 현재의 valkey: 키보다 이전 명칭입니다.

SearXNG 가이드 역시 시간이 지나면 쓸모없어지며, clone URL을 확인하는 것이 해당 가이드의 시점을 파악하는 가장 빠른 방법입니다. 과거에는 compose 파일이 별도의 searxng-docker 저장소에 있었습니다. 해당 저장소는 2026년 3월에 아카이브되었고, 파일들은 메인 저장소의 container/으로 이동했습니다. 현재 문서에서 제공하는 컨테이너 퀵스타트 방식은 다음과 같습니다.

mkdir -p ./searxng/core-config/
cd ./searxng/
curl -fsSL \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/docker-compose.yml \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/.env.example
cp -i .env.example .env
nano .env
docker compose up -d

마지막 명령을 실행하기 전에 .env를 수정하십시오. 이미지는 환경 변수를 설정 키로 매핑하므로, SEARXNG_SECRET는 server.secret_key이 되고 SEARXNG_BASE_URL은 server.base_url이 됩니다. 스크립트를 이용한 호스트 설치 방식은 경로는 다르지만 결과는 동일합니다.

git clone https://github.com/searxng/searxng.git searxng
cd searxng
sudo -H ./utils/searxng.sh install all

이 과정은 searxng 사용자를 생성하고, /usr/local/searxng 하위에 가상 환경을 구축하며, uWSGI 서비스를 설정합니다. 이는 SearXNG 문서에서 권장하는 표준 설정입니다. 해당 경로에 대한 자세한 설명은 자신의 VPS에 SearXNG 설치하기를 참조하십시오.

공용 인스턴스 또는 개인 인스턴스

공용 인스턴스는 타인의 서버에서 TLS(transport layer security) 연결을 종료하는 방식이므로, 해당 서버의 소프트웨어는 사용자의 질의를 일반 텍스트로 읽습니다. SearXNG 공식 문서에서는 신뢰 문제를 명확히 지적합니다. 관리자를 신뢰해야 하며, 요청이 기록되거나 수집되는지, 혹은 제3자에게 전달되는지 알 수 없습니다. 공개된 목록은 짧고 완전합니다. 운영자의 스택은 질의 텍스트, 시간, 요청이 도달한 IP 주소, 브라우저 사용자 에이전트, 그리고 설정을 담은 preference 쿠키를 확인할 수 있습니다. 또한 운영자가 코드를 제어하므로, 그들이 적용한 모든 패치가 사용자의 검색마다 실행됩니다.

기본 설정 하나가 실수로 로그를 남기기 더 쉽게 만듭니다. Searx는 검색을 POST로 전송했습니다. SearXNG는 method: "GET"을 제공하며, POST는 검색 질의를 브라우저 기록에 남기지 않지만 사용성 문제를 일으킨다는 설명을 덧붙입니다. GET을 사용하면 질의가 요청 라인에 남으므로 기본적으로 리버스 프록시 접근 로그와 브라우저 기록에 저장됩니다. 이는 일반적인 웹 서버의 동작 방식입니다. 누구의 서버를 사용할지 선택하기 전에 알아두어야 할 사항입니다.

개인 인스턴스를 운영하는 것은 신뢰를 제거하는 것이 아니라 이동시키는 것입니다. 코드와 로그를 직접 제어할 수 있으며, 단일 사용자용 박스에 호스트네임이나 TLS 인증서를 공개하고 싶지 않다면 v3 onion service를 통해 접속하여 공용 DNS에 인스턴스를 노출하지 않고도 어디서든 접속할 수 있습니다. 대신 상위 검색 엔진들은 사용자의 모든 검색을 하나의 주소에서 오는 것으로 인식하며, 단일 사용자 인스턴스에서는 모든 질의가 군중 속에 섞이지 않고 사용자에게 추적됩니다. 사용자가 많은 공용 인스턴스는 군중 속에 섞이게 해주지만 로그에 대한 통제권은 가져갑니다. 본인이 중요하게 생각하는 속성을 선택하십시오. 전체 위험 목록을 먼저 확인하고 싶다면 SearXNG 사용의 안전성 문서를 참조하십시오.

VPS 운영 시 실용적인 참고 사항입니다. 데이터센터 주소 대역은 가정용 연결보다 더 빠르게 차단되므로, 새로운 인스턴스는 검색 몇 번 만에 일부 엔진에서 CAPTCHA를 마주하게 됩니다. 이는 앞서 언급한 차단 동작이 정상적으로 작동하는 것이며, 설정 오류가 아닙니다.

이미 Searx 인스턴스를 운영 중인 경우

이 글을 읽는 시점에 기존 서비스가 즉시 중단되지는 않습니다. 서버는 다음 업스트림 변경으로 인해 다른 엔진이 작동을 멈출 때까지 계속 실행되지만, 일단 문제가 발생하면 그대로 방치됩니다. 마이그레이션을 계획하되, 기존 설정 파일을 그대로 옮기지 마십시오. SearXNG 템플릿에서 시작하여 의도적으로 변경했던 항목만 다시 추가하십시오. 여기에는 인스턴스 이름, safe_search, 활성화하거나 비활성화한 엔진 이름, 인터페이스 기본 설정이 포함됩니다. 포크 과정에서 엔진 이름과 옵션이 변경되었으므로, 설정 키가 여전히 존재할 것이라고 가정하지 말고 최신 문서와 하나씩 대조해야 합니다. Filtron 규칙과 morty URL은 애플리케이션 내부로 기능이 통합되었으므로 별도의 대응 항목이 없습니다.

기존 인스턴스를 유지한 상태에서 새로운 인스턴스를 다른 포트에서 실행하십시오. 첫 페이지에서 200 응답을 받고, 검색 시 여러 엔진에서 결과가 반환되며, /stats/errors이 비어 있거나 이해 가능한 수준의 실패 항목만 나열된다면 정상적으로 작동하는 것입니다. 이후 리버스 프록시 설정을 변경하고 기존 서비스를 중단하십시오.

FAQ

2026년에 Searx는 더 이상 운영되지 않습니까?

저장소가 아카이브 상태는 아니므로 복제는 가능하지만, 프로젝트는 유지보수되지 않습니다. 마지막 코드 커밋은 2023년 4월에 이루어졌으며, README에는 "Searx는 더 이상 유지보수되지 않습니다"라는 문구가 명시되어 있습니다. curl -s https://api.github.com/repos/searx/searx | jq -r '.pushed_at' 명령으로 직접 확인한 뒤 최근 커밋 메시지를 읽어보십시오. 푸시 날짜만으로는 문서 수정인지 코드 수정인지 알 수 없기 때문입니다. 메타 검색 엔진의 경우, 유지보수가 중단되면 검색 결과의 품질이 저하됩니다. 각 엔진 모듈은 지속적으로 변경되는 업스트림 사이트에 의존하기 때문입니다.

여전히 apt나 pip로 Searx를 설치할 수 있습니까?

현재 시스템에서는 불가능하며, 설치가 가능하더라도 유용하지 않습니다. Ubuntu는 22.04 버전에서 1.0.0 버전을 패키징한 것이 마지막이므로, 24.04에서 sudo apt install searx를 실행하면 E: Unable to locate package searx 오류가 발생합니다. Debian은 Debian 12에서 1.1.0 버전을 제공했으나 2023년 10월 테스트 버전에서 제외했으므로, Debian 13에는 패키지가 없습니다. PyPI는 2020년 7월의 0.17.0 버전을 여전히 제공하지만, 이는 포크 자체보다 오래된 버전입니다. 대신 SearXNG를 설치하십시오.

기존 searx의 settings.yml을 SearXNG에서 사용할 수 있습니까?

아니요. 파일 자체가 아닌 설정값만 복사하십시오. SearXNG는 /etc/searxng/settings.yml을 읽으며 파일 상단에 use_default_settings: true이 있을 것으로 예상합니다. 따라서 사용자의 파일은 기본 설정 위에 덮어쓰는 오버레이 방식으로 동작합니다. 오래된 searx 파일은 키 이름이 다르며, limiter, valkey 블록, formats 목록이 없는 전체 설정 파일입니다. utils/templates/etc/searxng/settings.yml에 있는 템플릿에서 시작하여 변경 사항을 하나씩 다시 추가하십시오.

왜 직접 구축한 SearXNG 인스턴스가 공개 인스턴스보다 검색 결과가 적게 나옵니까?

일부 엔진이 일시 중단되었기 때문입니다. 엔진이 CAPTCHA나 속도 제한 페이지를 반환하면, SearXNG는 일정 시간 동안 해당 엔진에 대한 쿼리를 중단합니다. 단순 거부 시 180초부터 Cloudflare CAPTCHA 발생 시 최대 1,296,000초까지 중단됩니다. 결과 페이지의 "검색 엔진 메시지"에서 이를 확인할 수 있으며, /stats/errors 명령으로 실패 원인을 나열할 수 있습니다. 데이터 센터 IP 주소는 가정용 연결보다 더 빨리 차단되므로, 새로 구축한 VPS 인스턴스에서 이러한 현상이 더 빨리 나타납니다.

공개 SearXNG 인스턴스를 사용해야 합니까, 아니면 직접 구축해야 합니까?

코드와 로그를 직접 제어하고 싶다면 직접 구축하십시오. 단, 업스트림 엔진이 모든 검색 요청을 단일 IP 주소에서 오는 것으로 인식한다는 점을 감안해야 합니다. 로그 기록 여부보다 다른 사람들의 쿼리와 자신의 쿼리를 섞는 것이 더 중요하다면 공개 인스턴스를 사용하십시오. 공개 인스턴스에서는 운영자가 쿼리 텍스트, 시간, IP 주소, 사용자 에이전트를 볼 수 있으며, 언제든지 코드를 변경할 수 있습니다. 명시된 로그 정책은 외부에서 검증할 수 없습니다.

#searxng#searx#search #privacy #self-hosting