ClawdBot步骤详解:前端无法访问时的SSH端口转发与Token链接获取

ClawdBot步骤详解:前端无法访问时的SSH端口转发与Token链接获取

1. ClawdBot是什么:你的本地AI助手,不依赖云端服务

ClawdBot 是一个真正属于你自己的个人 AI 助手——它不是网页上点几下就用的 SaaS 工具,而是一个能完整运行在你本地设备(笔记本、台式机、甚至树莓派)上的独立应用。它不像很多“AI助手”那样把你的提示词悄悄发到远端服务器,而是把模型推理、对话管理、插件调度全部留在你自己的机器里。

它的后端由 vLLM 驱动,这意味着你能以极高的吞吐和极低的延迟运行像 Qwen3-4B-Instruct 这样的高质量开源模型。vLLM 的 PagedAttention 技术让显存利用更高效,4GB 显存也能稳稳跑起 4B 级别模型,响应快、不卡顿、不排队。

更重要的是,ClawdBot 的设计哲学是“可控即可靠”。所有配置文件明文可读、所有模型路径清晰可见、所有日志本地留存。你不需要成为 DevOps 工程师,但你永远知道数据在哪、模型在哪、权限在哪。它不是黑盒,而是一套透明、可审计、可定制的本地智能中枢。

这和 MoltBot 形成鲜明互补:MoltBot 是为 Telegram 群聊量身打造的“多语言翻译官”,开箱即用、语音图片全支持、5 分钟上线;而 ClawdBot 则是你私有的“AI工作台”,它不直接对接社交平台,但为你提供底层能力——你可以把它当作 MoltBot 的本地大模型引擎,也可以单独用它写报告、理思路、查资料、编代码。

简单说:MoltBot 解决“怎么把 AI 能力快速塞进群聊”,ClawdBot 解决“怎么让 AI 能力完全听你指挥”。

2. 前端打不开?别急,这是本地部署的正常现象

刚装好 ClawdBot,兴冲冲打开浏览器输入 http://localhost:7860,结果页面一片空白,或者提示“连接被拒绝”“无法访问此网站”——这太常见了,而且完全不是故障,而是本地部署的默认状态

原因很实在:ClawdBot 的 Web 控制台(基于 Gradio 构建)默认只绑定在 127.0.0.1:7860,也就是“仅本机可访问”。它不会自动暴露给局域网,更不会开放到公网。这是安全设计,不是 bug。就像你家门锁着,不是坏了,是本来就不该随便让人进来。

所以当你在远程服务器(比如云主机、NAS 或树莓派)上部署时,直接在自己电脑浏览器里敲 IP 地址,自然连不上——因为请求根本没走到那台机器的 7860 端口,中途就被网络拦下了。

这时候有两个核心问题要解决:

  • 第一,如何让本地浏览器能“触达”远程服务器上的 7860 端口?
  • 第二,即使连上了,为什么还会跳转到登录页或报 403?Token 是什么,从哪来?

答案就藏在 clawdbot dashboard 这条命令里。它不只是告诉你 URL,而是一整套“安全隧道 + 访问凭证”的交付方案。

3. 三步打通访问链路:从终端命令到可用界面

3.1 第一步:执行 clawdbot dashboard,拿到完整访问信息

这是最关键的起点。不要跳过,不要凭记忆输地址,一定要运行这条命令:

clawdbot dashboard 

你会看到类似这样的输出:

🦞 Clawdbot 2026.1.24-3 (885167d) — Your .env is showing; don't worry, I'll pretend I didn't see it. Dashboard URL: http://127.0.0.1:7860/?token=23588143fd1588692851f6cbe9218ec6b874bb859e775762 Copy to clipboard unavailable. No GUI detected. Open from your computer: ssh -N -L 7860:127.0.0.1:7860 [email protected] Then open: http://localhost:7860/ http://localhost:7860/?token=23588143fd1588692851f6cbe9218ec6b874bb859e775762 Docs: https://docs.clawd.bot/gateway/remote https://docs.clawd.bot/web/control-ui 

