OpenWebUI联网搜索实战：如何用SearXNG让本地大模型获取实时信息（附百度/360配置）

Ne0inhk

— 7 min read

OpenWebUI联网搜索实战：如何用SearXNG让本地大模型获取实时信息（附百度/360配置）

如果你在本地运行大模型，比如用Ollama部署了Qwen、Llama或者DeepSeek，可能会发现一个尴尬的问题：模型的知识截止日期是固定的，它不知道今天股市涨跌，不清楚最新的科技新闻，甚至不知道明天是什么节日。这种“信息孤岛”的感觉，让本地大模型的实用性大打折扣。

我最初搭建OpenWebUI环境时，也遇到了这个痛点。看着模型一本正经地分析过时的数据，那种无力感让我开始寻找解决方案。市面上有不少联网搜索方案，但要么配置复杂，要么对国内网络环境不友好。经过几周的折腾和测试，我发现SearXNG这个开源元搜索引擎，配合OpenWebUI的联网搜索功能，是目前最稳定、最灵活的方案之一。

更重要的是，通过合理配置SearXNG，我们可以让本地大模型直接调用百度、360等国内搜索引擎，获取符合中文用户习惯的实时信息。这不仅仅是技术上的连接，更是让本地AI真正“接地气”的关键一步。下面我就把自己踩过的坑、验证过的配置，以及实际效果对比，毫无保留地分享给你。

1. 为什么需要SearXNG？OpenWebUI联网搜索的现状与痛点

在深入配置之前，我们得先搞清楚一个问题：为什么不能直接用OpenWebUI内置的搜索引擎？答案藏在网络环境和搜索质量的双重限制里。

OpenWebUI确实提供了多种联网搜索选项，比如DuckDuckGo、Google PSE、Bing等。但在实际使用中，你会发现这些选项各有各的问题：

  • DuckDuckGo：开箱即用，但搜索结果对中文内容支持有限，经常返回一些相关性不高的英文页面
  • Google PSE：需要API密钥，免费版限制严格（每天100次搜索），而且搜索结果质量与网页版Google相差甚远
  • Bing：API申请流程复杂，新用户基本无法通过，老用户也经常遇到部署失败的问题
  • Mojeek：速度慢得让人怀疑人生，有时候一个查询要等上十几秒

我在GitHub的OpenWebUI讨论区看到不少开发者都在抱怨这个问题。有人尝试了各种方案，最后发现要么效果差，要么根本用不了。更让人头疼的是，这些搜索引擎大多对国内网络环境不友好，要么访问不稳定，要么直接被屏蔽。

这时候SearXNG的优势就体现出来了。它是一个元搜索引擎，本身不维护搜索索引，而是聚合其他搜索引擎的结果。这意味着：

  1. 隐私保护：SearXNG不会跟踪用户，所有搜索请求都经过匿名化处理
  2. 高度可定制：你可以自由选择启用哪些搜索引擎，包括百度、360、搜狗等国内引擎
  3. API友好：提供JSON格式的输出，非常适合程序化调用
  4. 自托管：完全控制在自己手里，不用担心服务突然不可用

但SearXNG也不是完美无缺。最大的问题是官方Docker镜像默认不包含国内搜索引擎的配置文件。如果你直接部署，很可能会遇到这样的错误：

[Errno 2] No such file or directory: '/usr/local/searxng/searx/engines/baidu.py'

这就是为什么很多人在配置SearXNG时卡住的原因。不过别担心，后面的章节我会详细讲解如何解决这个问题。

2. SearXNG部署详解：从零搭建可用的元搜索引擎

部署SearXNG有多种方式，包括Kubernetes、手动安装和Docker Compose。考虑到易用性和维护性，我强烈推荐使用Docker Compose方案。下面是我优化后的配置流程，已经避开了大部分常见的坑。

2.1 环境准备与基础部署

首先确保你的服务器已经安装了Docker和Docker Compose。如果还没有，可以参考官方文档进行安装。这里假设你使用的是Ubuntu 22.04或更高版本的系统。

# 更新系统包 sudo apt update && sudo apt upgrade -y # 安装Docker（如果尚未安装） curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # 安装Docker Compose sudo apt install docker-compose-plugin -y # 验证安装 docker --version docker compose version

接下来创建SearXNG的工作目录并获取配置文件：

