SearXNG có an toàn không? Nó thực sự che giấu gì

SearXNG có an toàn không? Câu trả lời ngắn gọn

SearXNG an toàn theo một hướng và không an toàn theo hướng khác. Vì vậy, câu hỏi “SearXNG có an toàn không” chỉ có câu trả lời sau khi bạn xác định mình muốn ẩn khỏi ai. SearXNG là một công cụ metasearch: nó nhận truy vấn của bạn, gửi truy vấn đó đến Google, Bing, DuckDuckGo và các công cụ khác mà bạn đã bật, rồi gộp kết quả trả về thành một trang kết quả. Các công cụ tìm kiếm nhìn thấy instance. Instance nhìn thấy bạn.

Trên một public instance do người lạ vận hành, người đó nhận được mọi truy vấn bạn nhập ở dạng plain text. Không thông tin nào trên trang giới thiệu của họ có thể chứng minh họ xử lý dữ liệu đó như thế nào. Trên server riêng của bạn, các công cụ tìm kiếm upstream nhìn thấy địa chỉ của server thay vì địa chỉ nhà bạn. Việc thay thế này là toàn bộ câu chuyện về privacy, và giá trị của nó chỉ tương đương với mức độ an toàn của server đang chạy instance.

Không phần nào trong cơ chế này che giấu hoạt động tìm kiếm của bạn khỏi network của chính bạn. Nhà cung cấp dịch vụ Internet (ISP) vẫn thấy kết nối đến instance. DNS (domain name system) resolver của bạn vẫn thấy hostname. Hãy ghi nhớ ranh giới này khi đọc phần còn lại.

SearXNG thay đổi gì đối với một request tìm kiếm

Khi tìm kiếm trực tiếp trên Google, Google nhận được địa chỉ IP, cookie, header User-Agent và trang bạn truy cập trước đó. Tất cả thông tin này được gắn với một profile tồn tại lâu hơn session. SearXNG đứng ở giữa. Tài liệu của SearXNG mô tả 2 việc nó thực hiện: “xóa dữ liệu riêng tư khỏi các request gửi đến dịch vụ tìm kiếm” và “tạo một profile trình duyệt ngẫu nhiên cho mỗi request”. Cookie của bạn không bao giờ được chuyển tiếp đến engine. Preferences được lưu trong chính trình duyệt của bạn thay vì trong một account trên server.

Mặc định có 2 response header được gửi đi, và cả 2 đều có tác dụng thực tế:

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

Referrer-Policy: no-referrer có nghĩa là khi bạn click vào một kết quả, site đích không bao giờ biết trang tìm kiếm nào đã chuyển bạn đến đó, vì trình duyệt bỏ qua header Referer. X-Robots-Tag: noindex, nofollow ngăn instance và các trang kết quả của nó xuất hiện trong search index.

Điều SearXNG không thay đổi là chính query. Query đến instance đầy đủ và có thể đọc được, vì TLS (bảo mật tầng truyền tải) được terminate tại đó. Mọi điểm bên dưới đều xuất phát từ một thực tế này.

Trên instance public, operator thấy mọi query

Tài liệu chính thức của dự án nói rất rõ: người dùng instance public “phải tin operator của instance đó” và không thể biết “request của họ có được ghi log, tổng hợp, rồi gửi hoặc bán cho bên thứ ba hay không”. Tuyên bố không lưu log trên landing page chỉ là một tuyên bố. Từ bên ngoài không có cách nào kiểm tra, nên bạn chỉ có thể tin hoặc không dùng.

Ghi log cũng là cách dễ xảy ra nhất, vì cấu hình mặc định được phát hành đưa query vào URL:

server:
  method: "GET"

Với GET, query được gửi dưới dạng ?q=... trong request line. Mọi reverse proxy thông thường đều ghi request line đó vào access log, nên query được lưu lại mà không cần ai chủ động quyết định ghi chúng:

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

Trên instance của bạn, hãy tự kiểm tra:

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

Các tìm kiếm của bạn nằm trong đó vì format log combined của nginx ghi $request, tức toàn bộ request line bao gồm cả query string. SearXNG không có quyền quyết định việc này. Chuyển instance sang method: "POST" sẽ đưa query vào request body, nên query không còn xuất hiện trong access log và browser history. Tài liệu cũng nêu rõ POST có những nhược điểm “hạn chế nghiêm trọng tính dễ sử dụng đối với người dùng cuối”, chủ yếu liên quan đến nút quay lại của trình duyệt. Đây là một đánh đổi có chủ đích.

