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

【前端实战】构建 Vue 全局错误处理体系,实现业务与错误的清晰解耦

【前端实战】构建 Vue 全局错误处理体系,实现业务与错误的清晰解耦

目录 【前端实战】构建 Vue 全局错误处理体系,实现业务与错误的清晰解耦 一、为什么要做全局错误处理? 1、将业务逻辑与错误处理解耦 2、为监控和埋点提供统一入口 二、Vue 中的基础全局错误处理方式 1、Vue 中全局错误处理写法 2、它会捕获哪些错误? 3、它不会捕获哪些错误? 4、errorHandler 的参数含义 三、全局错误处理的进阶设计 1、定义“可识别的业务错误” 2、在 errorHandler 中做真正的“分类处理” 3、补齐 Promise reject 的捕获能力 4、错误处理的策略化封装 四、结语         作者:watermelo37         ZEEKLOG优质创作者、华为云云享专家、阿里云专家博主、腾讯云“

前端部署:别让你的应用在上线后掉链子

前端部署:别让你的应用在上线后掉链子 毒舌时刻 这部署流程写得跟绕口令似的,谁能记得住? 各位前端同行,咱们今天聊聊前端部署。别告诉我你还在手动上传文件到服务器,那感觉就像在石器时代用石头砸坚果——能用,但效率低得可怜。 为什么你需要自动化部署 最近看到一个项目,部署时需要手动复制文件到服务器,每次部署都要花上几个小时。我就想问:你是在做部署还是在做体力活? 反面教材 # 反面教材:手动部署 # 1. 构建项目 npm run build # 2. 压缩文件 zip -r build.zip build # 3. 上传到服务器 scp build.zip user@server:/var/www/html # 4. 登录服务器 ssh user@server # 5. 解压文件 unzip

Youtu-VL-4B-Instruct源码实战:基于Gradio自定义组件扩展WebUI的图片批处理功能

Youtu-VL-4B-Instruct源码实战:基于Gradio自定义组件扩展WebUI的图片批处理功能 1. 引言:从单张到批量,解放生产力的新思路 如果你用过Youtu-VL-4B-Instruct的WebUI,肯定体验过它的强大——上传一张图片,问几个问题,模型就能给出精准的回答。无论是识别图片里的文字,还是描述复杂的场景,这个40亿参数的多模态模型都表现得相当不错。 但不知道你有没有遇到过这样的场景:手头有几十张产品图片需要批量添加描述,或者有一堆文档截图需要统一提取文字。这时候,一张一张上传、等待、再上传,效率实在太低了。每次操作都要重复“上传-等待-复制结果”的流程,不仅耗时,还容易出错。 这就是我们今天要解决的问题。原生的WebUI界面虽然友好,但在批量处理方面存在明显短板。它就像一家只接受堂食的餐厅,味道很好,但没法做外卖。而我们需要的是能同时处理多份订单的中央厨房。 好消息是,Gradio框架给了我们足够的灵活性。通过深入源码,我们可以自己动手,为这个WebUI增加一个“图片批处理”功能。想象一下,一次性上传几十张图片,设置好统一的提问模板,然后去喝杯咖

基于Canvas和Web Audio API的交互式烟花动画网页游戏

基于Canvas和Web Audio API的交互式烟花动画网页游戏

一个基于 Canvas 和 Web Audio API 的交互式烟花动画网页 目录 1. 整体架构 2. HTML 结构 3. CSS 样式 4. JavaScript 核心模块 5. 用户交互 6. 性能优化 7. iOS 适配 8. 文件依赖 一、整体架构 ┌─────────────────────────────────────────────────────────────┐ │ HTML 结构 │ ├─────────────────────────────────────────────────────────────┤ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ │ │ SVG 图标 │ │ Canvas容器 │ │ 控制面板/菜单 │ │ │ └─────────────┘ └─────────────┘ └─────────────────────┘ │ ├──────────────────────────────────────────────────────