注意三点:

  • Dashboard URL 后面的地址是服务器内部视角的地址,你本地浏览器不能直连;
  • ssh -N -L ... 这行是给你本地电脑用的 SSH 端口转发命令,复制它;
  • 最后两个 http://localhost:7860/...你本地浏览器最终要访问的地址,带 token 才能进。

3.2 第二步:在你自己的电脑上执行 SSH 端口转发

打开你本地的终端(Mac/Linux)或 PowerShell(Windows),粘贴并运行那条 ssh 命令:

ssh -N -L 7860:127.0.0.1:7860 [email protected] 

说明一下参数含义:

  • -N:不执行远程命令,只做端口转发(安静地搭桥);
  • -L 7860:127.0.0.1:7860:把你本地的 7860 端口,映射到远程服务器的 127.0.0.1:7860
  • [email protected]:换成你实际的服务器用户名和 IP(如 [email protected])。

执行后,终端会保持连接状态(没有新提示符,也不报错),这就对了——隧道已建立。此时,你本地的 localhost:7860 就等价于服务器的 127.0.0.1:7860

小技巧:如果 SSH 连接需要密码,提前配好密钥;如果提示“Permission denied”,检查用户名/IP 是否正确,或是否开启了 SSH 服务(sudo systemctl status ssh)。

3.3 第三步:在本地浏览器打开带 Token 的链接

现在,回到你本地电脑的浏览器,直接访问:

http://localhost:7860/?token=23588143fd1588692851f6cbe9218ec6b874bb859e775762 

注意:必须带完整的 ?token=... 参数,缺一不可。这个 token 是一次性、有时效、绑定会话的访问凭证,不是密码,也不是 API Key,它只是告诉 ClawdBot:“这个请求来自合法的 dashboard 命令发起者,请放行”。

如果你看到熟悉的 Gradio 界面(左侧菜单栏、顶部模型选择、中间聊天框),恭喜,链路完全打通。

常见误区提醒:不要尝试访问 http://100.64.232.100:7860(服务器公网IP),它默认不监听外部;不要删掉 URL 里的 ?token=...,否则会返回 403 Forbidden;如果浏览器提示“不安全连接”,忽略即可(本地自签名证书,不影响功能)。

4. 如果还是打不开?检查设备授权与配置文件

即使走通了 SSH 隧道,有时仍会卡在白屏或 403。这时大概率是 ClawdBot 的设备信任机制在起作用——它把 Web 访问也当作一次“设备接入”,需要手动批准。

4.1 查看待处理的设备请求

在服务器终端中运行:

clawdbot devices list 

你会看到类似输出:

ID Status Created At Last Seen abc123 pending 2026-01-25 14:22:01 - def456 approved 2026-01-24 09:15:33 2026-01-25 14:20:18 

只要存在 pending 状态的条目,就说明你的这次浏览器访问被识别为新设备,但尚未授权。

4.2 手动批准该设备

复制 pending 行的 ID(如 abc123),执行:

clawdbot devices approve abc123 

命令无输出即成功。稍等 5 秒,刷新你本地浏览器的 http://localhost:7860/?token=... 页面,界面就会正常加载。

4.3 配置文件位置与关键路径

所有配置都集中在一个地方,方便排查:

  • 主配置文件/app/clawdbot.json(容器内路径,已映射)
  • 用户级配置~/.clawdbot/clawdbot.json(宿主机路径)

如果你改过配置但没生效,记得检查是不是改错了位置。ClawdBot 优先读取 /app/clawdbot.json,这个文件在 Docker 容器启动时由 volume 映射进来,修改后需重启容器(docker restart clawdbot)或执行 clawdbot reload(如果支持)。

5. 模型怎么换?两种方式,推荐配置文件法

ClawdBot 默认用 vllm/Qwen3-4B-Instruct-2507,但你完全可以换成其他模型。有两种方式,我们推荐第一种——它稳定、可复现、适合生产环境。

5.1 方式一:修改 /app/clawdbot.json(推荐)