Điều này dẫn đến 2 hệ quả đối với mọi instance public. Operator có thể đọc query của bạn, dù họ có chủ định thu thập chúng hay không. Backup hoặc một vụ breach cũng có thể làm lộ chính log đó.

Tự chạy trên VPS: các engine thấy server của bạn thay vì thấy bạn

Chạy instance riêng trên VPS (virtual private server) giúp thay đổi điều này một cách rõ ràng. Google không còn nhận địa chỉ IP tại nhà của bạn cùng với truy vấn. Nó nhận địa chỉ IP của server cùng với truy vấn. Google không thể liên kết truy vấn đó với tài khoản bạn đang đăng nhập, điện thoại của bạn hoặc profile quảng cáo gắn với kết nối Internet của gia đình bạn. Phần triển khai được trình bày trong hướng dẫn chạy instance SearXNG riêng trên VPS.

Cần hiểu rõ những gì không thay đổi. Các engine vẫn thấy nội dung truy vấn, thời điểm, ngôn ngữ và khu vực bạn yêu cầu, cùng mẫu hình của mọi nội dung bạn tìm kiếm trong nhiều tháng, tất cả được gom dưới một địa chỉ ổn định. Nếu bạn là người dùng duy nhất, địa chỉ đó tạo thành một luồng dữ liệu riêng theo từng người nhưng không có tên định danh. Muốn phá vỡ việc gom nhóm này, instance phải truy cập các engine thông qua outbound proxy hoặc Tor. SearXNG hỗ trợ cả hai cách, nhưng đây là một phần công việc riêng.

Những gì ISP, resolver và nhà cung cấp hosting của bạn vẫn thấy

Bốn bên quan sát không bị ảnh hưởng bởi những thay đổi này.

• ISP của bạn thấy một kết nối TLS đến địa chỉ IP của instance và thấy hostname trong trường SNI (server name indication). Trường này được gửi dưới dạng plaintext trong quá trình handshake. ISP không thấy query.
• DNS resolver của bạn thấy yêu cầu phân giải hostname đó. Dùng sudo tcpdump -ni any port 53 trên client để theo dõi khi bạn tải trang; yêu cầu bản ghi A cho instance sẽ xuất hiện.
• Nhà cung cấp VPS vận hành phần cứng, nên họ có thể đọc disk và memory của virtual machine. Mã hóa disk bên trong VM thuê không loại bỏ được vấn đề này, vì hệ thống đang chạy vẫn giữ key.
• Bất kỳ ai có quyền root trên instance đều thấy mọi thứ. Người đó có thể là bạn hoặc bất kỳ ai đột nhập vào sau này.

Có một bên nữa mà nhiều người quên. Các request outbound của server hiển thị trên network của chính server, nên nhà cung cấp có thể thấy máy của bạn cả ngày kết nối đến Google và Bing. Đây là traffic pattern chứ không phải query, nhưng nó vẫn tiết lộ thông tin.

Đây là lúc câu hỏi về VPN xuất hiện. VPN (virtual private network) chuyển phần quan sát của ISP sang cho công ty VPN. VPN không thay đổi gì đối với operator của instance và cũng không thay đổi gì đối với các search engine, vì các engine kết nối đến server của bạn chứ không kết nối trực tiếp đến bạn. Hai mô hình này được so sánh đầy đủ trong phần phân tích VPS và VPN.

Vì sao SearXNG chặn bạn và 429 thực sự có nghĩa gì

Hai sự kiện khác nhau đều thường được mô tả là “SearXNG đã chặn tôi”, nhưng cách xử lý của chúng khác nhau.

Trường hợp đầu tiên là limiter của chính bạn trả về HTTP 429. Đây là cơ chế bảo vệ chống bot của SearXNG và mặc định đang tắt:

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

Tính đến tháng 8 năm 2026, limiter cần một database Valkey và đọc các rule từ /etc/searxng/limiter.toml. Nếu người lạ thực sự sử dụng máy này, hãy đặt server.public_instance: true vì mặc định nó là false và kiểm soát hành vi dành cho public use.

Limiter chạy nhiều probe. http_user_agent xem request không có User-Agent hoặc User-Agent khớp với các tool phổ biến như curl và wget là bot. http_accept xem request có header Accept không chứa text/html là bot. link_token đánh dấu client là đáng ngờ nếu client không bao giờ fetch URL /client<token>.css mà browser thực thường tải. Khi một probe kích hoạt, SearXNG trả về 429 và ghi một dòng ERROR vào logger botdetection.

Vì vậy, lệnh này fail đúng như thiết kế:

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

