SearXNG VPS CAPTCHA 錯誤修正方法

SearXNG CAPTCHA 錯誤的含義

SearXNG CAPTCHA 錯誤來自您的執行個體查詢的搜尋引擎。您的伺服器向搜尋引擎要求結果，但搜尋引擎回傳挑戰頁面，而非搜尋結果。SearXNG 因回應中沒有可解析的內容，將該搜尋引擎記錄為錯誤。您的執行個體本身運作正常。您無法控制的機器判定這項請求看起來不像是由真人提出。

這項事實決定了以下所有修正方式。該判定是在搜尋引擎自己的硬體上做出的，因此 settings.yml 中的任何設定都無法覆寫它。您可以變更請求送出的位址、要查詢的搜尋引擎，以及某個搜尋引擎開始拒絕請求後執行個體的處理方式。

兩種看起來相同的故障，以及如何區分

第一種故障是您自己的 instance 對自己的瀏覽器回應 HTTP 429（請求過多）。這是 SearXNG limiter，也就是位於搜尋端點前方的 bot detection layer。它在您的主機上執行，設定也由您管理。對您自己的使用者回應 429 的 limiter 是另一個獨立問題，使用不同的設定，以下建議均不適用於該問題。

第二種故障發生在 upstream。結果頁面正常載入，但結果中缺少一個或多個 engine，或顯示錯誤通知。不是您的 instance 拒絕了請求，而是某個 engine 拒絕了您的伺服器。

• 頁面無法載入，或搜尋端點回應 429：檢查您的 limiter。
• 頁面可載入，但結果很少，或某個 engine 被標記為錯誤：檢查 upstream，並繼續閱讀。

這兩種故障可能同時發生在同一個 instance 上，也會互相影響，因為設定過於寬鬆的 limiter 會放行更多流量，導致您對外送出的查詢速率升高。請一次診斷一種故障。

為什麼 SearXNG 引擎在 VPS 上會回傳 CAPTCHA 錯誤，但在我的筆電上不會？

原因在於請求的來源位址。你的家用連線使用消費者 ISP（internet service provider）位址範圍，這些位址會隨時間由許多一般使用者共用。你的 VPS 使用資料中心位址範圍，而這些範圍已公開列出，任何人都能查出哪些位址屬於託管服務供應商。想要阻擋 scraper 的引擎，通常會先將來自託管服務範圍的請求視為可疑，因為這些範圍中的請求，極少是由使用瀏覽器的人類發出。

除了位址之外，還有其他因素會疊加影響。你的執行個體會針對每次使用者搜尋，向每個引擎送出一個請求。因此，即使使用者人數不多，來自單一位址的請求速率仍可能超過任何單一使用者會產生的速率。SearXNG 依設計不會與引擎維持 session，也不會攜帶長期 cookie，因此每個請求抵達時，後方都沒有可供引擎參考的歷史紀錄。此外，該位址可能帶有不是你造成的歷史紀錄，因為供應商會重新分配位址，而前一位租用者可能已使用該位址進行數月的 scraping。

拒絕請求本身不一定會呈現為明顯的失敗。引擎可能回傳 403、429，或回傳 HTTP 200，但在回應本文中提供驗證頁面。最後一種情況最容易造成誤判，因為檢查狀態碼會顯示引擎正常，但 SearXNG 卻從回應中找不到任何結果。因此，應讀取你自己執行個體的錯誤報告，而不是對引擎執行 curl 後只查看狀態列。

變更任何設定前，先查看執行個體回報的內容

以下每項修正都從發生錯誤的引擎名稱，以及執行個體記錄的原因開始。SearXNG 會提供這兩項資訊。/stats 頁面會列出各引擎的錯誤次數與可靠性；/stats/errors 則以 JSON 傳回錯誤詳細資訊，較容易保存，也方便下週比較。請使用平常存取此執行個體的瀏覽器開啟這些頁面。

容器日誌會在事件發生時記錄相同內容。這裡的服務名稱是容器文件所附 compose 檔案使用的名稱；如果你的名稱不同，請改用自己的服務名稱。