打开配置文件,找到 "models""agents" 区块。重点改两处:

设置默认模型(让所有对话自动用它):

"agents": { "defaults": { "model": { "primary": "vllm/Qwen3-4B-Instruct-2507" } } } 

指定 vLLM 服务地址(确保和你的 vLLM 启动命令一致):

"providers": { "vllm": { "baseUrl": "http://localhost:8000/v1", "apiKey": "sk-local", "api": "openai-responses", "models": [ { "id": "Qwen3-4B-Instruct-2507", "name": "Qwen3-4B-Instruct-2507" } ] } } 

改完保存,重启 ClawdBot(或执行 clawdbot reload),再运行:

clawdbot models list 

如果看到 vllm/Qwen3-4B-Instruct-2507 出现在列表里,且 Local Auth 列显示 yes,说明模型已成功注册。

5.2 方式二:通过 UI 界面修改(适合快速试用)

进入已打开的 Web 界面 → 左侧菜单点 ConfigModelsProviders → 找到 vllm 条目 → 点击右侧铅笔图标 → 在 Models 数组里添加新模型 JSON。

注意:UI 修改是实时生效的,但不会写回 /app/clawdbot.json。一旦容器重启,修改会丢失。所以仅建议用于临时测试。

6. 关于 Telegram 频道配置:国内环境下的务实建议

文档里提到的 channel-telegram 配置,目标是让 ClawdBot 直接作为 Telegram Bot 运行。但现实很骨感:Telegram 在国内无法直连,必须依赖代理。

配置本身很简单(填 botToken、开 proxy),但问题在于:

  • 代理稳定性难保障(尤其 SOCKS5);
  • Telegram 的 webhook 或 polling 模式在国内延迟高、易断连;
  • 消息往返链路变长,影响实时翻译体验(MoltBot 的 0.8s 响应就很难复现)。