# 创建专用目录 mkdir -p ~/searxng-docker && cd ~/searxng-docker # 克隆官方仓库（包含Docker配置） git clone https://github.com/searxng/searxng-docker.git .
注意：如果你在国内，GitHub克隆可能会很慢。可以考虑使用镜像源，或者先下载ZIP包再解压。

2.2 Docker Compose配置优化

官方提供的docker-compose.yaml文件包含Caddy反向代理，但对于大多数内网部署场景来说，这个组件不是必需的。我建议使用简化版的配置，只保留核心服务。

创建或修改docker-compose.yaml文件：

version: "3.7" services: redis: container_name: redis image: docker.io/valkey/valkey:8-alpine command: valkey-server --save 30 1 --loglevel warning restart: unless-stopped networks: - searxng volumes: - valkey-data:/data logging: driver: "json-file" options: max-size: "1m" max-file: "1" searxng: container_name: searxng image: searxng/searxng:latest restart: unless-stopped networks: - searxng ports: - "8080:8080" # 可以根据需要修改端口 volumes: - ./searxng:/etc/searxng:rw - ./engines:/usr/local/searxng/searx/engines:rw # 关键：持久化引擎目录 environment: - SEARXNG_BASE_URL=http://${SEARXNG_HOSTNAME:-localhost}:8080/ - UWSGI_WORKERS=${SEARXNG_UWSGI_WORKERS:-4} - UWSGI_THREADS=${SEARXNG_UWSGI_THREADS:-4} - SEARXNG_SETTINGS_PATH=/etc/searxng/settings.yml logging: driver: "json-file" options: max-size: "1m" max-file: "1" networks: searxng: volumes: valkey-data: driver: local driver_opts: type: none o: bind device: /data/searxng-docker/redis

这里有几个关键点需要注意：

  1. 移除了Caddy服务：对于内网部署，直接用Nginx或直接访问端口更简单
  2. 持久化引擎目录：这是支持国内搜索引擎的关键，后面会详细说明
  3. 使用Valkey替代Redis：Valkey是Redis的分支，兼容性更好，性能也有所提升
  4. 网络配置：使用自定义网络，方便后续与OpenWebUI容器通信

2.3 配置文件深度定制

SearXNG的配置文件位于./searxng/settings.yml。首次启动容器时会自动生成默认配置，但我们需要对其进行定制以支持国内搜索引擎。

首先创建必要的目录结构：

# 创建配置目录 mkdir -p searxng engines # 首次启动以生成默认配置 docker compose up -d sleep 10 # 等待容器启动 docker compose down # 停止容器以修改配置

现在我们来修改searxng/settings.yml文件。以下是我经过多次测试优化的配置：

# 使用默认设置作为基础 use_default_settings: true server: # base_url在环境变量SEARXNG_BASE_URL中定义 secret_key: "你的安全密钥" # 使用openssl rand -hex 32生成 limiter: false # 私有实例可以禁用限制器 image_proxy: true # 启用图片代理，保护用户隐私 ui: static_use_hash: true redis: url: redis://redis:6379/0 search: formats: - html - json # 必须启用JSON格式，OpenWebUI需要 # 搜索引擎配置 - 重点部分 engines: # 启用国内搜索引擎 - name: baidu categories: - web - news - general engine: baidu shortcut: bd timeout: 9.0 disabled: false enable_http: false # 强制使用HTTPS - name: 360search categories: - web - news - general engine: 360search shortcut: 360so timeout: 9.0 disabled: false enable_http: false - name: sogou categories: - web - news - general engine: sogou shortcut: sg timeout: 9.0 disabled: false # 禁用部分不常用或访问慢的国外引擎 - name: google engine: google disabled: true # 国内访问困难，建议禁用 - name: bing engine: bing disabled: true # API限制严格 - name: duckduckgo engine: duckduckgo disabled: true - name: startpage engine: startpage disabled: true # 保留一些有用的国外引擎（可选） - name: wikipedia engine: wikipedia disabled: false timeout: 15.0 # 维基百科可以慢一点 - name: github engine: github disabled: false shortcut: gh
提示：secret_key需要自己生成，可以使用命令openssl rand -hex 32。Windows用户可以用PowerShell：<

Read more

Flutter 组件 powersync_core 的适配 鸿蒙Harmony 实战 - 驾驭极致离线优先架构、实现鸿蒙端高性能 SQL 增量同步与数据安全治理方案

