SearXNG 安全嗎？公開執行個體與自架伺服器

SearXNG 安全嗎？簡短答案

SearXNG 在某個方向上安全，在另一個方向上則不安全。因此，「SearXNG 安全嗎」這個問題，必須先說明你要向誰隱藏搜尋活動，才有答案。SearXNG 是中繼搜尋引擎：它會接收你的查詢，將查詢傳送給 Google、Bing、DuckDuckGo 以及你啟用的其他搜尋引擎，再把回傳結果合併成一個結果頁面。搜尋引擎看得到該執行個體。該執行個體看得到你。

如果使用陌生人執行的公開執行個體，對方會收到你輸入的每一則查詢，而且是純文字格式。對方網站的 about 頁面無法證明他們會如何處理這些資料。如果你使用自己的伺服器，上游搜尋引擎看到的是你伺服器的位址，而不是家中的位址。這項替換就是隱私保護的全部內容，而其價值完全取決於執行該服務的伺服器。

這不會讓你在自己的網路上隱藏搜尋活動。你的網際網路服務供應商（ISP）仍會看到你與該執行個體建立的連線。你的 DNS（domain name system）解析器仍會看到主機名稱。閱讀後續內容時，請記住這項界線。

SearXNG 如何變更搜尋請求

直接搜尋 Google 時，Google 會收到你的 IP 位址、cookie、User-Agent 標頭，以及你先前瀏覽的頁面；這些資料都會繫結至一個存續時間超過單次工作階段的個人檔案。SearXNG 位於兩者之間。其文件說明了它執行的兩項工作：「移除傳送至搜尋服務之請求中的私人資料」以及「為每個請求產生隨機瀏覽器個人檔案」。你的 cookie 絕不會轉送至搜尋引擎。你的偏好設定會儲存在自己的瀏覽器中，而不是伺服器上的帳戶。

預設會傳送兩個回應標頭，且兩者都會發揮實際作用：

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

Referrer-Policy: no-referrer 表示，當你按下搜尋結果時，目標網站不會得知是哪個搜尋頁面將你導向該網站，因為瀏覽器會省略 Referer 標頭。X-Robots-Tag: noindex, nofollow 則讓你的執行個體及其結果頁面不會出現在搜尋索引中。

SearXNG 不會變更的是查詢本身。查詢會以完整且可讀的形式抵達執行個體，因為 TLS（傳輸層安全性）會在該處終止。以下每一點都源自這項事實。

公開執行個體的營運者可以看到每個查詢

專案本身的文件明確指出：公開執行個體的使用者「必須信任該執行個體的管理員」，而且無法知道「自己的請求是否會被記錄、彙整，並傳送給第三方或出售給第三方」。首頁上的無日誌聲明只是聲明。從外部無法測試，只能選擇信任，否則就無法使用。部分公開執行個體仍執行原始的 Searx，而不是這個分支版本；這點很重要，因為 Searx 自 2023 年起就沒有任何程式碼提交，而未維護的搜尋軟體又增加了一項你必須盲目信任的內容。

記錄查詢也是最省力的做法，因為發布時的預設設定會將查詢放入 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（virtual private server）上執行自己的 instance，變化很容易說明。Google 不再隨查詢收到你的家用 IP 位址，而是收到你的伺服器 IP 位址。它無法將這次搜尋連結到你的已登入帳戶、手機，或附加在家用連線上的廣告設定檔。建置方式請參閱在 VPS 上執行自己的 SearXNG instance 指南。

但必須清楚哪些事情沒有改變。搜尋引擎仍會看到查詢文字、查詢時間、你要求的語言和地區，以及數月內所有搜尋內容的整體模式；這些資料都會歸在同一個穩定位址下。如果只有你一個人使用，該位址就會形成一串沒有姓名標示、但可對應到個人的資料流。若要打破這種歸併，instance 必須透過 outbound proxy 或 Tor 連線到搜尋引擎；SearXNG 支援這兩種方式，但這是另一項工作。

你的 ISP、DNS resolver 與主機仍可看見的資訊

以下 4 個觀察者不受上述措施影響。

