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 nhưng 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 nói rõ mình đang che giấu hoạt động khỏi ai. SearXNG là một metasearch engine: nó nhận query của bạn, gửi query đó đến Google, Bing, DuckDuckGo và các engine 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 engine nhìn thấy instance. Instance nhìn thấy bạn.

Nếu dùng một public instance do người lạ vận hành, người đó nhận được mọi query bạn nhập dưới dạng plain text. Không nội dung 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ác engine 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ó phụ thuộc hoàn toàn vào 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 (internet service provider, ISP) vẫn thấy kết nối đến instance. DNS (domain name system) resolver vẫn thấy hostname. Hãy ghi nhớ giới hạn này khi đọc phần còn lại.

SearXNG thay đổi những gì trong một search request

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ả đều đượ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ả hai việc mà 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 browser profile 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 browser của bạn thay vì trong account trên server.

Hai response header được bật mặc định và đề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 nhấp 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ì browser không gửi 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à query. Query đến instance ở dạng đầy đủ và có thể đọc được, vì TLS (transport layer security) được terminate tại đó. Mọi điểm bên dưới đều bắt nguồn từ thực tế này.

Trên một instance public, operator nhìn thấy mọi query

Tài liệu của dự án nói rất rõ: người dùng instance public “phải tin tưởng administrator của instance đó”, và họ không thể biết “các request của mình 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 vẫn chỉ là một tuyên bố. Từ bên ngoài, không có cách nào kiểm tra điều đó, nên bạn chỉ có thể tin hoặc không dùng. Một số instance public còn chạy Searx gốc thay vì fork này. Điều đó đáng lưu ý vì Searx không có code commit nào kể từ năm 2023 và phần mềm tìm kiếm không còn được maintenance là thêm một thành phần mà bạn phải tin tưởng một cách mù quáng.

Ghi log cũng là lựa chọn dễ thực hiện nhất, vì default được cung cấp sẽ đặt query vào URL:

server:
  method: "GET"

Với GET, query được gửi dưới dạng ?q=... trong request line. nginx mặc định ghi request line này vào access log, nên query được ghi lại mà không cần ai chủ động quyết định ghi chúng. Caddy không ghi access log cho đến khi operator thêm directive log. Khi directive này được bật, URI trong log vẫn chứa query string nếu operator không lọc nó ra:

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 gửi bằng GET xuất hiện trong đó vì log format combined của nginx ghi $request, tức là toàn bộ request line, bao gồm cả query string. SearXNG không thể can thiệp vào việc này. Chuyển instance sang method: "POST" sẽ đưa query vào request body. Khi đó query không còn xuất hiện trong access log hoặc browser history. Tài liệu cũng nói 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 browser. Đây là một đánh đổi có chủ đích.

Có 2 hệ quả đối với mọi instance public. Operator có thể đọc query của bạn, dù họ không định thu thập chúng. Backup hoặc một vụ xâm nhập cũng có thể truy cập chính log đó.

Tự chạy trên VPS của bạn, các công cụ tìm kiếm sẽ thấy server thay vì bạn

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

Cần hiểu rõ những gì không thay đổi. Các công cụ tìm kiếm 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 toàn bộ dạng thức của mọi nội dung bạn tìm kiếm trong nhiều tháng, tất cả được nhóm 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 hoạt động riêng theo từng người, nhưng không chứa tên của bạn. Muốn phá vỡ việc gom nhóm này, instance phải truy cập các công cụ tìm kiếm thông qua outbound proxy hoặc Tor. SearXNG hỗ trợ cách này, nhưng đó là một phần việc riêng.

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

Bốn bên quan sát không bị ảnh hưởng bởi những việc 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. Nếu browser dùng DNS over HTTPS, lookup sẽ được mã hóa và gửi đến DoH resolver đó. Khi ấy, không có gì xuất hiện trên port 53 và DoH resolver là bên nhìn thấy hostname.
• Nhà cung cấp VPS vận hành phần cứng, nên có thể đọc disk và memory của virtual machine. Mã hóa disk bên trong một VM thuê không loại bỏ được điều này vì hệ thống đang chạy vẫn giữ key.
• Bất kỳ ai có root trên instance đều nhìn thấy mọi thứ. Người đó bao gồm bạn và bất kỳ ai xâm nhập được sau này.

Truy cập instance dưới dạng Tor onion service sẽ loại bỏ 2 điểm đầu tiên, vì không có hostname public để phân giải và không có trường SNI để đọc. Hướng dẫn thêm v3 onion service vào VPS trình bày cách thiết lập, cùng với những rò rỉ có thể liên kết địa chỉ đó trở lại public IP của server.

Còn một điểm 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 liên lạc với Google và Bing cả ngày. Đây là traffic pattern chứ không phải query, nhưng nó vẫn tiết lộ một phần thông tin.

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

Vì sao SearXNG chặn bạn và 429 thực sự có nghĩa là 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 cũ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ệ bot của SearXNG và mặc định đang tắt:

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

Từ tháng 10 năm 2026, limiter cần một cơ sở dữ liệu Valkey và đọc các rule từ /etc/searxng/limiter.toml. Đồng thời đặt server.public_instance: true nếu thực sự có người ngoài sử dụng máy này, vì mặc định nó là false và kiểm soát các hành vi dành cho môi trường public. Thiết lập này cũng tự bật limiter và buộc bật link_token, bất kể limiter.toml có giá trị gì.

