如何修复 SearXNG 搜索引擎 CAPTCHA 错误

SearXNG CAPTCHA 错误的含义

SearXNG CAPTCHA 错误来自实例查询的搜索引擎。您的服务器向某个搜索引擎请求结果，但该搜索引擎返回的是验证页面，而不是结果。由于响应中没有可解析的内容，SearXNG 将该搜索引擎记录为错误。您的实例运行正常。您无法控制的系统判定该请求不像是由用户发起的。

这一点决定了下面所有修复方法。该判定是在搜索引擎自己的服务器上作出的，因此您的 settings.yml 无法覆盖它。您可以更改请求发出的地址、要查询的搜索引擎，以及某个搜索引擎开始拒绝请求后实例的行为。

看起来相同的两种故障，以及如何区分

第一种故障是您自己的实例向您自己的浏览器返回 HTTP 429（请求过多）。这是 SearXNG 限流器的行为。限流器位于搜索端点前方，负责检测机器人请求。它运行在您的服务器上，也由您配置。向您自己的用户返回 429 的限流器是另一个独立问题，使用不同的设置。以下建议均不适用于该问题。

第二种故障发生在上游。结果页面正常加载，但结果中缺少一个或多个引擎，或者引擎显示错误提示。您的实例没有拒绝任何请求。是某个引擎拒绝了您的服务器。

• 页面无法加载，或搜索端点返回 429：检查您的限流器。
• 页面可以加载，但结果很少，或某个引擎标记为错误：检查上游，并继续阅读。

同一实例可能同时出现这两种故障。两者还会相互影响，因为限流器设置过宽松时，会放行更多流量，从而提高您的出站查询速率。请分别诊断这两种故障。

为什么 SearXNG 在 VPS 上返回 CAPTCHA 错误，而在我的笔记本电脑上不会？

原因是请求来源地址不同。您的家庭网络使用的是消费级 ISP（互联网服务提供商）地址段中的地址，这些地址会被许多普通用户共享。您的 VPS 使用的是数据中心地址段中的地址，这些地址段是公开的：任何人都可以查询哪些地址属于托管服务提供商。希望阻止抓取程序的搜索引擎，通常会先将来自托管服务地址段的请求视为可疑请求，因为这些地址中的请求很少来自使用浏览器的真实用户。

除了地址之外，还有其他因素会叠加影响结果。您的实例会针对每次用户搜索向每个搜索引擎发送一个请求，因此即使用户数量很少，单个地址产生的请求速率也可能超过普通个人用户的行为。SearXNG 按设计不会与搜索引擎保持会话，也不会携带长期 Cookie，因此每个请求到达时都没有历史记录。该地址还可能带有并非由您造成的历史记录，因为服务提供商会回收地址，而之前的租户可能已经使用该地址抓取了数月。

搜索引擎的拒绝不一定会表现为明显的失败。搜索引擎可能返回 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。默认上限为两分钟，因此问题消失后，间歇性故障的引擎通常会在几分钟内自动恢复。

第二层处理本指南所讲的故障。当 SearXNG 将响应识别为质询或拒绝，而不是一般错误时，会应用 suspended_times 中匹配的条目，这些数值要大得多。86400 秒为整整一天。604800 秒为一周。1296000 秒为十五天。以 cf_ 开头的键适用于识别为 Cloudflare 质询的情况；以 recaptcha_ 开头的键适用于识别为 reCAPTCHA 的情况。

这解释了最浪费时间的现象。您找到原因并修复问题后，引擎仍然数小时不返回结果。因为它仍处于暂停状态。暂停状态保存在运行中的进程内，因此重启容器会清除该状态，下一次搜索会再次尝试使用该引擎。在这里，直接重启即可；在无须重建镜像之前，最好先了解何时重启就足够，以及何时需要重新创建容器。如果引擎在重启后立即再次失败，说明您的修复没有生效。