docker compose logs -f core

在持續監看日誌時，執行一個會失敗的搜尋。搜尋執行期間，你應該會看到失敗引擎的項目出現在日誌中。記下引擎名稱，以及執行個體列出的完整原因字串。不要從部落格文章（包括本文）複製引擎名稱。會對資料中心位址提出挑戰的引擎集合每月都可能變更；對你失敗的引擎，對本文作者使用的執行個體可能完全正常。

如果結果頁面完全沒有顯示錯誤，但結果數量很少，請檢查該引擎的 display_error_messages。它預設為 true；如果執行個體已將其關閉，就會隱藏你需要的那則訊息。

SearXNG 如何重試並暫停失敗的引擎

SearXNG 不會持續重試拒絕回應的引擎。失敗的引擎會被暫停；暫停期間會完全略過該引擎，因此故障引擎會變成無提示地消失的引擎。

這由兩層設定控制，兩者都位於 settings.yml 的 search: 下。貼上任何設定前，請先根據實際執行版本的設定文件確認這些鍵名，因為它們在不同版本之間曾經變更。截至 2026 年 9 月 2 日，預設值如下：

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400
    SearxEngineTooManyRequests: 3600
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

第一層處理逾時等一般故障。封鎖會從 ban_time_on_fail 秒開始，並隨每次連續失敗而延長，最多達到 max_ban_time_on_fail。預設上限為 2 分鐘，因此問題排除後，間歇性故障的引擎會在幾分鐘內自行恢復。

第二層處理本指南所說的故障。SearXNG 將回應辨識為 challenge 或拒絕，而不是一般錯誤時，會套用 suspended_times 中相符的項目，且這些數值大得多。86400 秒是完整 1 天。604800 是 1 週。1296000 是 15 天。以 cf_ 為前綴的鍵會在 challenge 被辨識為 Cloudflare challenge 時套用；以 recaptcha_ 為前綴的鍵則會在被辨識為 reCAPTCHA 時套用。

這就解釋了最浪費時間的症狀。你找到原因並修正問題，但引擎在數小時內仍然沒有回應。因為它仍處於暫停狀態。暫停狀態保存在執行中的程序內，因此重新啟動容器即可清除該狀態，下一次搜尋就會再次嘗試該引擎。這裡直接重新啟動即可；在無須重建映像的情況下開始操作前，最好先了解何時重新啟動已經足夠，以及何時需要重新建立容器。如果引擎在重新啟動後立即再次失敗，表示你的修正沒有生效。

每個引擎各自有一項設定需要特別注意。retry_on_http_error 會在引擎回應你列出的狀態碼時重試請求。對於正在封鎖你的引擎，重試會向已判定你的伺服器是 bot 的系統傳送更多網路流量。除非你要處理確實不穩定的引擎，否則請維持原設定。

SSH tunnel 上游文件的說明，以及它無法修正的問題

截至 2026 年 9 月 2 日，SearXNG 管理文件以手動建立 tunnel 的方式處理這個問題。你可以透過伺服器建立 SOCKS proxy，將桌面瀏覽器的流量導向該 proxy，然後手動完成驗證，而搜尋引擎看到的會是伺服器的位址。

ssh -q -N -D 8080 user@example.org

-D 8080 會在本機的 8080 埠開啟 SOCKS server，並透過 SSH connection 轉送流量。-N 不會執行遠端 command，-q 則會讓輸出保持安靜。因此 tunnel 正常運作時不會輸出任何內容，也不會返回。請從第二個 terminal 檢查：

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

第一個 command 應該輸出伺服器的位址，第二個 command 應該輸出桌面的位址。如果兩者完全相同，表示 request 沒有透過 tunnel。接著將瀏覽器的網路設定設為 SOCKS5 proxy，位址為 127.0.0.1，埠為 8080。在瀏覽器中載入相同的位址檢查服務，確認它回報的是伺服器位址，再前往提出驗證要求的搜尋引擎，並在該處完成驗證。