Limiter chạy nhiều probe. http_user_agent xem request không có User-Agent hoặc 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ờ tải URL /client<token>.css mà trình duyệt thực tải. Khi một probe khớp, SearXNG trả về 429 và ghi block ở mức DEBUG. Vì vậy, với log level mặc định, một lần probe khớp thông thường hoàn toàn không ghi log. Các dòng ERROR chỉ dành cho trường hợp khớp block_ip và trường hợp thiếu cơ sở dữ liệu Valkey.

Vì vậy, lệnh này thất bại, và đó là hành vi đúng:

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: */*. Wildcard */* được tính là chấp nhận text/html, nên probe Accept vượt qua và probe User-Agent là probe khớp. curl vẫn bị bắt bởi nhiều probe vì các header bị bỏ qua: http_accept_encoding từ chối search không có gzip hoặc deflate trong Accept-Encoding, còn http_accept_language từ chối request không có Accept-Language. Đây là lý do script và AI agent nhận 429 từ một instance vẫn hoạt động bình thường trong trình duyệt. Đâ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à thiết lập được trình bày trong hướng dẫn về rate limit và lỗi 429 của SearXNG.

Có một lỗi cấu hình limiter phía sau reverse proxy cần được nêu riêng. Nếu proxy không được tin cậy, SearXNG sẽ thấy địa chỉ của proxy thay vì địa chỉ của người truy cập:

[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à cùng một client và user đầu tiên tạo nhiều traffic sẽ khóa truy cập của tất cả user khác. Hãy thêm subnet đó vào trusted_proxies.

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

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

Cả hai, nhưng theo hai hướng ngược nhau. Vì vậy 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 công cộng đô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ộ dữ liệu. 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 rõ ràng của một người, nhưng không kèm tên.

Với phía operator thì ngược lại. Một đám đông lớn có nghĩa là một người lạ nắm giữ các query dạng plain text của cả đám đông, bao gồm cả 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 theo mối đe dọa thực tế của bạn. Bạn lo bị lập hồ sơ quảng cáo và theo dõi liên site? Đám đông xử lý tốt vấn đề đó, còn rủi ro từ operator là nhỏ. Bạn lo một người hoặc công ty cụ thể có thể đọc một query cụ thể mà bạn đã chạy? Đá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 trung gian tốt 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 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 đó vì phần lớn phạm vi dữ liệu của 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ó 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" thường cho kết quả kém hơn qua SearXNG, vì engine không có tín hiệu vị trí nào về server của bạn ngoài datacenter nơi server đang chạy. Khi cần kết quả địa phương, hãy đặt region trong preferences.

Hai thiết lập quyết định mức độ instance làm lộ thông tin khi bạn đọc cá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. Đặt image_proxy: true sẽ định tuyến thumbnail qua instance, nhưng làm tăng mức sử dụng bandwidth và memory. Ngoài ra, formats chỉ được phát hành ở chế độ 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 các engine bạn phụ thuộc chặn địa chỉ của server. Hãy tắt nó hoặc đặt nó phía sau authentication.

Ranh giới của tính riêng tư mà SearXNG cung cấp

SearXNG che giấu người gửi truy vấn khỏi các công cụ tìm kiếm. Nó không che giấu hoạt động của bạn khỏi mạng của bạn. Từ đó có 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ạ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. Hãy đọc các log đó, và chuyển sang method: "POST" nếu bạn muốn chúng vẫn trống.

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

FAQ

SearXNG có an toàn khi dùng trên public instance không?

SearXNG an toàn trước các công cụ tìm kiếm nhưng không an toàn trước operator. Truy vấn của bạn đến server đó dưới dạng plain text. Tài liệu của dự án nêu rõ 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 cấu hình mặc định đi kèm là method: "GET", truy vấn cũng nằm trong request line. Vì vậy, nó sẽ xuất hiện trong access log của reverse proxy nếu proxy đó lưu log, như nginx mặc định vẫn làm, bất kể operator có muốn hay không. Hãy dùng public instance cho các tìm kiếm thông thường nếu điều bạn lo ngại là ad profiling. Không nhập vào đó bất kỳ nội dung nào mà bạn không sẵn sàng đưa cho chủ sở hữu instance.

SearXNG có ẩn các tìm kiếm của tôi khỏi nhà cung cấp Internet không?

Nội dung truy vấn được ẩn. Hoạt động truy cập thì không. Nhà cung cấp Internet 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 truy vấn phân giải hostname đó. Không bên nào trong số này thấy bạn đã tìm gì, vì kết nối được mã hóa. SearXNG không phải 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 đến từ limiter của chính instance. Đây là cơ chế chống bot, không phải thông báo từ Google. Các probe của nó đánh dấu request có header Accept thiếu text/html, cùng User-Agent chưa được đặt hoặc khớp với các tool như curl và wget. Search request cũng bị đánh dấu khi không có header Accept-Language, hoặc có header Accept-Encoding nhưng thiếu gzip hoặc deflate. Một probe khác, gọi là link token, đánh dấu client không bao giờ fetch URL /client<token>.css mà browser 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ó nhiều traffic có thể chặn toàn bộ 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 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 biết. Kết quả đến từ upstream engine. Vì vậy, nếu các engine throttle đị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, personalised ranking không còn. Đ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ỏ local intent. Vì vậy, các tìm kiếm phụ thuộc vào vị trí có thể cho kết quả kém hơn cho đến khi bạn đặt region trong preferences.