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: 下方。在貼上任何內容前，請對照 searx/settings.yml，確認這些鍵名和值符合實際執行的版本。這些設定在不同版本間曾經變更，而且設定文件頁面的範例仍顯示比 SearXNG 實際載入的檔案更長的暫停時間。searx/settings.yml 於 17 October 2026 發布時，預設值如下：

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

第一層處理逾時等一般故障。封鎖會從 ban_time_on_fail 秒開始，並隨每次連續失敗逐步增加，最高至 max_ban_time_on_fail。預設上限為 2 分鐘，因此引擎發生短暫故障時，問題排除後幾分鐘內就會自行恢復。

第二層處理本指南所述的故障。SearXNG 將回應辨識為挑戰或拒絕，而非一般錯誤時，會套用 suspended_times 中相符的項目，其中大多數數值都大得多。180 秒是 3 分鐘，適用於一般拒絕或 429。3600 是 1 小時，適用於一般 CAPTCHA。86400 是完整 1 天。604800 是 1 週。1296000 是 15 天。以 cf_ 開頭的鍵適用於辨識為 Cloudflare 挑戰的情況；以 recaptcha_ 開頭的鍵適用於辨識為 reCAPTCHA 的情況。

這解釋了最容易浪費時間的症狀。你找出原因並修正問題，但引擎仍然在 1 小時內，或 Cloudflare 挑戰後數天內，沒有任何回應。這是因為引擎仍處於暫停狀態。暫停狀態保留在執行中的程序內，因此重新啟動容器即可清除該狀態，下一次搜尋就會再次嘗試該引擎。這裡直接重新啟動即可。在開始無故重建映像檔前，請先了解 何時重新啟動就足夠，以及何時需要重新建立容器。如果引擎在重新啟動後立即再次失敗，表示你的修正沒有生效。

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

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

截至 17 October 2026，SearXNG 管理文件以手動建立 tunnel 的方式處理這個問題。您可以透過伺服器建立 SOCKS proxy，讓桌面瀏覽器使用該 proxy，並在搜尋引擎看到伺服器位址的情況下手動完成驗證。

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

-D 8080 會在 port 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 則應該輸出桌面的位址。兩者輸出相同，表示請求沒有經過 tunnel。接著將瀏覽器的網路設定改為使用 127.0.0.1、port 8080 的 SOCKS5 proxy，再在瀏覽器中載入相同的位址檢查服務，確認其回報伺服器位址，然後造訪要求您完成驗證的搜尋引擎。在該頁面完成驗證。

接下來說明這個方法的限制。搜尋引擎發出的 cookie 會儲存在桌面瀏覽器中，而 SearXNG 無法存取瀏覽器的 cookie。因此，唯一可能協助您的 instance 的資訊，是搜尋引擎針對該位址記錄的內容。這筆記錄會過期，期限由搜尋引擎決定，且不會公開。整個程序沒有自動化，因此下次仍須回到鍵盤前操作。若是其他人也在使用的 instance，觸發驗證的查詢速率仍然存在，因此驗證會再次出現。

今天下午可以用這個方法讓一個 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 個錯誤的頁面更有用。

持久的修正：透過代理伺服器傳送對外請求

SearXNG 可以透過代理伺服器傳送對外的引擎請求，藉此變更引擎所看到的來源位址。您可以在 outgoing: 下進行全域設定；如果只有一個引擎發生問題，也可以針對該引擎設定。

outgoing:
  request_timeout: 3.0
  extra_proxy_timeout: 10
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

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

如果希望由代理伺服器解析主機名稱，請優先使用 socks5h://，而不是 socks5://，因為 h 表示會將名稱傳送給代理伺服器，而不是在您的伺服器上查詢。請同時提高逾時預算。request_timeout 的預設值為 3.0 秒，代理伺服器會為每個請求增加一次往返，因此原本能及時回應的引擎可能改為因逾時而失敗。extra_proxy_timeout 正是為此用途而設，會在使用代理伺服器時增加秒數。請使用整數，例如 10。不同於可接受小數的 request_timeout，extra_proxy_timeout 在設定結構描述中是整數，因此像 10.0 這樣的值會被拒絕為無效的 settings.yml，即使對外設定說明頁面的註解範例採用這種寫法。

使用代理伺服器的代價：

• 代理伺服器營運者可以看到您的執行個體查詢哪些引擎，以及查詢時間。TLS（傳輸層安全性）會將搜尋字詞留在其日誌之外，因為查詢位於加密請求內；但他們仍可讀取您網路流量的型態與時間。
• 共用的出口位址也會與其他付費使用者共用。如果其他使用者進行大量抓取，您會繼承其信譽，有時甚至比原本要避開的封鎖更快遭到封鎖。
• 低價住宅代理伺服器池通常由消費者裝置組成，而裝置擁有者並未明確同意承載流量。請先了解您購買的服務。
• using_tor_proxy: true 會透過 Tor 路由，但出口節點位址會完整公開；通常會封鎖資料中心網段的引擎，至少同樣會嚴格封鎖出口節點。
• 搜尋現在依賴伺服器外部的服務。該服務可能依自己的時程故障，並連帶使您的搜尋結果消失。

代理伺服器會移動封鎖位置，而不是移除封鎖；您的執行個體隱私也會納入第三方因素。如果您自行託管的原因是希望維持簡短的隱私範圍，請先對照自行託管的執行個體實際隱藏了什麼，以及沒有隱藏什麼，再註冊任何服務。

刻意維持較小的引擎集合，才能長期穩定運作

多數人會略過的選項，是接受使用較少的引擎。SearXNG 的價值在於合併結果。每次都能回應的 6 個引擎，會勝過 20 個但其中一半一次停用數小時或數天。連續一週監控 /stats，保留從你的位址連線時紀錄良好的引擎。

使用 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 設定的時間停止查詢該引擎。根據拒絕類型，內建預設值的範圍是 3 分鐘到 15 天。暫停狀態保留在執行中的程序內，因此重新啟動容器即可清除狀態，下一次搜尋會再次嘗試查詢該引擎。如果引擎在重新啟動後立即再次失敗，表示你的修正沒有生效。

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

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

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

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

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

沒有相關設定。專案文件記載的方法是手動處理：使用 SSH SOCKS 通道、自有瀏覽器，並由你親自完成驗證挑戰。任何用於自動回應驗證挑戰的機制，都會違反引擎明定的政策；而且每次挑戰變更後都可能靜默失效，最後你維護的會是 scraper，而不是搜尋執行個體。移除會封鎖你來源位址的引擎，才是能持續運作的做法。