接下來說明這個方法的限制。共有 4 點。搜尋引擎發出的 cookie 會存放在桌面瀏覽器中，而 SearXNG 無法存取瀏覽器的 cookie。因此，唯一可能協助你的 instance 的，是搜尋引擎針對該位址記錄的資訊。這項記錄會過期，期限由搜尋引擎自行決定，而且不會公開。整個程序沒有任何自動化，因此下次遇到相同問題時，你仍然必須親自操作。若該 instance 供其他人使用，觸發驗證的 query rate 仍在持續，驗證要求很快就會再次出現。

你可以用這個方法讓單一 instance 在今天下午恢復運作。但不要以此為基礎建置 instance。

持久解法：停用或調低阻礙你的引擎權重

最省成本且持久的做法，是停止查詢無法服務你伺服器的引擎。你的 settings.yml 會先載入容器映像中的 use_default_settings: true。因此，只要在 engines: 下加入具備相符 name 的項目，就能只覆寫列出的設定鍵，其餘預設定義維持不變。

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

disabled: true 會預設停用該引擎，但仍保留在偏好設定頁面。需要使用的使用者仍可自行重新啟用，以進行個人搜尋。inactive: true 會將該引擎完全從使用者設定中移除。對於從你的位址永遠無法運作的引擎，應使用此設定。weight 的用途不同：它會調整該引擎結果在 SearXNG 合併與排序時的權重。因此，低於 1 的權重可以保留勉強可用的引擎，又不會讓它主導第一頁結果。

編輯完成後重新啟動容器，執行幾次搜尋，然後再次檢查 /stats。擁有 6 個正常運作引擎的乾淨統計頁面，比列出 20 個錯誤的頁面更有用。

持續有效的修正：透過 proxy 傳送對外請求

SearXNG 可以透過 proxy 傳送對外的 engine 請求，讓 engine 看到不同的來源位址。您可以在 outgoing: 下進行全域設定；如果只有一個 engine 發生問題，也可以針對該 engine 設定。

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

如果希望由 proxy 解析主機名稱，請優先使用 socks5h://，而不是 socks5://，因為 h 表示會將名稱傳送給 proxy，而不是在您的伺服器上查詢。請同時提高 timeout 預算。request_timeout 的預設值為 2.0 秒，而 proxy 會讓每個請求多一次往返，因此原本能及時回應的 engine 可能會改以 timeout 失敗。extra_proxy_timeout 正是為此用途提供，會在使用 proxy 時增加秒數。

使用 proxy 的代價：

• proxy 營運者可以看到您的 instance 查詢哪些 engine，以及查詢時間。TLS（transport layer security）會將搜尋詞排除在其日誌之外，因為查詢位於加密請求內；但對方仍能查看您網路流量的特徵與時間。
• 共用的出口位址會與其他付費使用者共用。如果對方進行 scraper，您會繼承其聲譽，有時甚至比您原本要避開的封鎖更快受到影響。
• 廉價的 residential proxy pool 通常由消費者裝置組成，而裝置擁有者並未明確同意承載這些流量。請先了解您購買的服務。
• using_tor_proxy: true 會透過 Tor 傳送流量，但出口節點位址會完整公開；通常會封鎖 datacentre range 的 engine，對出口節點的封鎖至少同樣嚴格。
• 搜尋現在依賴您伺服器以外的服務。該服務可能依自己的時程故障，並讓您的搜尋結果一併中斷。

proxy 會移動封鎖的位置，而不是移除封鎖；您的 instance 隱私也會納入第三方。如果您自架服務的原因是希望維持簡單的隱私邊界，請在註冊任何服務前，先權衡 自架 instance 實際能隱藏什麼，以及無法隱藏什麼。

有持續效果的做法：刻意使用較小的引擎組合

多數人會略過的選項，是接受較少的引擎。SearXNG 的價值在於整合結果，而每次都能回應的 6 個引擎所形成的整合，勝過 20 個引擎中有一半一次停用 1 天。監控 /stats 1 週，保留從你的位址連線時紀錄穩定的引擎。