curl gửi User-Agent: curl/8.5.0 và Accept: */*, nên hai probe cùng khớp một lúc. Vì vậy script và AI agent nhận 429 từ một instance vẫn hoạt động bình thường trong browser. Đây là vấn đề cần xử lý trước khi trỏ search skill của agent vào instance của bạn. Toàn bộ nguyên nhân và setting nằm trong hướng dẫn về rate limit và lỗi 429 của SearXNG.

Có một bẫy về limiter cần nêu rõ. Khi chạy sau reverse proxy, SearXNG nhìn thấy địa chỉ của proxy thay vì địa chỉ của visitor, trừ khi proxy đó được tin cậy:

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

Danh sách mặc định bao gồm proxy chạy trên cùng host. Proxy trong một Docker network riêng sẽ gửi request từ địa chỉ như 172.18.0.5. Địa chỉ này không nằm trong danh sách, nên mọi visitor bị tính là một client và user đầu tiên có nhiều request sẽ khóa tất cả những người khác. Hãy thêm subnet đó vào trusted_proxies.

Trường hợp block thứ hai xảy ra ở upstream. Một engine nhận định địa chỉ datacenter đang chạy nhiều search là scraper và ngừng trả lời server của bạn. Bạn không nhận 429 trong trường hợp này. Bạn nhận một results page không có kết quả của engine đó, kèm một lỗi được ghi nhận cho engine. Sau nhiều lần fail, SearXNG sẽ tạm suspend engine đó. Nguyên nhân nằm ở địa chỉ mà VPS của bạn sử dụng, nên cách xử lý là chọn engine khác và chờ, không phải chỉnh limiter.

Chia sẻ một instance với người lạ giúp ích hay gây hại?

Cả hai, theo hai hướng ngược nhau, nên câu trả lời có vẻ khó xác định. Tính ẩn danh đến từ hiệu ứng đám đông. Trên một instance public đông người, query của bạn đi ra từ cùng một địa chỉ với query của hàng nghìn người khác, nên không engine nào có thể tách query của bạn khỏi toàn bộ nhóm. Trên instance chỉ dành cho một người, mọi query từ địa chỉ đó đều là của bạn. Các engine nhận được một luồng query sạch của một người, nhưng không kèm tên.

Ở phía operator thì ngược lại. Một đám đông lớn đồng nghĩa với việc một người lạ nắm giữ plain text query của cả nhóm, bao gồm query của bạn. Với máy chủ riêng, bạn nắm giữ query của mình và không có query của người khác.

Vì vậy, hãy chọn dựa trên mối đe dọa thực tế. Nếu bạn lo về việc lập hồ sơ quảng cáo và tracking giữa các site, đám đông xử lý tốt vấn đề đó và rủi ro từ operator thấp. Nếu bạn lo một người hoặc công ty cụ thể có thể đọc một search cụ thể bạn đã thực hiện, đám đông hoàn toàn không giúp được, vì operator nhìn thấy plain text. Một lựa chọn cân bằng là dùng một instance cho một nhóm nhỏ những người bạn biết. Bạn có một đám đông nhỏ và một operator mà bạn có thể xác minh, vì operator chính là bạn.

Kết quả SearXNG có tốt hơn Google không?

Không. SearXNG không có index riêng, nên mọi kết quả trên trang đều đến từ một engine upstream. Chất lượng tối đa chỉ bằng chất lượng của các engine bạn đã bật. Nếu tắt Google và Bing, chất lượng sẽ giảm ngay trong ngày hôm đó, vì phần lớn phạm vi bao phủ web nói chung đến từ hai engine này.

Điểm thay đổi là cách hệ thống xử lý truy vấn của bạn. Không có thành phần nào xây dựng hồ sơ quảng cáo từ truy vấn, và không có thành phần nào sắp xếp lại kết quả dựa trên những gì bạn đã nhấp vào tuần trước. Điều này có cả mặt lợi và mặt hại, vì cá nhân hóa cũng cung cấp ngữ cảnh địa phương. Một truy vấn như "pharmacy open now" sẽ cho kết quả kém hơn khi đi qua SearXNG, vì engine không có tín hiệu vị trí nào cho server của bạn ngoài datacenter nơi server đang đặt. Khi cần kết quả địa phương, hãy đặt region trong phần preferences.

Hai thiết lập quyết định mức độ instance của bạn làm lộ thông tin trong khi bạn đọc kết quả. image_proxy mặc định là false, nên thumbnail được tải trực tiếp từ các site lưu trữ chúng và các site đó nhìn thấy địa chỉ của browser của bạn. Đặt image_proxy: true sẽ chuyển thumbnail qua instance, nhưng làm tăng mức dùng bandwidth và memory. Ngoài ra, formats chỉ được phát hành với html, nên request JSON (JavaScript object notation) sẽ bị từ chối với lỗi 403 Forbidden:

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

Bật json trên một instance public đồng nghĩa với việc bạn đã công khai một scraping API miễn phí. Đây là cách nhanh nhất khiến địa chỉ của server bị các engine mà bạn phụ thuộc chặn. Hãy tắt tùy chọn này hoặc đặt nó phía sau authentication.

Ranh giới của quyền riêng tư với SearXNG

SearXNG ẩn danh tính của người gửi truy vấn khỏi các công cụ tìm kiếm. Nó không ẩn hoạt động của bạn khỏi mạng. Điều đó tạo ra 4 giới hạn.

• Lưu lượng của bạn không thay đổi ở bất kỳ đâu ngoài ô tìm kiếm. Mọi hoạt động khác của máy vẫn rời khỏi mạng của bạn như trước.
• Một người dùng trên một server là một định danh ổn định đối với mọi công cụ tìm kiếm. Định danh này không chứa tên, và đó là toàn bộ lợi ích.
• Operator của bất kỳ instance nào cũng đọc được truy vấn dưới dạng plain text. Tự vận hành instance là cách duy nhất để bạn xác minh điều này.
• Access log của chính bạn có thể dựng lại bản ghi mà bạn đang cố tránh tạo ra. Hãy đọc chúng và chuyển sang method: "POST" nếu bạn muốn các log đó vẫn trống.

SearXNG chỉ chuyển vị trí của observer. Nó không loại bỏ việc bị quan sát. Hãy xác định observer mà bạn không muốn tin cậy, chọn instance phù hợp, và đừng xem search front end là phần mềm cung cấp anonymity.

FAQ

Dùng SearXNG trên một instance công khai có an toàn không?

Dịch vụ này an toàn trước các công cụ tìm kiếm, nhưng không an toàn trước người vận hành. Truy vấn của bạn đến server đó dưới dạng plain text. Tài liệu của dự án nói rằng người dùng "phải tin tưởng administrator của instance đó" và không thể biết "các request của họ có bị ghi log, tổng hợp, gửi hoặc bán cho bên thứ ba hay không". Với giá trị mặc định được cung cấp là method: "GET", truy vấn cũng xuất hiện trong access log của reverse proxy như một phần của request line, dù operator có muốn ghi lại hay không. Hãy dùng instance công khai cho các tìm kiếm thông thường khi điều bạn lo ngại là việc lập hồ sơ quảng cáo. Đừng nhập vào đó bất kỳ nội dung nào mà bạn không sẵn sàng giao cho chủ sở hữu instance.

SearXNG có che giấu các tìm kiếm của tôi với nhà cung cấp Internet không?

Nội dung truy vấn được che giấu. Hoạt động kết nối thì không. Nhà cung cấp của bạn thấy một kết nối TLS đến địa chỉ của instance và hostname trong trường SNI dạng plain text của quá trình handshake. DNS resolver của bạn cũng thấy lookup đến hostname đó. Không bên nào thấy bạn đã tìm gì, vì kết nối được mã hóa. SearXNG không phải là VPN và không bảo vệ bất kỳ hoạt động nào khác trên máy của bạn.

Vì sao SearXNG trả về lỗi 429?

Lỗi 429 do limiter của chính instance tạo ra. Đây là cơ chế bảo vệ chống bot, không phải thông báo từ Google. Probe của nó đánh dấu request có header Accept thiếu text/html, cùng User-Agent chưa được set hoặc khớp với các tool như curl và wget. Probe thứ ba, link token, đánh dấu client không bao giờ fetch URL /client<token>.css mà trình duyệt tải. Nếu reverse proxy không được khai báo trong trusted_proxies của /etc/searxng/limiter.toml, mọi visitor đều bị tính là cùng một client. Khi đó, một user có lưu lượng cao có thể chặn những user còn lại. Nếu upstream engine chặn server của bạn, kết quả từ engine đó chỉ biến mất khỏi trang và bạn sẽ không nhận được lỗi 429.

Tự host SearXNG có làm kết quả tìm kiếm kém hơn không?

Đôi khi có, vì 2 lý do cần lưu ý. Kết quả đến từ upstream engine. Vì vậy, nếu các engine giới hạn địa chỉ datacenter, sẽ có ít engine trả lời hơn và trang kết quả sẽ ít thông tin hơn. Ngoài ra, ranking được cá nhân hóa không còn nữa. Điều này loại bỏ việc sắp xếp lại theo quảng cáo nhưng cũng loại bỏ ngữ cảnh địa phương, nên các tìm kiếm phụ thuộc vị trí có thể trả về kết quả kém hơn cho đến khi bạn đặt region trong preferences.