有朋友问我现在谁还在自己搭搜索引擎这个问题我熟悉。去年我把 SearXNG 部署到云主机上的时候身边同事的反应基本都是“白嫖 Google / Bing 不好吗”。但跑了大半年之后我可以很负责任地说这已经是我日常使用频率最高的自托管服务没有之一。原因非常朴素我不喜欢搜索结果里越来越重的广告和追踪参数也想让“搜索”这个入口重新掌握在自己手里。SearXNG 是一个完全开源的元搜索引擎本身不自带爬虫和索引库而是聚合多个上游引擎的结果配合 Docker部署门槛被压得非常低一台低配云主机就能跑得很好。如果你手上有一台云主机不想继续忍受导航页和广告堆砌出来的搜索体验或者想给团队内部做一个统一的搜索入口这篇实战记录应该能帮你少走不少弯路。我会从 SearXNG 的定位讲起再把机器选型、Docker 部署、配置调优、公网加固、故障排查这几个环节完整过一遍全程是可复现的操作。1. SearXNG到底是个什么玩意1.1 元搜索是怎么工作的很多人第一次听说 SearXNG会以为它又是一个“搜索引擎”。其实它的定位更准确的说法是搜索结果聚合器。它没有自己的爬虫系统也不维护网页索引库。用户提交一个关键词后SearXNG 会把这个关键词同时转发给多个上游搜索引擎——Google、Bing、Brave、Wikipedia、GitHub、Reddit 这些都在可选列表里——然后把这些来源的结果拉回到本地经过解析、排序、去重之后统一渲染成一个干净的页面。这种设计带来的好处很直观一个入口能看到多个信息源的结果而且页面里几乎没有广告。我日常查一个开源项目时往往左边是普通网页结果右边能看到 GitHub 和 Stack Overflow 的聚合条目比来回切换标签页效率高很多。代价也同样明显SearXNG 的搜索体验完全取决于上游引擎的稳定性和解析兼容性上游接口结构一变或者某个引擎开始限流搜索质量就会波动。用一句话总结SearXNG 是“给搜索做聚合和过滤的前端”它自己不生产内容只决定你看到什么。1.2 自托管 vs 公共实例SearXNG 官方和社区维护了一批公共实例网上随便一搜就能找到。公共实例的好处是开箱即用不用自己维护服务器但问题也不少公共实例通常负载很高时不时会挂掉你不知道它有没有记日志也没法确认服务方的隐私政策管理员一旦调整引擎配置你只能被动接受。自托管的意义就在这里。部署在自己的云主机上你可以关掉统计、限制日志留存、自由增删引擎、调整结果权重、决定是否开放给别人用。这些能力对普通用户来说可能只是“更安心”但对经常写脚本、接 API 的开发者和喜欢自托管的爱好者来说就是实打实的可定制性。Docker 部署给自托管带来的另外一个关键好处是可复现。compose 文件加一个配置目录整个服务就能在一台新机器上快速恢复。我后来给朋友部署第二台实例时整个过程只花了一刻钟大部分时间都在等镜像拉取。1.3 它适合谁又不适合谁SearXNG 并不是搜索引擎的万能答案。如果你对搜索准确度极其敏感希望每个关键词的第一条结果都精确命中默认配置的 SearXNG 可能会让你失望——聚合结果的排序逻辑和单一搜索引擎的算法差距明显需要花时间调引擎权重和语言偏好才能接近“顺手”的状态。它真正适合的人群是注重搜索隐私、喜欢自托管、愿意花一点时间调教工具的人。对普通家用场景它是个很好的默认搜索入口对开发者它是很干净的 JSON 搜索 API 来源对团队它可以作为内部知识检索的统一跳板。这些场景下SearXNG 的性价比极高。2. 部署前的准备机器、系统与Docker环境2.1 云主机怎么选SearXNG 对硬件的要求不高但这不代表可以随便拿一台最便宜的机器硬扛。我最初在一台 1 核 1G 的云主机上跑单用户自己用没毛病可一旦同时开多个引擎搜索内存曲线会明显往上涨。如果有条件推荐 2 核 2G 起步这样即使并发几个请求系统也不会进入频繁 swap 的状态。硬盘方面镜像加配置和数据 20G 绰绰有余不需要额外挂数据盘。系统我建议用 Debian 12 或 Ubuntu 22.04 LTS 这类干净的 Linux 发行版。用过带面板的系统也没问题但面板的防火墙和 Docker 网络策略偶尔会互相干扰排查起来反而更累。虚拟化方面优先选 KVM 架构的机器OpenVZ 这类轻量容器虚拟化对 Docker 的内核功能限制比较多跑起来容易碰壁。2.2 Docker 的安装步骤Docker 官方脚本是很多教程的首选但我个人更推荐先配好 apt 源再安装这样后续版本升级更可控。以 Debian 系系统为例下面这组命令是我每次初始化新机器时都会用的sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/debian/gpg | sudo tee /etc/apt/keyrings/docker.asc /dev/null echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo systemctl enable --now docker装完之后用docker version确认客户端和引擎都正常。如果服务器到 Docker 官方仓库的拉取速度不理想可以考虑给 Docker 配置镜像加速源但这一步不是必须的先跑通再说。2.3 Compose 插件和用户权限现在的 Docker 已经内置了 compose v2 子命令也就是docker compose不需要再单独安装docker-compose那个 Python 包。如果你执行docker compose version报错多半是docker-compose-plugin没有装好用 apt 装一下即可。比较容易被新手忽略的是用户权限问题。刚装完 Docker普通用户执行docker ps会提示权限不足这是因为当前用户不在docker用户组里。把用户加进去再重新登录就好sudo usermod -aG docker $USER重新登录后不需要每次都用sudo docker操作会顺手很多。注意这个操作等效于把本用户提升到接近 root 的权限只建议在你自己掌控的服务器上使用。2.4 防火墙和基础端口在开始部署前先把防火墙规则想清楚避免服务起来了却连不上或者更糟——服务裸奔到公网。如果是云服务商除了机器上的防火墙还要同步检查安全组规则。我常用的ufw配置是这样的sudo apt install ufw sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable这里我只放了 SSH、80 和 443。SearXNG 的 8080 端口先不放出去后面我会用 Nginx 反向代理来对外提供访问这样安全性和灵活性都更好。还有一个细节Docker 默认会修改 iptables 规则ufw的规则有时候会被 Docker 的端口映射绕过所以最佳实践是强制所有外部流量都走 Nginx而不是直接暴露容器端口。3. 用docker-compose把SearXNG拉起来3.1 目录规划和compose文件SearXNG 容器本身是无状态的但需要的持久化内容并不复杂主要是配置文件和一个小的数据目录。我习惯把服务目录建在/opt/searxng下面结构清晰备份的时候打包整个目录就行。sudo mkdir -p /opt/searxng cd /opt/searxng mkdir -p searxng然后在/opt/searxng下创建docker-compose.yml。这是我最常用的最小可用版本services: searxng: container_name: searxng image: searxng/searxng:latest restart: unless-stopped ports: - 127.0.0.1:8080:8080 volumes: - ./searxng:/etc/searxng environment: - SEARXNG_BASE_URLhttp://127.0.0.1:8080 - SEARXNG_SECRET请替换成随机字符串注意端口映射我写的是127.0.0.1:8080:8080这样宿主机之外访问不到 8080 端口。你可能会好奇为什么不直接映射到公网答案是我用 Nginx 反向代理来对外服务容器端口绑定在 loopback 上就多了一层安全边界。如果只是本地测试这个配置也够用。3.2 首次启动与配置生成写好 compose 文件后先启动一次容器让镜像内部把默认配置生成出来docker compose up -d docker compose ps docker compose logs -f searxngSearXNG 官方镜像的一个贴心设计是如果挂载的/etc/searxng目录下没有settings.yml容器启动时会把内置的默认配置复制进去。也就是说第一次启动后宿主机上的./searxng目录里会自动多出配置文件可以直接编辑不用自己去官网抄一份完整配置。启动完成后先在宿主机上验证一下页面是不是活着curl -I http://127.0.0.1:8080如果看到 HTTP 200说明基本通了。这里有个小坑curl -I走的是 HEAD 请求SearXNG 对某些路径可能返回 405 或 404但只要返回的不是连接拒绝基本就能说明服务进程是正常的。3.3 secret_key 和 BASE_URL 为什么必须认真填SEARXNG_SECRET是很多新手第一个踩坑的地方。SearXNG 默认配置里开启了 limiter限流器而 limiter 要求必须有一个有效的 secret_key 来签名会话数据。如果你既不设置环境变量也不改配置文件容器会一直报错或拒绝请求。生成随机密钥用下面这条命令比较省事openssl rand -hex 32把输出替换到 compose 文件的SEARXNG_SECRET字段里。注意别把密钥提交到公开的 Git 仓库有泄露风险。SEARXNG_BASE_URL同样重要。它告诉 SearXNG 最终对外访问的地址是什么影响页面里生成的链接和 API 返回的结构。如果你只是本机访问http://127.0.0.1:8080没问题一旦后面配置了域名和 HTTPS记得把它改成https://search.example.com这种正式地址否则浏览器里的静态资源和登录状态都可能出问题。3.4 settings.yml 的结构和常用调整容器首次启动后编辑./searxng/settings.yml。这个文件是 YAML 格式SearXNG 的设计很友好你不需要维护一份完整配置只要在最上面声明use_default_settings: true然后在下面覆盖需要改的字段就行。我的一份基础配置长这样use_default_settings: true server: port: 8080 bind_address: 0.0.0.0 secret_key: 这个值会被环境变量覆盖留着也不影响 limiter: true search: safe_search: 0 autocomplete: google default_lang: zh-CN改完配置后重启容器docker compose restart searxng这里我要特别提醒如果同时设置了SEARXNG_SECRET环境变量它会覆盖 settings.yml 里的secret_key。我推荐的做法是密钥跟着环境变量走配置文件里不要写真正的密钥这样整个配置目录即便打包分发出去也不会泄露秘密。3.5 什么时候需要加 Redis官方 compose 示例里其实可以不加 Redis单用户或者小团队场景完全没必要。Redis 在 SearXNG 里的作用主要是保存限流状态、缓存搜索结果和任务负载只有公开实例或高并发集群才值得引入。如果你确实要加最简单的方式是在 compose 里加一个redis服务redis: image: redis:alpine restart: unless-stopped然后在 settings.yml 里指定redis.url: redis://redis:6379/0。这样 SearXNG 的限流次数和搜索缓存就能跨实例共享但代价是内存占用会继续上涨。对本文讨论的单机部署我建议先跳过 Redis把有限的内存留给搜索请求本身。4. 把默认搜索结果调成顺手的样子4.1 语言与区域的坑如果你的用户主要是中文使用者默认配置的第一感受可能是英文结果太多。SearXNG 的search.default_lang可以设置默认语言zh-CN但这只是一个偏好不是强制过滤。真实世界的搜索引擎还是会根据关键词、用户 IP、请求来源来猜意图所以不要指望设了一个zh-CN就只剩中文结果。我实际用下来最顺手的组合是default_lang设为zh-CN但地区不锁定。因为中文技术搜索经常需要找英文原版文档把地区锁死反而会把一些高质量英文结果过滤掉。搜索框旁边的地区下拉菜单可以随时切缺省不锁是最灵活的方案。4.2 引擎的启停与权重调整SearXNG 默认启用的引擎很多其中一些可能响应慢、结果重复严重或者根本不是你需要的语言。在 settings.yml 的engines段可以精确控制。比如我想关掉某个质量差的引擎同时让 Wikipedia 的权重高一点engines: - name: google disabled: false - name: wikipedia weight: 1.3 - name: some_unstable_engine disabled: true我的经验是一次别开太多引擎。每多一个引擎SearXNG 就要向外多发起一次请求响应时间会相应变长。比较常见的结果是 Bing Google Brave 再加一个垂直站点就够了搜索速度和结果丰富度能达到不错的平衡。判断哪些引擎值得留最好的办法不是猜而是看数据。SearXNG 自带一个统计页面通常在/stats里面能看到每个引擎的请求成功率、平均响应时间和最近错误数。我调优时就是打开这个页面把成功率低、响应慢的引擎逐个禁用观察搜索结果的变化几次迭代后整体体验会上一个档次。4.3 结果数量与安全搜索search.per_page控制每页显示的搜索结果数默认一般是 20。对私人实例来说20 合适如果开放给公网建议不要调太高否则每次搜索都要聚合更多结果既增加上游压力也容易被爬虫盯上。safe_search是一个三级设置0 表示关闭1 为中等过滤2 为严格过滤。自己用设 0 没问题但如果这台实例要分享给朋友或团队成员设置成 2 能省掉很多不必要的麻烦。4.4 UI 主题和隐私细节SearXNG 新版的默认主题很简洁没有大问题。但有两个和隐私有关的细节值得动手一是自动补全autocomplete: google会把用户输入的前几个字符发送到 Google 的补全接口如果你在意“搜索词不离开自己的服务器”这件事把它改成空字符串或者直接关闭二是浏览器缓存和 cookieSearXNG 默认不会保留太多用户状态这点比很多商业搜索引擎克制得多。另外建议在 settings.yml 里确认一下server.public_instance这个字段。如果这台机器只是自己或小范围使用不要把它设成true。设为false时SearXNG 的限流和验证逻辑会更严格对防滥用很有帮助。4.5 顺手接一个 JSON APISearXNG 最被开发者称道的一点是它能直接返回结构化 JSON 结果。只要在搜索 URL 后面加formatjson就能拿到干净的结果列表字段包括标题、链接、摘要、来源引擎等。我团队里现在跑的很多内部脚本都是用这个接口做批量关键词查询比逐个请求上游搜索引擎稳定得多。现在不少对话式工具也支持把 SearXNG 当作联网搜索后端配置好地址后让大模型在回答问题时能实时查资料。这个组合用途很广而且配置方法非常简单基本上填一个 URL 就能连通。5. 从localhost到公网安全加固才是重头戏5.1 裸奔的教训如果你只是给自己用真的不建议直接把 8080 端口映射到公网后就开始访问。SearXNG 这类搜索代理是所有扫描器的重点关照对象很多人搭好服务和被恶意刷量之间只隔了一个下午。我自己的真实经历是有一次图省事把端口映射改成了0.0.0.0:8080:8080又没加访问控制结果部署完大概二十分钟日志里就开始出现大量陌生 IP 的请求有的在测路径有的在刷搜索接口。虽然没有造成什么严重后果但白白消耗了不少资源事后清理和加固反而花了很多时间。所以这次教程里我特意坚持先把容器绑在 127.0.0.1然后再用反向代理对外提供服务。5.2 Nginx 反向代理配置安装 Nginxsudo apt install nginx然后在/etc/nginx/sites-available/searxng写一个最基础的反向代理配置server { listen 80; server_name search.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }启用这个站点并重载 Nginxsudo ln -s /etc/nginx/sites-available/searxng /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx注意我把X-Forwarded-For和X-Forwarded-Proto都传给了后端的 SearXNG。这两个头对 SearXNG 判断客户端真实 IP 和请求协议非常关键尤其是开了限流器之后如果拿不到真实 IP所有请求都会被视为来自 127.0.0.1限流等于白开。5.3 上 HTTPS一次都别省在搜索引擎这个场景里不做 HTTPS 几乎等于把用户搜索词明文扔在公网上。安装证书用 certbot 非常顺手sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d search.example.comcertbot 会自动修改 Nginx 配置把 80 端口的重定向和 443 的证书路径写进去然后自动创建一个续期定时器。你基本不用再管证书续期的事。证书安装完成之后回到 compose 文件把SEARXNG_BASE_URL改成https://search.example.com然后重启容器docker compose up -d这一步经常被忽略但如果 BASE_URL 还是 http页面上会混入 http 链接浏览器地址栏的安全提示也会很别扭。5.4 访问控制自己用和别人访问完全是两套策略如果这台 SearXNG 只给你自己用最简单的加固是在 Nginx 层加 HTTP Basic Auth一行配置就能挡住绝大多数扫描器sudo apt install apache2-utils sudo htpasswd -c /etc/nginx/searxng.htpasswd admin然后在 Nginx 的 location 里加两行auth_basic SearXNG; auth_basic_user_file /etc/nginx/searxng.htpasswd;重载 Nginx 之后没有用户名密码的人连搜索框都看不到。如果想让团队小范围免密使用那就得靠 SearXNG 自身的 limiter。开启limiter: true之后SearXNG 会基于来源 IP 和 cookie 做请求频率限制同时会在页面上要求通过一个简单的验证。此时必须保证 Nginx 把真实 IP 传给了后端否则限流器形同虚设。还可以在 Nginx 层加limit_req限制单个 IP 的请求速率作为第二道防线。看到这里你应该已经明白公网部署的核心思路不是“相信谁”而是“默认不信任任何人”。5.5 更新和备份策略SearXNG 的用户数据很少需要备份的核心其实就是配置目录。整个/opt/searxng打个包也就几 KB 到几十 KB非常适合定时备份tar czf searxng-backup-$(date %F).tar.gz /opt/searxng把这个命令放进 crontab并且把压缩包同步到其他机器或对象存储就足够应付绝大多数意外了。升级镜像更简单docker compose pull searxng docker compose up -d searxngSearXNG 的更新节奏比较稳定但大版本升级后配置结构偶尔会变。升级完看一眼日志如果某个配置字段失效容器通常会很直白地报出来按提示调整即可。6. 真实运行中的故障和排查思路6.1 容器起不来、反复重启这是最常遇到的问题我的排查顺序很固定先docker compose ps看状态再docker compose logs --tail200 searxng看日志。新手遇到最多的原因是 settings.yml 的 YAML 缩进错误。YAML 对缩进极其敏感Tab 和空格混用、字段多缩进一格或少缩进一格容器都可能直接启动失败。这时候日志里一般会给出 “could not parse settings.yml” 之类的提示。修改的时候记得用空格缩进不要用 Tab。另一个常见原因是端口被占。如果你在同一台机器上跑了其他服务占用了 8080SearXNG 会报address already in use。解决办法很简单把 compose 的端口映射改成其他端口或者停掉那个占用端口的服务。6.2 页面能打开搜索却一直报错能打开页面说明服务正常搜索失败通常出在上游引擎侧。我先去/stats页面看引擎的成功率和响应时间哪个引擎红得刺眼就先把它禁用。这类问题的本质是你所在网络到某些上游搜索服务的连通性不稳。搜索引擎服务商会根据请求频率和来源做限流较频繁的搜索请求很容易触发临时封禁。我的处理方式是在 settings.yml 里把单引擎超时时间调短比如 3 秒避免某个慢引擎拖垮整个页面engines: - name: some_slow_engine timeout: 3.0同时控制并发引擎数量尽量保持在 4 到 6 个之间。这里我提醒一句不要盲目追求“引擎越多越好”你真正想保留的是“结果质量稳定”的源而不是“偶尔能用”的源。6.3 本地电脑部署的那些坑如果你选择在本地 Windows 或 Mac 上用 Docker Desktop 先试试可能会遇到两个高频问题。第一个是 Windows 下常见的 “virtualization support not detected” 之类报错说明 BIOS 里的虚拟化没开或者 WSL2 没正确启用。第二个是 Docker Desktop 本身偶发的网络状态异常表现是 curl 能通浏览器打不开或者反过来。本地体验一下没问题但我还是建议真正要长期用的服务直接放到一台 Linux 云主机上。Docker Desktop 和 Linux 下的 Docker 引擎在行为细节上存在不少差异生产环境部署换到 Linux 能少很多诡异问题。6.4 内存和并发压力怎么处理搜索请求的峰值内存比平时高这是 SearXNG 的特性。如果你发现云主机经常吃满内存优先做三件事限制容器内存上限、降低 worker 数量、把上游引擎数量降下来。compose 里可以这样限制mem_limit: 1g environment: - SEARXNG_WORKER_COUNT2worker 数量在 settings.yml 里对应的字段是server.workers。默认值可能是 CPU 核心数加一对低配机器来说偏高手动改成 2 或 3 通常就够日常使用了。同时检查一下search.per_page如果之前调得过高搜索请求的内存开销会明显增加。6.5 健康检查让机器自己报告身体情况SearXNG 自带一个/healthz端点返回 200 就代表服务存活。在 compose 里加上健康检查能让系统自动帮你盯着服务状态healthcheck: test: [CMD, curl, -fsS, http://127.0.0.1:8080/healthz] interval: 30s timeout: 5s retries: 3加了之后docker compose ps会显示容器是否 healthy如果有外部监控也能直接调用/healthz做探活。这个小成本投入对长期稳定运行非常值得。最后说点个人体会。最早搭 SearXNG我是抱着“去广告、去追踪”的心态实际跑下来它最大的价值不是替代谁而是把所有我不满意的地方集中到一个自己能改的地方。Docker 部署这件事最大好处不是“一键”而是可复现服务器搬家或重装把 compose 文件和配置一拷两条命令就能回来。如果你也想动手我的建议是先别急着追求复杂一台最便宜的云主机、一个域名、一个干净的系统从上面的 compose 开始跑通再优化。部署 SearXNG 本身不会花很多时间真正花时间的是理解和调试你自己的搜索需求。等用顺了再把这个地址填进你常用的对话工具或者浏览器搜索引擎里会越用越顺。