有一项按引擎配置的设置需要特别注意。retry_on_http_error 会在引擎返回您列出的状态码时重试请求。对于正在拦截您的引擎，重试会向已经判定您的服务器是机器人的系统发送更多流量。除非您要处理确实存在间歇性故障的引擎，否则不要启用此设置。

SSH 隧道文档说明及其无法解决的问题

SearXNG 管理文档于 2026 年 9 月 2 日确认，针对这个问题给出的方案是手动建立隧道。您可以通过服务器建立 SOCKS 代理，将桌面浏览器指向该代理，然后手动完成验证，此时引擎看到的是服务器的地址。

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

-D 8080 会在本地 8080 端口启动 SOCKS 服务器，并通过 SSH 连接转发流量。-N 不执行远程命令，-q 让命令保持静默，因此隧道正常时不会输出任何内容，也不会返回。请在第二个终端中检查：

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

第一个命令应输出服务器地址，第二个命令应输出桌面地址。如果两者输出相同，说明请求没有通过隧道。然后将浏览器的网络设置为 SOCKS5 代理，地址使用 127.0.0.1，端口使用 8080。在浏览器中打开同一个地址检查服务，确认它报告的是服务器地址，然后访问触发验证的引擎。在那里完成验证。

下面说明这种方法的限制。共有 4 点。引擎发放的 cookie 会保存在桌面浏览器中，而 SearXNG 无法访问浏览器的 cookie。因此，唯一可能帮助您的实例的，是引擎针对该地址本身记录的信息。该记录会过期，过期时间由引擎决定，且不会公开。整个过程没有任何自动化机制，因此下次仍需手动操作。对于供其他人使用的实例，触发验证的查询速率仍在持续，验证还会再次出现。

可以使用这种方法让一个实例在今天下午恢复工作。但不要以此为基础构建实例。

持久修复：移除或降低阻塞您的引擎权重

最经济且持久的做法，是停止查询无法为您的服务器提供结果的引擎。您的 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: 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

如果您希望由代理解析主机名，请优先使用 socks5h://，而不是 socks5://，因为 h 表示将名称发送给代理，而不是在服务器上解析。请同时增加超时预算。request_timeout 的默认值为 2.0 秒，而代理会为每个请求增加一次往返延迟。原本能及时响应的引擎可能因此开始超时失败。extra_proxy_timeout 正是为此设计的，使用代理时会额外增加数秒。

使用代理的代价：

• 代理运营方可以看到您的实例查询了哪些引擎，以及查询时间。TLS（传输层安全）会将搜索词排除在其日志之外，因为查询内容位于加密请求中；但您的流量特征和时间信息仍由代理运营方掌握。
• 共享出口地址也与其他付费用户共享。如果他们进行抓取，您会继承其信誉风险，有时甚至会比原先要绕过的封禁更快触发封禁。
• 廉价的住宅代理池通常由消费者设备组成，而设备所有者并未明确同意承载流量。请了解您购买的服务。
• using_tor_proxy: true 通过 Tor 路由，但出口节点地址会完整公开。通常会封禁数据中心网段的引擎，至少也会同样严格地封禁出口节点。
• 搜索现在依赖服务器之外的服务。该服务可能按自己的时间表发生故障，并导致您的搜索结果同时不可用。

代理只能转移封禁，不能消除封禁；您的实例隐私边界现在还包括第三方。如果您自行托管的原因是希望获得简洁的隐私边界，请在注册任何服务前，权衡这一点与自托管实例实际能隐藏什么、不能隐藏什么。

有持久效果的修复：有意使用更少的引擎

大多数人会跳过的选项，是接受使用更少的引擎。SearXNG 的价值在于合并结果。每次都能返回结果的 6 个引擎，比 20 个引擎中有一半连续暂停一天，更有实际价值。连续一周监控 /stats，保留从您的地址访问记录良好的引擎。

