Bởi Matt Connor 2026-10-18

Searx hay SearXNG: Nên cài cái nào?

Searx không có commit mã nguồn nào từ tháng 4/2023 và đã bị ngừng duy trì. Kiểm tra trạng thái, rồi xem các thay đổi khi cài instance SearXNG mới.

Searx hay SearXNG: bạn nên cài đặt cái nào?

Searx và SearXNG là hai dự án khác nhau với tên gọi gần như giống hệt nhau, và chỉ một trong số đó còn nhận được các bản sửa lỗi. Hãy cài đặt SearXNG. Dự án Searx gốc đã không có commit mã nguồn nào kể từ tháng 4 năm 2023, và file README của nó đã nêu rõ vị trí trong một dòng: "Searx không còn được duy trì nữa."

Điều này để lại một vấn đề thực tế thay vì vấn đề triết học. Hai dự án này dùng chung một ảnh chụp màn hình, hầu hết file cấu hình và một nửa cái tên, vì vậy một hướng dẫn viết cho cái này trông có vẻ áp dụng được cho cái kia. Thực tế thì không. File cài đặt nằm ở vị trí khác, cơ chế bảo vệ bot là mới, và tên gói đã không còn tồn tại trên các bản phân phối Ubuntu hiện tại. Những nội dung dưới đây là sự phân tách, các lệnh để tự kiểm tra trạng thái, và danh sách những thay đổi đối với người đang thiết lập một instance.

Searx là gì và nguồn gốc của SearXNG

Searx là một công cụ tìm kiếm tổng hợp (metasearch engine). Nó không tự lưu trữ chỉ mục (index) riêng. Nó nhận truy vấn của bạn, chuyển tiếp đến các dịch vụ tìm kiếm khác như Bing, DuckDuckGo hoặc Wikipedia, sau đó hợp nhất kết quả trả về vào một trang duy nhất. Lợi ích là các dịch vụ đó chỉ thấy địa chỉ IP của máy chủ thay vì của bạn. Cái giá phải trả là công tác bảo trì. Mỗi engine là một đoạn mã nhỏ dùng để phân tích (parse) HTML hoặc API của bên thứ ba, vì vậy một engine sẽ bị hỏng bất cứ khi nào phía upstream thay đổi. Sức khỏe của một công cụ tìm kiếm tổng hợp phụ thuộc hoàn toàn vào những người sửa chữa các module engine của nó.

Repository của searx được tạo vào tháng 10 năm 2013. Vào tháng 4 năm 2021, một cựu maintainer đã tạo ra SearXNG như một bản fork từ dự án này. "NG" là viết tắt của next generation (thế hệ tiếp theo). Bản thân file README của searx mô tả cả hai dự án song song, và mô tả đó vẫn là bản tóm tắt rõ ràng nhất về sự phân tách này:

SearXNG là một bản fork của searx, được tạo bởi một cựu maintainer của searx.

SearXNG có các bản phát hành theo dạng rolling release, các dependency được cập nhật thường xuyên hơn và các engine được sửa lỗi nhanh hơn.

Bất đồng đằng sau việc fork này nằm ở vấn đề chẩn đoán. Searx coi dữ liệu sử dụng là thứ mà một instance không nên lưu giữ, và các thiết lập mặc định của nó đã nêu rõ điều đó: enable_stats: False # activate /stats page - note: it may leak usage data. SearXNG đưa ra quyết định ngược lại và mặc định tích hợp enable_metrics: true. Những số liệu này là thứ tạo nên các thanh thời gian phản hồi và các trang báo lỗi, giúp việc tìm kiếm và sửa chữa một engine bị hỏng trở nên dễ dàng. Cả hai quan điểm đều có lý lẽ riêng. Chỉ có một trong số đó là vẫn tiếp tục phát hành code.

Searx đã chết chưa? Tự kiểm tra như thế nào