• 你的 ISP 會看到連往該 instance IP 位址的 TLS 連線，也會看到 SNI（server name indication）欄位中的 hostname。此欄位會在 handshake 期間以明文傳送。ISP 看不到查詢內容。
• 你的 DNS resolver 會看到對該 hostname 的查詢。載入頁面時，可在 client 上使用 sudo tcpdump -ni any port 53 監看；此時會出現對該 instance 的 A record 請求。
• 你的 VPS provider 負責執行硬體，因此可以讀取虛擬機器的磁碟與記憶體。在租用的 VM 內進行磁碟加密也無法消除這項風險，因為執行中的系統持有金鑰。
• 在 instance 上擁有 root 權限的任何人都能看見所有內容。這包括你，也包括之後取得存取權的人。

透過 Tor onion service 連線至 instance，可以排除前 2 項觀察，因為不需要解析公開 hostname，也沒有可讀取的 SNI 欄位；在 VPS 上新增 v3 onion service 的操作指南涵蓋設定方式，以及原本可能將該位址連回伺服器公開 IP 的資訊洩漏問題。

還有一項常被忽略。你的伺服器對外發出的請求會在伺服器自身的網路上暴露，因此 provider 可以看到你的機器整天與 Google 和 Bing 通訊。這屬於 network traffic pattern，而不是查詢內容，但仍會透露一些資訊。

這就是 VPN 問題出現的地方。VPN（virtual private network）會把 ISP 所能看到的資訊，轉移為 VPN 公司所能看到的資訊。它不會改變 instance operator 所能看到的內容，也不會改變 engines 所能看到的內容，因為 engines 是與你的伺服器通訊，而不是與你通訊。兩者的正確比較請參閱VPS 與 VPN 的差異分析。

SearXNG 為何封鎖請求，以及 429 的真正含義

「SearXNG 封鎖了我」可能指兩種不同事件，處理方式也不同。

第一種是 SearXNG 自己的限制器以 HTTP 429 回應。這是 SearXNG 的機器人防護功能，預設為關閉：

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

截至 August 2026，限制器需要 Valkey 資料庫，並從 /etc/searxng/limiter.toml 讀取規則。如果確實有不特定使用者使用這台主機，也要設定 server.public_instance: true，因為它預設為 false，用來控制公用環境的行為。

限制器會執行數項檢查。http_user_agent 會將未設定 User-Agent，或 User-Agent 符合 curl、wget 等已知工具的請求視為機器人。http_accept 會將 Accept 標頭不包含 text/html 的請求視為機器人。link_token 會在用戶端從未擷取真實瀏覽器會載入的 /client<token>.css URL 時，將其標記為可疑。檢查觸發時，SearXNG 會回傳 429，並在其 botdetection logger 中寫入 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 agent 從某個 SearXNG instance 收到 429，但瀏覽器卻能正常使用。應先修正這項問題，再將 agent 的搜尋功能指向自己的 instance。完整的原因與設定請參閱SearXNG 速率限制與 429 錯誤指南。

有一個限制器陷阱值得特別說明。位於 reverse proxy 後方時，除非該 proxy 已受信任，否則 SearXNG 看到的是 proxy 的位址，而不是訪客的位址：

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

預設清單涵蓋與 SearXNG 位於同一台主機上的 proxy。位於不同 Docker network 的 proxy 會從類似 172.18.0.5 的位址傳入，但該位址不在清單中。因此，所有訪客都會被計為同一個用戶端，第一位流量較大的使用者就會讓其他人全部遭到封鎖。請將該子網路加入 trusted_proxies。

第二種封鎖發生在上游。某個引擎可能判定來自資料中心、且執行大量搜尋的位址是 scraper，然後停止回應你的伺服器。這種情況不會收到 429。你會收到結果頁面，但該引擎的結果會缺失，並在該引擎旁標示失敗；多次失敗後，SearXNG 也會暫停使用該引擎一段時間。原因在於 VPS 使用的位址，因此處理方式是更換引擎並等待，而不是修改限制器設定。

與陌生人共用同一個 instance，有幫助還是有害？

兩者皆是，而且方向相反，所以答案不容易一概而論。匿名性來自群體效果。在忙碌的 public instance 上，你的查詢會與數千名其他使用者的查詢使用同一個位址，因此任何搜尋引擎都無法從大量查詢中辨認出你的查詢。在單一使用者的 instance 上，來自該位址的每一筆查詢都是你的；搜尋引擎會收到一串乾淨的單一使用者查詢，但不會知道你的姓名。

