Docker 部署 OpenClaw 踩坑实录:Web UI 访问、飞书配对及自定义模型配置

最近在使用 Docker 部署 OpenClaw 时遇到了一些典型的环境与配置问题。为了方便大家排查,我将这几个核心问题的表现、解决思路以及如何接入公司自己配置的大模型节点进行了梳理。


一、问题一:安装成功但 Web UI 无法访问

1. 现象描述

  • 终端提示安装成功,但在浏览器中访问http://127.0.0.1:18789 时,页面提示连接被重置。
  • 使用具体的局域网 IP(如192.168.5.30:18789)访问时,同样提示无法连接或无法访问此网站。
alt

2. 原因分析

  • 在排除了代理服务器和系统防火墙的干扰后,根本原因在于 OpenClaw 核心网关的跨域访问(CORS)安全机制。
  • 系统默认包含白名单配置,它的作用是告诉 OpenClaw 的核心网关:“只有从这些特定的网址(域名或IP)打开的控制台网页,才被允许连接我并下发控制指令”。

3. 解决方案

修改 OpenClaw 的配置文件~/.opneclaw/openclaw.json,在gateway.controlUi.allowedOrigins 节点中加上* 作为通配符(或添加你实际访问的 URL)。具体配置参考如下:

"gateway": {
  "port": 18789,
  "mode": "local",
  "bind": "lan",
  "controlUi": {
    "allowedOrigins": [
      "*",
    ],
    "dangerouslyDisableDeviceAuth": true
  }
}


二、问题二:飞书机器人配对失败与配对码刷新

1. 现象描述

  • 在系统内设置了飞书 Channel 后,通过飞书机器人发送消息没反应,系统提示未配对,并给了一个配对码。
  • 给飞书发送多次消息,配对码会不断发生改变。
alt

2. 解决方案

由于多次发消息导致配对码不断刷新,我们需要通过后台 CLI 指令直接查看并抓取最新、最准确的配对请求进行手动授权。

  1. 查看最新的飞书配对请求:执行docker compose run --rm openclaw-cli pairing list feishu 命令查看当前的配对列表。
alt
  1. 获取正确配对码:在输出的表格中,找到最新的配对码(例如:ZLX3M556)。
  2. 执行授权配对:拿到正确的配对码后,执行docker compose run --rm openclaw-cli pairing approve feishu ZLX3M556 命令通过审批。当日志输出类似Approved feishu sender ou_... 后,即代表授权成功。
alt

三、进阶配置:接入公司自行配置的大模型

OpenClaw 支持灵活地接入公司自己配置的大模型节点。配置 Agent 的方法同样是修改~/.openclaw/openclaw.json 文件。

以下是接入公司自行配置的、提供 MiniMax 模型的高速自定义节点的配置示例:

{
  "agents": {
    "defaults": {
      "model": "yuxiaor/MiniMax-M2.7-highspeed"
    }
  },
  "models": {
    "mode": "merge",
    "providers": {
      "yuxiaor": {
        "api": "openai-completions",
        "baseUrl": "http://xxxxxxxxxxx/v1",
        "apiKey": "your key",
        "models": [
          { "id": "MiniMax-M2.7-highspeed", "name": "MiniMax 2.7 highspeed" }
        ]
      }
    }
  }
}

配置解析:

  • 在models.providers 节点下自定义公司自行配置的节点名称(如yuxiaor),并将其 API 格式指定为兼容性最好的openai-completions。
  • 填入公司配置节点提供的baseUrl和对应的apiKey。
  • 在agents.defaults.model 中,将默认模型指向刚才声明的节点与模型名称(如yuxiaor/MiniMax-M2.7-highspeed)。这样配置并重启后,OpenClaw 默认就会调用公司配置的模型来进行回复了。
alt

本文由 mdnice 多平台发布

Read more

Java Web 公交线路查询系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

Java Web 公交线路查询系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