“Đã chết” không phải là trạng thái mà GitHub báo cáo, nên hãy đọc hai tín hiệu hiện có rồi tự kết luận. Tín hiệu đầu tiên là repository có được archive hay không, và lần push gần nhất là khi nào.

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'

Vào ngày 18 tháng 10 năm 2026, lệnh đầu tiên in ra false và 2026-05-14T10:02:22Z. Lệnh thứ hai in ra false và một timestamp gần đây, thường là trong 1 hoặc 2 ngày gần nhất. Hãy chú ý giá trị đầu tiên. Repository searx không được archive và không ai khóa cửa, nên câu hỏi này vẫn tiếp tục xuất hiện.

pushed_at tự nó là một tín hiệu yếu, vì giá trị này thay đổi khi có push vào bất kỳ branch nào, kể cả một thay đổi tài liệu chỉ gồm 1 dòng. Hãy đọc danh sách commit thay thế.

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

Tính đến ngày 18 tháng 10 năm 2026, lệnh đó in ra:

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  Update searx.data - update_wikidata_units.py (#3454)

Hãy đọc từ dưới lên. Công việc thông thường dừng lại vào tháng 4 năm 2023. Commit tháng 9 năm 2023 là lúc các maintainer ghi thông báo vào README. Commit duy nhất kể từ đó chỉ liên quan đến tài liệu, vì tác giả ban đầu đã chuyển sang Hister, một công cụ tìm kiếm lập chỉ mục các trang và file do bạn chọn thay vì truy vấn các engine khác. Đó là một ý tưởng khác, và hữu ích nếu điều bạn thực sự cần là một công cụ tìm kiếm cá nhân cho nội dung của chính bạn.

Tín hiệu thứ hai là việc đóng gói, và hầu hết tutorial cũ đều âm thầm phụ thuộc vào việc đóng gói.

PyPI có 20 bản phát hành searx, từ 0.1.2 vào tháng 1 năm 2014 đến 0.17.0 vào tháng 7 năm 2020, và tất cả vẫn có thể tải xuống. pip install searx chạy thành công và cung cấp bản mới nhất trong số đó là 0.17.0, tức code được phát hành 9 tháng trước khi fork xuất hiện.
Debian đã phát hành searx 1.1.0 trong Debian 12 (bookworm) và vẫn giữ package này trong unstable. Package bị gỡ khỏi testing vào tháng 10 năm 2023, nên Debian 13 (trixie) hoàn toàn không có package searx.
Ubuntu phát hành searx lần cuối trong 23.10 (mantic), ở version 1.1.0. Bản LTS cuối cùng có searx là 22.04, ở version 1.0.0, và package đã bị xóa khỏi 24.04 trước khi bản phát hành đó ra mắt. Trên Ubuntu 24.04, sudo apt install searx kết thúc bằng E: Unable to locate package searx.
searx.space, directory các instance public mà project luôn hướng người dùng đến, hiện liệt kê các instance SearXNG.

Vì vậy, trạng thái chính xác là như sau. Code vẫn public, vẫn chạy, và bạn có thể clone rồi khởi động ngay hôm nay. Nhưng bạn không nhận được bản sửa engine hoặc security update, trong khi với một metasearch engine thì đó chính là toàn bộ công việc cần duy trì. Các engine sẽ xuống cấp theo lịch của bên khác. Một instance không được maintain sẽ trả về ít kết quả hơn sau mỗi tháng mà không cần ai thay đổi gì trên máy chủ.

Những thay đổi của fork đối với một instance mới

File settings đã chuyển vị trí và hiện là một overlay

Trên Searx, bạn chỉnh sửa searx/settings.yml bên trong source tree. Trên SearXNG, file nằm tại /etc/searxng/settings.yml, và process tìm file này thông qua biến môi trường SEARXNG_SETTINGS_PATH. Template mà installer sao chép đến đó rất ngắn:

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 là dòng làm thay đổi cách bạn cấu hình. Khi có dòng này, file của bạn chỉ chứa các override. Mọi key bạn bỏ qua sẽ lấy từ các giá trị mặc định được đóng gói bên trong package. Nếu không có dòng này, file phải mô tả toàn bộ cấu hình, theo từng engine. Đây là nguyên nhân khiến instance khởi động bình thường nhưng không tìm thấy engine nào. File settings cũ của Searx khi được dán vào path này sẽ trở thành một cấu hình hoàn chỉnh với các key name khác, nên nó đi theo cách thứ hai và gặp lỗi.

Secret key sẽ dừng process

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

Chạy lệnh đó một lần sau khi sao chép template. Nếu bỏ qua, SearXNG sẽ ghi một dòng log rồi thoát với status 1, vì webapp.py so sánh key với giá trị trong template trước khi phục vụ bất kỳ request nào:

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

Kiểm tra này bị bỏ qua khi general.debug là true. Vì vậy instance có thể chạy bình thường trong debug session nhưng lại không khởi động dưới systemd hoặc trong container. Nếu container restart liên tục và có dòng đó trong docker compose logs, nguyên nhân là kiểm tra này đang thất bại, không phải image bị hỏng.

Limiter là thành phần mới và cần Valkey

Searx không có rate limiting bên trong ứng dụng. Các instance Searx public thường đặt các service riêng ở phía trước: filtron để lọc request và morty để proxy nội dung kết quả. Cả hai repository đều không có commit nào kể từ January 2023: commit cuối của filtron là trong tháng đó, còn commit cuối của morty là từ April 2021.

SearXNG tự xử lý các chức năng này. Rate limiting và bot detection nằm trong limiter, được bật bằng server.limiter. Tính năng này là false trong các giá trị mặc định được phát hành và là true trong template của installer. Nó cần một database Valkey để lưu các counter. Valkey là một fork của Redis, và Ubuntu 24.04 có package cho Valkey:

sudo apt install -y valkey-server

server:
  limiter: true

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

Các hướng dẫn được viết trước lần đổi tên đó sẽ cấu hình một block redis:. Vì vậy hãy lấy key name từ tài liệu limiter hiện tại. Tinh chỉnh chi tiết nằm trong file thứ hai, /etc/searxng/limiter.toml, và server.public_instance: true bật bot detection nghiêm ngặt hơn mà một instance public cần, bao gồm phương thức link token. Kết quả nhìn thấy là một số request sẽ nhận HTTP 429 thay vì kết quả tìm kiếm, kể cả request của bạn nếu bạn viết script gọi instance. Nội dung này có trang riêng tại đây: vì sao instance SearXNG trả về 429 Too Many Requests.

Engine tự suspend và timeout dài

Khi một upstream service trả về CAPTCHA hoặc trang rate limit, SearXNG sẽ raise một typed exception và ngừng gửi request đến engine đó trong một khoảng thời gian cố định, thay vì retry đến khi bị block. Các giá trị mặc định nằm trong searx/settings.yml, bên dưới search.suspended_times. Đây là 6 giá trị được công bố tính đến October 2026:

Biểu đồSearXNG 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

Dữ liệu đằng sau biểu đồ này

[
  {
    "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"
  }
]

Một phản hồi access denied thông thường sẽ suspend engine đó trong 180 giây. CAPTCHA sẽ suspend engine trong 3,600 giây. Cloudflare CAPTCHA sẽ suspend engine trong 1,296,000 giây, tức fifteen days, còn Google reCAPTCHA sẽ suspend engine trong 604,800 giây, tức one week. Các giá trị dài này là có chủ đích, vì tiếp tục request sau khi service đã đánh dấu địa chỉ là nguyên nhân khiến IP của instance bị block vĩnh viễn.

Trong thời gian engine bị suspend, trang kết quả sẽ bỏ qua engine đó và hiển thị nó trong sidebar block có tiêu đề "Messages from the search engines", còn /stats/errors liệt kê những engine bị lỗi. Một instance mới trả về ít kết quả thường đang gặp tình trạng này, không phải do cài đặt bị hỏng.

JSON API mặc định bị tắt

Giá trị mặc định được phát hành là formats: [html] và không có gì khác, nên API mà mọi script cần sẽ bị đóng cho đến khi bạn bật nó.

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

Lệnh đó in ra 403, vì search route gọi flask.abort(403) khi format được yêu cầu không nằm trong search.formats. Thêm format rồi restart service:

search:
  formats:
    - html
    - json

File settings của searx hoàn toàn không có key formats, nên JSON output chỉ cần gọi là có. Mọi script và snippet từ thời đó đều giả định như vậy, và failure mode là một lỗi 403 trống, không có giải thích. Nếu bạn kết nối instance với tooling, cung cấp cho agent một endpoint SearXNG để tìm kiếm bắt đầu từ setting này.

Vì sao các hướng dẫn Searx được sao chép nguyên văn đều lỗi

Mỗi dòng dưới đây đều xuất hiện trong các hướng dẫn vẫn còn được xếp hạng cao. Trên bản cài đặt hiện tại, mỗi dòng đều lỗi hoặc gây hiểu nhầm.

sudo apt install searx trên Ubuntu 24.04 dừng tại E: Unable to locate package searx vì package này được phát hành lần cuối trong 23.10 và đã bị xóa khỏi 24.04 trước khi phát hành.
pip install searx chạy thành công và cài bản 0.17.0 từ tháng 7 năm 2020. Không có cảnh báo nào cho biết bản này có trước thời điểm fork.
git clone https://github.com/asciimoo/searx vẫn hoạt động vì GitHub chuyển hướng từ tên owner cũ. Lệnh này checkout default branch hiện tại, nơi có một commit tài liệu từ tháng 5 năm 2026 nằm trên phần application code đã ngừng thay đổi từ tháng 4 năm 2023.
Các bước chỉnh sửa searx/settings.yml trong source tree không có tác dụng trên SearXNG vì SearXNG đọc /etc/searxng/settings.yml.
Các bước cài filtron hoặc morty đang dựng lại những thành phần mà SearXNG đã tích hợp sẵn.
URL redis: dành cho limiter chậm hơn key hiện tại valkey: một lần đổi tên.

Các hướng dẫn SearXNG cũng nhanh lỗi thời. Clone URL là cách nhanh nhất để xác định tuổi của một hướng dẫn. Các compose file trước đây nằm trong một repository searxng-docker riêng. Repository đó hiện đã được archive, lần push cuối là vào tháng 3 năm 2026, và các file đã được chuyển vào container/ trong main repository. Lệnh quickstart cho container hiện tại trong tài liệu là:

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

Chỉnh sửa .env trước lệnh cuối cùng. Image ánh xạ các biến môi trường vào các settings key, nên SEARXNG_SECRET trở thành server.secret_key và SEARXNG_BASE_URL trở thành server.base_url. Cách cài đặt host bằng script là một quy trình khác nhưng cho cùng kết quả:

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

Lệnh này tạo user searxng, virtual environment tại /usr/local/searxng và service uWSGI. Đây là cấu hình tham chiếu trong tài liệu SearXNG. Phần hướng dẫn chi tiết hơn cho quy trình này là cài đặt SearXNG trên VPS của bạn.

Instance public hoặc instance tự quản lý

Instance public là server của người khác terminate kết nối TLS (transport layer security) của bạn, nên phần mềm trên đó đọc được truy vấn của bạn dưới dạng plain text. Tài liệu chính thức của SearXNG nêu rõ vấn đề trust: bạn phải tin administrator, và không thể biết request có bị ghi log, tổng hợp hoặc chuyển cho bên thứ ba hay không. Danh sách những gì có thể bị nhìn thấy khá ngắn và đầy đủ. Stack của operator có thể thấy nội dung truy vấn, thời gian, địa chỉ IP gửi request, user agent của browser và preference cookie chứa các thiết lập của bạn. Operator cũng kiểm soát code, nên mọi patch họ áp dụng sẽ chạy trên mỗi lần bạn search ở đó.

Một thiết lập mặc định khiến việc ghi log ngoài ý muốn dễ xảy ra hơn. Searx gửi search dưới dạng POST. SearXNG phát hành method: "GET", kèm chú thích rằng POST giữ search query khỏi browser history nhưng gây ra vấn đề về khả năng sử dụng. Với GET, query nằm trong request line, nên mặc định nó được ghi vào reverse proxy access log và browser history. Đây là hành vi thông thường của web server. Bạn nên biết điều này trước khi chọn server của ai sẽ xử lý truy vấn.

Chạy instance của riêng bạn chỉ chuyển trust sang nơi khác, chứ không loại bỏ trust. Bạn kiểm soát code và log. Nếu không muốn công khai hostname hoặc TLS certificate cho một máy chỉ có một user, truy cập qua onion service v3 sẽ giữ instance ngoài public DNS, trong khi bạn vẫn có thể truy cập từ bất kỳ đâu. Đổi lại, upstream engine sẽ thấy một địa chỉ cho tất cả search của bạn. Trên instance chỉ có một user, mọi query đều truy ngược về bạn thay vì hòa vào một nhóm đông người. Một instance public có nhiều traffic tạo ra nhóm người dùng đó và lấy quyền kiểm soát log khỏi bạn. Hãy chọn thuộc tính mà bạn quan tâm. Nếu muốn xem toàn bộ danh sách rủi ro trước, SearXNG có an toàn để sử dụng không sẽ trình bày vấn đề này. Lịch sử vị trí cũng cần được cân nhắc tương tự, nhưng mức độ rủi ro cao hơn, vì một điện thoại báo vị trí suốt ngày tiết lộ nhiều thông tin hơn bất kỳ search log nào. so sánh các công cụ theo dõi vị trí tự host là nơi nên bắt đầu nếu bạn muốn lưu dữ liệu đó trên một box do mình kiểm soát.

Một lưu ý thực tế khi dùng VPS. Dải địa chỉ của datacentre bị gắn cờ nhanh hơn kết nối gia đình, nên instance mới có thể gặp CAPTCHA trên một số engine chỉ sau vài lần search đầu tiên. Đó là hành vi suspension ở phần trên đang hoạt động, không phải lỗi cấu hình. Nếu các engine đó tiếp tục bị block sau khi suspension hết hạn, đọc lỗi thực tế trước khi thay đổi bất kỳ thứ gì sẽ giúp bạn không phải đoán cách khắc phục.

Nếu bạn đang chạy một instance Searx

Không có gì bị hỏng ngay trong ngày bạn đọc bài này. Máy chủ vẫn hoạt động cho đến khi thay đổi từ upstream làm hỏng một engine khác, và sau đó nó sẽ không hoạt động nữa. Hãy lên kế hoạch chuyển đổi và đừng copy file cấu hình cũ sang. Hãy bắt đầu từ template của SearXNG, sau đó chỉ thêm lại những gì bạn đã chủ động thay đổi: tên instance, safe_search, các engine bạn đã bật hoặc tắt theo tên, và các thiết lập mặc định của giao diện. Tên engine và các tùy chọn đã thay đổi trong bản fork, vì vậy hãy kiểm tra từng cái với tài liệu hiện tại thay vì giả định rằng key đó vẫn tồn tại. Các quy tắc Filtron và URL morty không có tương đương, vì các tác vụ đó đã được tích hợp vào bên trong ứng dụng.

Hãy chạy instance mới trên một cổng khác trong khi instance cũ vẫn đang hoạt động. Nó hoạt động bình thường khi trang chủ trả về mã 200, một lượt tìm kiếm trả về kết quả từ nhiều hơn một engine, và /stats/errors trống hoặc chỉ liệt kê các lỗi mà bạn hiểu rõ. Sau đó, hãy chuyển hướng reverse proxy sang và dừng service cũ lại.

FAQ

Searx đã chết vào năm 2026 chưa?

Repository chưa bị lưu trữ, nên bạn vẫn có thể clone nó, nhưng dự án không còn được bảo trì. Commit code cuối cùng được push vào tháng 4 năm 2023, và README có dòng “Searx is no longer maintained.” Hãy tự kiểm tra bằng curl -s https://api.github.com/repos/searx/searx | jq -r '.pushed_at' rồi đọc các commit message gần đây, vì ngày push riêng lẻ có thể chỉ là ngày sửa tài liệu. Với một metasearch engine, việc không được bảo trì có nghĩa là chất lượng kết quả sẽ tự giảm theo thời gian, vì mỗi module engine đều phụ thuộc vào một upstream site liên tục thay đổi.

Tôi còn có thể cài Searx bằng apt hoặc pip không?

Không trên các hệ thống hiện tại, và những nơi vẫn cài được cũng không còn hữu ích. Ubuntu đóng gói searx lần cuối trong bản 23.10 với version 1.1.0, còn bản LTS cuối cùng có gói này là 22.04 với version 1.0.0. Gói này bị xóa khỏi 24.04 trước khi phát hành, nên sudo apt install searx trên 24.04 trả về E: Unable to locate package searx. Debian phát hành 1.1.0 trong Debian 12 và loại gói này khỏi testing vào tháng 10 năm 2023, nên Debian 13 không có package. PyPI vẫn cung cấp mọi bản phát hành searx, và bản mới nhất là 0.17.0 từ tháng 7 năm 2020, cũ hơn chính fork này. Thay vào đó, hãy cài SearXNG.

File settings.yml cũ của searx có hoạt động trong SearXNG không?

Không. Hãy chép các giá trị, không chép cả file. SearXNG đọc /etc/searxng/settings.yml và yêu cầu use_default_settings: true ở đầu file, nên file của bạn hoạt động như một lớp override trên các giá trị mặc định đi kèm. File searx cũ là một cấu hình đầy đủ với các tên key khác nhau, đồng thời không có limiter, block valkey và list formats. Hãy bắt đầu từ template tại utils/templates/etc/searxng/settings.yml rồi thêm lại từng thay đổi một.

Vì sao instance SearXNG của tôi trả về ít kết quả hơn instance public?

Một số engine bị tạm ngưng. Khi engine trả về CAPTCHA hoặc trang rate limit, SearXNG dừng truy vấn engine đó trong một khoảng thời gian cố định, từ 180 giây đối với một lần từ chối thông thường đến 1,296,000 giây đối với CAPTCHA của Cloudflare. Trang kết quả hiển thị thông tin này trong mục “Messages from the search engines”, còn /stats/errors liệt kê các lỗi kèm nguyên nhân. Địa chỉ datacenter bị gắn cờ sớm hơn kết nối gia đình, nên instance mới trên VPS thường gặp tình trạng này ngay từ đầu.

Tôi nên dùng instance SearXNG public hay tự chạy instance riêng?

Hãy tự chạy nếu bạn muốn kiểm soát code và log, đồng thời chấp nhận việc các upstream engine sẽ thấy một địa chỉ duy nhất cho mọi truy vấn của bạn. Hãy dùng instance public nếu việc trộn truy vấn của bạn với truy vấn của người khác quan trọng hơn việc biết những gì được ghi vào log. Trên một instance public, operator có thể thấy nội dung truy vấn, thời gian, địa chỉ IP và user agent của bạn, đồng thời có thể thay đổi code bất cứ lúc nào. Bạn không thể xác minh chính sách logging được công bố từ bên ngoài.

#searxng#searx#search #privacy #tự lưu trữ