使用 API key 進行驗證的引擎運作方式不同，因為引擎知道你的身分，會套用配額，而不是猜測你是否為真人。代價是必須建立帳戶、將 key 存放在設定檔中，而且通常需要付費。對你真正需要的 1 或 2 個引擎而言，這通常是最省事的做法。

請將其他工具的需求一併納入考量。停用的引擎對任何透過 API 讀取結果的工具都不可見，因為Open WebUI 與類似工具查詢的 JSON API只會回傳較少的結果，不會回傳工具能察覺的錯誤。如果有自動化程序依賴你的執行個體，請排程輪詢 /stats/errors，不要等到有人反映搜尋結果變差。

這值得花力氣處理嗎？

用使用者人數來判斷。單人執行個體每天只會從一個位址送出少量搜尋，許多搜尋引擎不會對此提出驗證要求。即使某個引擎要求驗證，處理方式也很簡單：移除該引擎，通常幾乎不會察覺它已不再提供結果。這是在小型 VPS 上自行執行 SearXNG的常見情況，不需要 tunnel 或 proxy。

公開或共用的執行個體則不同，因為同一套軟體承受的查詢量會隨每位使用者增加，因此驗證要求會快到超出任何設定所能消化的程度。從一開始就規劃較少的引擎集合，並記住現在加入的任何 proxy，都會以你的帳戶承載其他人的搜尋。

自動化用戶端介於兩者之間，但更接近困難的情況。代理程式為了回答一個問題而執行多次搜尋，會產生人類不會產生的突發流量。因此，提供給 coding agents 和 research tools 使用的執行個體，會比由人手動操作的相同執行個體更早遇到驗證要求。如果你屬於這種用途，應根據可靠性而非涵蓋範圍選擇引擎集合，讓代理程式使用實際能取得的結果。

可遵循的原則是：如果某個引擎是你自行託管的原因，就設法保留；如果不是，就移除它。

FAQ

為什麼我修正問題後，SearXNG 引擎仍然沒有回傳任何結果？

因為它仍處於暫停狀態。SearXNG 偵測到引擎提出挑戰或拒絕請求時，會依 search.suspended_times 設定的期間停止查詢該引擎；期限會依拒絕類型而異，從 1 小時到 15 天不等。暫停狀態會保留在執行中的程序內，因此重新啟動容器即可清除該狀態，下一次搜尋會再次嘗試查詢該引擎。如果引擎在重新啟動後立即再次失敗，表示你的修正沒有生效。

引擎的 CAPTCHA 錯誤，和我的執行個體回傳的 429 相同嗎？

兩者的方向相反。你的執行個體回傳給瀏覽器的 429，是 SearXNG 自有的限制器判定請求看起來像自動化流量；這項設定由你管理。CAPTCHA 或封鎖錯誤則是上游引擎拒絕你的伺服器請求，決定權在你無法控制的系統上。如果結果頁面能載入，但只有部分引擎沒有結果，遇到的就是後者。

在伺服器上使用 VPN 或 proxy，能解決引擎的 CAPTCHA 嗎？

有時可以，但需要付出代價。透過 outgoing.proxies 路由輸出請求，會變更引擎看到的位址，因此可能解除針對資料中心網段的封鎖。proxy 業者會看見你查詢哪些引擎及查詢時間；共用的出口位址也會承擔其他客戶的信譽紀錄。此外，增加的延遲可能造成逾時，除非提高 request_timeout 和 extra_proxy_timeout。Tor 可透過 using_tor_proxy 使用，但其出口位址是公開的，也經常受到挑戰。

我可以讓 SearXNG 自動解決 CAPTCHA 嗎？

沒有可用的設定。專案文件提供的方法是手動處理：建立 SSH SOCKS tunnel、使用自己的瀏覽器，並由你親自完成挑戰。任何用於自動回應挑戰的作法，都違反引擎明定的政策；挑戰內容一變也會失效，最後你維護的是 scraper，而不是執行搜尋執行個體。移除封鎖你位址的引擎，才是能持續運作的做法。