營運者面臨的情況則相反。人數眾多的群體表示陌生人持有整個群體的明文查詢，其中也包括你的查詢。使用自己的主機時，你只持有自己的查詢，不會持有其他人的查詢。

因此，應根據你實際面臨的威脅做選擇。若你擔心廣告分析與跨網站追蹤，群體能有效降低這類風險，而營運者風險相對較小。若你擔心某個特定的人或公司讀取你執行的某一筆特定搜尋，群體完全無法提供幫助，因為營運者看得到原始文字。折衷做法是與幾位你認識的人共用一個 instance。你能取得小型群體的匿名效果，也能驗證營運者，因為營運者就是你自己。

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，就等於發布免費的 scraping API。這是讓你所依賴的引擎封鎖伺服器位址最快的方法。請保持停用，或將其置於驗證機制後方。

SearXNG 隱私防護的界線

SearXNG 會隱藏向搜尋引擎發出查詢的使用者身分，但不會隱藏你在網路上的活動。這會產生以下 4 項界線。

• 除了搜尋框以外，你的網路流量不會有任何變化。電腦執行的其他所有活動，都會與過去一樣離開你的網路。
• 對每個搜尋引擎而言，單一伺服器上的單一使用者都是穩定的識別項。這個識別項不包含姓名，而這就是全部的效益。
• 任何 instance 的 operator 都能以純文字讀取查詢內容。只有由你自行擔任 operator，才能驗證這一點。
• 你自己的存取日誌會重建你原本想避免留下的紀錄。請閱讀這些日誌；如果你希望日誌保持空白，請切換至 method: "POST"。

SearXNG 只是移動觀察者，並不會消除觀察。請先決定你在意哪一類觀察者，再選擇符合需求的 instance。不要把搜尋前端當成匿名軟體。

FAQ

SearXNG 在公開實例上使用是否安全？

對搜尋引擎而言是安全的，但對實例營運者而言並不安全。您的查詢會以純文字形式送達該伺服器，專案文件也指出，使用者「必須信任該實例的管理員」，而且無法得知「他們的請求是否會被記錄、彙整、傳送給第三方或出售給第三方」。在 method: "GET" 的預設設定下，無論營運者是否有意如此，查詢也會作為請求列的一部分，寫入反向代理的存取日誌。若您擔心的是廣告業者建立使用者輪廓，可將公開實例用於一般搜尋。請勿在其中輸入任何不願交給實例擁有者的內容。

SearXNG 會將我的搜尋內容對網際網路服務提供者隱藏嗎？

查詢文字會被隱藏，但活動本身不會。您的服務提供者可以看到通往該實例位址的 TLS 連線，以及握手期間明文 SNI 欄位中的主機名稱；DNS 解析器也會看到對該主機名稱的查詢。由於連線已加密，兩者都看不到您的搜尋內容。SearXNG 不是 VPN，也不會保護您電腦進行的其他活動。

為什麼 SearXNG 會傳回 429 錯誤？

429 來自實例本身的速率限制器，這是機器人防護機制，不是 Google 傳回的訊息。其探測機制會標記缺少 text/html 的 Accept 標頭，以及未設定或符合 curl、wget 等工具特徵的 User-Agent。第三項探測機制是連結權杖；如果用戶端從未擷取瀏覽器載入的 /client<token>.css URL，就會被標記。若反向代理未在 /etc/searxng/limiter.toml 的 trusted_proxies 中正確設定，所有訪客都會被視為同一個用戶端，因此一名忙碌的使用者就可能阻擋其他人。若是上游引擎封鎖您的伺服器，該引擎的結果只會從頁面中消失，完全不會出現 429。

自行代管 SearXNG 會讓我的搜尋結果變差嗎？

有時會，原因有兩個。結果來自上游引擎，因此如果引擎限制資料中心位址的流量，能回應的引擎就會減少，結果頁面也會變得較精簡。個人化排名也會消失；這會移除由廣告驅動的排序調整，也會移除本地搜尋意圖。因此，在偏好設定中指定地區前，具地區相關性的搜尋可能會得到較不精確的結果。