摘要 随着城市化进程的加速,公共交通系统的复杂性和规模不断扩大,传统的公交线路查询方式已难以满足用户高效、精准的出行需求。公交线路查询系统的开发旨在解决这一问题,通过信息化手段提升公交出行的便捷性和智能化水平。该系统整合了公交线路、站点、换乘等关键信息,为用户提供实时查询、最优路径推荐等功能,同时优化公交资源管理效率。关键词:公交线路查询、智能化出行、信息化管理、SpringBoot、Vue3。 本系统采用前后端分离架构,后端基于SpringBoot2框架,结合MyBatis-Plus实现高效数据持久化操作,MySQL8.0作为数据库存储公交线路、站点及用户信息。前端使用Vue3构建响应式用户界面,提供线路查询、换乘推荐、站点导航等功能。系统支持多条件筛选和动态路径规划,确保用户能够快速获取最优出行方案。关键词:SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0、路径规划。 数据表 公交线路数据表 公交线路数据表用于存储公交线路的基本信息,包括线路名称、运营方向、首末班时间等属性。线路编号是该表的主键,用于唯一标识每条线路。结构表如表3-1所示。

轻松搭建个人WebDAV文件服务器:小白也能快速上手

轻松搭建个人WebDAV文件服务器:小白也能快速上手 【免费下载链接】webdavSimple Go WebDAV server. 项目地址: https://gitcode.com/gh_mirrors/we/webdav 还在为多设备间文件同步而烦恼吗?想要拥有一个安全可靠的文件共享平台吗?这个基于Go语言开发的WebDAV服务器正是你需要的解决方案。它简单易用、功能强大,让你轻松搭建专属的文件管理服务。 🎯 快速上手:三种部署方式任你选 方式一:一键安装(推荐新手) # 使用Homebrew安装 brew install webdav # 使用Go工具链安装 go install github.com/hacdias/webdav/v5@latest 方式二:Docker容器化部署 docker run -p 6060:6060 -v $(pwd)/data:/data

微信 H5 缓存控制:后端重定向 & 前端强制刷新

在 Web 开发中,缓存是一把双刃剑。对于静态资源,它能极大提升加载速度;但对于业务逻辑频繁变动的 H5 页面(如支付、订单页),缓存往往会导致用户看到过期的数据或界面。最近在维护一个 uni-app 项目时,遇到了一段关于 H5 缓存控制的逻辑,引发了我对于“后端重定向加时间戳”和“前端 JS 加时间戳”这两种方案的思考。虽然两者的最终目的一致,但在 Hash 模式下,它们的实现原理和效果有着本质的区别。 一、 问题背景 在应用启动的生命周期中,通常会有这样一段逻辑:当用户访问特定的关键页面(如支付、订单页)时,如果当前 URL 中缺少时间戳参数,前端会自动解析 URL,追加当前时间戳,并强制页面刷新。 这就引出了一个问题:为什么不直接在后端重定向时加时间戳?这两种方式有什么区别? 二、 核心区别:

AI 时代,前端逆向的门槛已经低到离谱 — 以 Upwork 为例

我用 AI 逆向 Upwork 消息系统,2小时搞定数据层开发 前言 作为 Upwork 自由职业者,我一直觉得它的消息管理界面信息量太大,不够直观。我想做一个 Chrome 插件来简化消息管理,核心需求很简单:一眼看出哪些对话需要我回复,哪些在等对方。 传统做法是下载混淆后的 JS 文件慢慢分析,但这次我决定换个思路——全程和 AI 配合,看看能多快搞定。 结果远超预期。从零开始到完全摸清 API、认证方式、数据结构,总共不到 2 小时。 第一步:摸清技术栈(5分钟) 打开 Upwork 消息页面,F12 看 Sources 面板,从加载的 JS 文件名就能判断出技术栈: ThunderNuxt/rooms.fdb6ff58.