Flutter 组件 powersync_core 的适配 鸿蒙Harmony 实战 - 驾驭极致离线优先架构、实现鸿蒙端高性能 SQL 增量同步与数据安全治理方案

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 powersync_core 的适配 鸿蒙Harmony 实战 - 驾驭极致离线优先架构、实现鸿蒙端高性能 SQL 增量同步与数据安全治理方案 前言 在鸿蒙（OpenHarmony）生态的大规模野外作业系统、高密社交协作平台以及对数据一致性有“零时延要求”的各类金融生产应用开发中，“离线状态下的业务连续性”不仅是功能加分项，更是决定系统存亡的基础底座。面对在地铁中产生的 1,000 条即时消息、在偏远林区采集的数万个传感器样本。如果不具备一套成熟的“离线存储 -> 增量对齐 -> 自动冲突解决”机制。不仅会导致用户在重新联网后遭遇由于“版本覆盖”引发的严重数据丢失，更会因为全量拉取带来的巨大网络带宽压力。引发鸿蒙应用在高频刷新场景下的崩溃。 我们需要一种“本地为王、差量对齐”的同步艺术。

By Ne0inhk

Dify平台的Webhook机制配置与使用场景

Dify平台的Webhook机制配置与使用场景 在企业加速智能化转型的今天，一个常见但棘手的问题摆在面前：如何让大语言模型（LLM）的能力真正嵌入到现有的业务流程中？很多团队尝试过自研AI客服、智能工单系统，结果却往往止步于“演示可用”，上线即卡顿——原因不在于模型不够强，而在于系统之间像孤岛一样难以协同。 Dify的出现改变了这一局面。作为一款开源的可视化AI应用开发平台，它不仅简化了提示工程和Agent编排，更重要的是通过Webhook机制打通了外部系统与AI引擎之间的“最后一公里”。这个看似简单的HTTP回调功能，实则是实现事件驱动、实时响应和跨系统联动的核心枢纽。 Webhook本质上是一种“反向API”：不是你去问系统有没有新数据，而是系统在事件发生时主动告诉你。这种模式在Dify中有两种典型用途： * 作为输入入口：当用户在网页提交咨询、CRM创建新客户记录时，自动触发Dify中的AI流程； * 作为输出出口：将AI生成的内容（如回复建议、结构化摘要）实时推送到企业微信、短信网关或ERP系统。 举个例子，某电商公司在其售后页面集成了Dify构建的智能助手。用户

By Ne0inhk
绿联云NAS配置webdav

绿联云NAS配置webdav

前言         zotero使用webdav服务时使用绿联自带的webdav服务只能使用http协议，并且只能在局域网内传输，故而尝试自行配置，以期实现公网文献同步。 注：非专业，自己在配置的时候也是根据前人的分享实现的，可能有很多不准确的地方，请见谅。 1. 大致思路         购买域名（腾讯云）→配置DDNS-go（docker）→获取SSL证书（乐此加密）→配置natfrp（docker） ①域名：固定域名，后续内网穿透时可以使用自定义域名； ②DDNS-go：自动更新域名解析到公网IP； ③SSL证书：https协议需要； ④natfrp：内网穿透需要，这里使用的是Sakura Frp。 2.参考文献 (31 封私信 / 80 条消息) 绿联 NAS 域名直连 DDNS-Go+IPv6 内网穿透并开启 HTTPS - 知乎https://zhuanlan.zhihu.com/p/

By Ne0inhk
实战：手写一个通用Web层鉴权注解，解决水平权限漏洞

实战：手写一个通用Web层鉴权注解，解决水平权限漏洞

实战：手写一个通用Web层鉴权注解，解决水平权限漏洞 * 一、背景：一次渗透测试引发的改造 * 二、需求分析：如何高效修复 * 三、业务模型：用户-公司授权关系 * 四、整体架构设计 * 五、代码实现：一步一步来 * 5.1 注解定义 * 5.2 权限管理服务 * 5.3 AOP切面：核心逻辑 * 六、使用示例 * 6.1 场景1：最简单的用法 * 6.2 场景2：对象属性 * 6.3 场景3：批量操作 * 6.4 场景4：嵌套属性 * 6.5 场景5：类级别默认配置 * 七、

By Ne0inhk