所以我们的建议很明确:不要在 ClawdBot 上硬接 Telegram
更好的组合是——用 MoltBot 做 Telegram 入口(它专为 Telegram 优化,内置代理、fallback、离线 OCR),用 ClawdBot 做本地大模型后端(你可以在 MoltBot 的配置里,把翻译/问答请求转发给 http://localhost:8000/v1/chat/completions)。这样分工明确:MoltBot 负责“接得住”,ClawdBot 负责“答得好”。

一句话总结:ClawdBot 是大脑,MoltBot 是嘴巴。让嘴巴连 Telegram,让大脑专注思考。

7. 总结:掌握这四件事,你就真正掌控了 ClawdBot

ClawdBot 的价值,不在于它有多炫的界面,而在于它把 AI 能力的控制权,稳稳交还到你手上。要真正用好它,你只需要彻底搞懂以下四件事:

  • 访问逻辑clawdbot dashboard 不是“查看地址”,而是“生成隧道指令 + 访问凭证”的完整交付包;SSH 端口转发是本地开发者的必备技能,不是障碍。
  • Token 本质:它不是密码,不是密钥,而是一次性会话令牌,由 dashboard 命令动态生成,必须原样拼在 URL 后,缺一不可。
  • 设备授权:Web 访问受设备信任链保护,clawdbot devices listapprove 是绕过白屏的黄金组合,比重启服务快十倍。
  • 模型管理:改配置文件 > 改 UI,clawdbot models list 是唯一可信的验证手段,看到 Local Auth: yes 才算真正就位。

当你不再把 ClawdBot 当作一个“要配好才能用”的工具,而是理解它每一层设计背后的意图——安全绑定、本地优先、配置透明——你就已经跨过了从使用者到掌控者的门槛。


获取更多AI镜像

想探索更多AI镜像和应用场景?访问 ZEEKLOG星图镜像广场,提供丰富的预置镜像,覆盖大模型推理、图像生成、视频生成、模型微调等多个领域,支持一键部署。

Read more

Z-Image-Turbo WebUI界面操作详解,图文并茂

Z-Image-Turbo WebUI界面操作详解,图文并茂 Z-Image-Turbo 不仅以轻量化、高效率著称,更通过一套直观清晰的 WebUI 界面,将专业级图像生成能力交到每位用户手中。无需命令行调试、不需代码基础,打开浏览器就能开始创作——这正是它区别于传统模型部署方式的核心优势。本文将全程聚焦 UI 操作本身,手把手带你熟悉每一个按钮、每一处设置、每一种交互逻辑,并结合真实界面截图,还原你在本地运行时的真实体验。 全文不讲原理、不谈部署、不写代码(除必要命令外),只做一件事:让你在 10 分钟内,真正“会用”这个界面。 1. 启动服务:从黑框到绿色提示,确认就绪的关键信号 Z-Image-Turbo 的 WebUI 基于 Gradio 构建,启动过程简洁直接。你只需在终端中执行一条命令: python /Z-Image-Turbo_gradio_ui.py

通过URI Scheme实现从Web网页上打开本地C++应用程序(以腾讯会议为例,附完整实现源码)

通过URI Scheme实现从Web网页上打开本地C++应用程序(以腾讯会议为例,附完整实现源码)

目录 1、需求描述 2、选择URI Scheme实现 3、何为URI Scheme? 4、将自定义的URL Scheme信息写入注册表的C++源码实现 5、如何实现最开始的3种需求 6、后续需要考虑的细节问题        之前陆续收到一些从Web页面上启动我们C++客户端软件的需求,希望我们能提供一些技术上的支持与协助,支持从Web网页上将我们的C++客户端软件启动起来。于是我大概地研究了相关的实现方法,下面把研究的过程与结果在此做一个分享,希望能给大家提供一个借鉴或参考。 C++软件异常排查从入门到精通系列教程(核心精品专栏,订阅量已达10000多个,欢迎订阅,持续更新...)https://blog.ZEEKLOG.net/chenlycly/article/details/125529931C/C++实战专栏(重点专栏,专栏文章已更新500多篇,订阅量已达8000多个,欢迎订阅,持续更新中...)https://blog.ZEEKLOG.net/

基于C++11手撸前端Promise

基于C++11手撸前端Promise

文章导航 * 引言 * 前端Promise的应用与优势 * 常见应用场景 * 并发请求 * Promise 解决的问题 * 手写 C++ Promise 实现 * 类结构与成员变量 * 构造函数 * resolve 方法 * reject 方法 * then 方法 * onCatch 方法 * 链式调用 * 使用示例 * `std::promise` 与 `CProimse` 对比 * 1. 基础功能对比 * 2. 实现细节对比 * (1) 状态管理 * (2) 回调注册与执行 * (3) 异步支持 * (4) 链式调用 * 3. 代码示例对比 * (1) `CProimse` 示例 * (2) `std::promise` 示例 * 4.

前端三剑客:HTML、CSS、JavaScript是如何协同工作的?

前端三剑客:HTML、CSS、JavaScript是如何协同工作的?

作为前端开发的基石,HTML、CSS、JavaScript 被称为“前端三剑客”,三者各司其职又深度协同,共同构建出我们每天浏览的网页——从简单的静态页面到复杂的交互应用,每一处呈现与操作都离不开它们的配合。 对于前端初学者而言,理解三者的协同逻辑,是入门前端开发的关键一步。今天就来拆解它们的分工与协作流程,结合实操案例帮大家吃透核心逻辑。 一、先明确分工:三剑客各自的“岗位职责” 要理解协同,首先要分清三者的核心定位——它们如同盖房子的三个核心工种,各自负责不同环节,缺一不可。 1. HTML:网页的“骨架”,搭建内容结构 HTML(超文本标记语言)是网页的基础,核心作用是定义内容的结构与语义,相当于盖房子时的钢筋水泥框架,决定了网页有哪些内容、内容的层级和关系,不负责美观与交互。 比如我们写一段简单的HTML代码,就能搭建出网页的基础结构: 这段代码定义了网页的层级:html 是根节点,包含 head(配置信息)和 body(可视内容),body 里有容器、