使用 API key 进行身份验证的引擎，行为有所不同，因为引擎知道您的身份，并会执行配额限制，而不是猜测您是否是真人。代价是需要一个账户，将密钥存放在设置文件中，而且通常还要付费。对于您确实需要的 1 个或 2 个引擎，这通常是最省事的方案。

请结合其他工具的使用情况做出决定。任何通过 API 读取结果的工具都无法看到已暂停的引擎，因为 Open WebUI 及类似工具查询的 JSON API 只会返回更少的结果，而不会返回工具能够识别的错误。如果有自动化任务依赖您的实例，请按计划轮询 /stats/errors，不要等到有人发现结果质量下降后再报告问题。

是否值得继续解决这个问题？

可以根据用户数量判断。单人实例每天从一个地址发出少量搜索请求，许多搜索引擎不会对此发起验证。如果某个引擎要求验证，解决方法也很简单：移除该引擎，通常几乎不会察觉它已不可用。这就是在小型 VPS 上自行运行 SearXNG的常见情况，不需要隧道或代理。

公共实例或共享实例使用相同的软件，但运行在不同的服务器上。触发验证的因素是查询速率，而且用户越多，查询速率越高，因此验证请求的到来速度会超过任何配置的处理能力。从一开始就规划较小的搜索引擎集合，并记住：现在添加的任何代理，都会让其他用户的搜索请求使用您的账户。

自动化客户端处于两者之间，但更接近复杂情况。一个代理为了回答一个问题而执行多次搜索，会产生人类用户不会产生的突发请求。因此，供编码代理和研究工具使用的实例会比手动操作的相同实例更早遇到验证。如果您的用途属于这种情况，应根据可靠性而不是覆盖范围选择搜索引擎集合，并让代理使用实际能够获取的结果。

通用原则是：如果某个搜索引擎是您自行托管的原因，就解决与它相关的问题；如果不是，就移除它。

FAQ

为什么修复问题后，SearXNG 引擎仍然不返回结果？

因为该引擎仍处于暂停状态。SearXNG 识别到引擎返回质询或拒绝后，会在 search.suspended_times 设置的时间内停止查询该引擎。根据拒绝类型，默认暂停时间可能从 1 小时到 15 天不等。暂停状态保存在运行中的进程内，因此重启容器即可清除该状态，下一次搜索会再次尝试访问该引擎。如果引擎在重启后立即再次失败，说明你的修复没有生效。

引擎 CAPTCHA 错误与实例返回的 429 是同一种问题吗？

两者的方向相反。实例向浏览器返回 429，表示 SearXNG 自带的限制器判断请求看起来像自动化请求；该限制由你配置。CAPTCHA 或阻止错误表示上游引擎拒绝你的服务器请求，决定权在你无法控制的设备上。如果结果页面可以加载，但只有部分引擎缺失，那么遇到的是后一种情况。

在服务器上使用 VPN 或代理可以解决引擎 CAPTCHA 吗？

有时可以，但需要付出代价。通过 outgoing.proxies 路由出站请求会改变引擎看到的地址，从而可能解除针对数据中心地址段的阻止。代理运营者可以看到你查询了哪些引擎以及查询时间；共享出口地址还会附带其他客户的信誉记录。此外，额外延迟可能导致超时，除非提高 request_timeout 和 extra_proxy_timeout。Tor 可通过 using_tor_proxy 使用，但其出口地址是公开的，也经常受到质询。

可以让 SearXNG 自动解决 CAPTCHA 吗？

没有相应设置。项目文档说明的方法是手动处理：使用 SSH SOCKS 隧道、你自己的浏览器，并由你亲自完成质询。你构建的任何自动回答质询的机制，都违反引擎声明的策略；每当质询发生变化，它还可能静默失效。这样你维护的就会变成一个抓取程序，而不是搜索实例。移除阻止你当前地址的引擎，才是能够持续生效的解决方案。