Clawdbot整合Qwen3-32B入门必看：Ollama API调用、端口映射、错误排查

1. 为什么需要Clawdbot + Qwen3-32B这套组合

你是不是也遇到过这些情况：想在内部系统里快速接入一个大语言模型，但又不想暴露公网接口；想用Qwen3-32B这种强推理能力的模型，却发现直接部署后和现有聊天平台对接不上；或者明明Ollama跑起来了，Clawdbot却连不上API，反复报错“connection refused”“timeout”“404 not found”。

这不是你配置错了，而是少了关键一环——服务链路的精准对齐。

Clawdbot本身不运行模型，它是个智能对话调度平台；Qwen3-32B是本地部署的重型模型，靠Ollama托管；而中间那层“代理直连Web网关”，才是真正让两者说上话的翻译官。本文不讲抽象原理，只聚焦三件事：
怎么让Ollama正确暴露Qwen3-32B的API
怎么把Clawdbot的请求稳稳送到18789网关
遇到连不通、返回空、响应慢时，5分钟内定位到根因

全程基于真实私有环境验证，所有命令、路径、端口均来自实测配置，不是文档搬运。

2. 环境准备与基础服务确认

在动手改配置前，请先确认这4个服务已就位且状态正常。少一个，后续全卡住。

2.1 检查Ollama是否真正运行Qwen3-32B

别只看ollama list里有没有qwen3:32b——那只是镜像存在。重点看它是否正在提供API服务：

# 查看Ollama服务状态（Linux/macOS）
systemctl is-active ollama

# 或检查进程（通用）
ps aux | grep ollama

# 确认模型已加载并可响应（关键！）
curl -X POST http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:32b",
    "messages": [{"role": "user", "content": "你好"}],
    "stream": false
  }'

正常返回：含"done": true和"message"字段的JSON
报错model not found：说明模型没拉取成功，执行ollama pull qwen3:32b
报错connection refused：Ollama服务未启动，运行ollama serve或systemctl start ollama

注意：Ollama默认监听127.0.0.1:11434，这是仅限本机访问的地址。Clawdbot若不在同一台机器，必须调整绑定地址。

2.2 确认Clawdbot服务已启动并监听8080端口

Clawdbot默认通过8080端口提供Web界面和API入口。验证方式：

# 检查端口占用
lsof -i :8080  # macOS/Linux
# 或
netstat -ano | findstr :8080  # Windows

# 访问健康检查接口（无需登录）
curl http://localhost:8080/health

返回{"status":"ok"}表示服务存活
Connection refused：Clawdbot未启动，检查启动日志中是否有Failed to bind to 0.0.0.0:8080

2.3 验证代理网关是否就绪（18789端口）

你提到“通过内部代理进行8080端口转发到18789网关”。这个网关是整条链路的枢纽。常见实现方式有Nginx、Caddy或自研反向代理。无论哪种，都需确认：

  • 代理服务正在运行（如systemctl is-active nginx）
  • 配置中明确将18789端口的请求透传给http://localhost:11434（不是8080！）
  • 代理未启用HTTPS重定向或强制跳转（会破坏API的POST请求）

一个极简Nginx转发配置示例（/etc/nginx/conf.d/clawdbot-qwen.conf）：

server {
    listen 18789;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:11434;  # 直连Ollama，非Clawdbot！
        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;
        proxy_buffering off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

重启后测试：

curl -v http://localhost:18789/api/tags

应返回Ollama的模型列表JSON
404或超时：检查代理配置路径、端口、目标地址是否写错

3. Clawdbot核心配置：三处关键修改

Clawdbot通过application.yml或环境变量配置后端模型地址。错误常发生在URL拼写、协议、路径三处。

3.1 定位配置文件

Clawdbot配置通常位于：

  • config/application.yml（Spring Boot项目标准位置）
  • 或启动时通过--spring.config.location=file:/path/to/config/指定

打开后找到类似llm:或ai.model:的配置块。

3.2 修改模型API地址（重点！）

原始配置可能类似：

llm:
  provider: ollama
  base-url: http://localhost:11434

这是错误的！ 因为Clawdbot和Ollama若不在同一台机器，localhost指向的是Clawdbot本机，而非Ollama所在服务器。

正确写法（使用代理网关地址）：

llm:
  provider: ollama
  base-url: http://your-server-ip:18789  # 替换为实际服务器IP
  model-name: qwen3:32b

关键细节：

  • base-url 必须是可被Clawdbot网络访问到的地址，不能写localhost（除非同机）
  • 端口必须是18789（你指定的代理端口），不是11434
  • 不要加/api后缀——Ollama SDK会自动拼接，加了反而404

3.3 验证Clawdbot能否连通代理网关

修改配置后，不要急着重启。先手动测试Clawdbot服务器能否访问18789：

# 在Clawdbot所在服务器执行
curl -v http://your-server-ip:18789/api/tags

返回Ollama模型列表 → 配置可生效
Failed to connect → 检查服务器防火墙（ufw status/firewall-cmd --list-all）是否放行18789端口
Connection timed out → 检查代理服务是否监听在0.0.0.0:18789（而非127.0.0.1:18789）

小技巧：用ss -tuln | grep 18789确认监听地址。若显示127.0.0.1:18789，需修改代理配置绑定0.0.0.0。

4. 常见错误排查清单（按发生频率排序）

遇到问题？别从头重装。按此清单逐项检查，90%的问题5分钟内解决。

4.1 “Connection refused” 错误

现象：Clawdbot日志出现java.net.ConnectException: Connection refused
根因TOP3：

  1. 代理网关根本没运行 → 执行systemctl status nginx或ps aux | grep caddy
  2. Clawdbot配置的IP/端口写错 → 检查base-url是否拼写错误，端口是否为18789
  3. 服务器防火墙拦截 → 运行sudo ufw allow 18789（Ubuntu）或sudo firewall-cmd --add-port=18789/tcp --permanent && sudo firewall-cmd --reload（CentOS）

4.2 “404 Not Found” 错误

现象：Clawdbot返回HTTP 404，日志显示Received 404 from LLM provider
根因TOP2：

  1. URL路径多写了/api → base-url: http://x.x.x.x:18789/api → 改为http://x.x.x.x:18789
  2. 代理配置中proxy_pass末尾多了/ → proxy_pass http://127.0.0.1:11434/; （会截断路径）→ 改为proxy_pass http://127.0.0.1:11434;

4.3 “Model not found” 错误

现象：Clawdbot提示Model qwen3:32b not found on provider
根因：

  • Ollama中模型名不匹配 → 运行ollama list，确认输出中精确显示qwen3:32b（注意冒号和大小写）
  • 若显示qwen3:latest，则Clawdbot配置中model-name需改为qwen3:latest
  • 模型未完全加载 → 执行ollama run qwen3:32b首次运行，等待下载完成再试

4.4 响应极慢或超时

现象：提问后等待30秒以上才返回，或直接报Read timeout
根因：

  • Qwen3-32B对GPU显存要求高（建议≥24GB），若OOM会严重降速 → nvidia-smi查看GPU内存占用
  • 代理未开启长连接 → Nginx配置中添加proxy_http_version 1.1;和proxy_set_header Connection '';
  • Clawdbot线程池过小 → 在application.yml中增加： 
    server:
  tomcat:
    max-connections: 500
    accept-count: 100

5. 进阶技巧：让Qwen3-32B发挥更强性能

配置通了只是起点。以下3个调整能显著提升实际体验：

5.1 启用Ollama的GPU加速（必须做）

Qwen3-32B纯CPU推理极慢。确保Ollama调用GPU：

# Linux + NVIDIA GPU
export OLLAMA_NUM_GPU=1
ollama serve

# 或启动时指定
OLLAMA_NUM_GPU=1 ollama serve

验证是否生效：运行ollama run qwen3:32b后，nvidia-smi应看到ollama进程占用显存。

5.2 调整Clawdbot的请求超时

Qwen3-32B生成长文本需更长时间。在application.yml中延长：

llm:
  timeout:
    connect: 30000   # 连接超时30秒
    read: 120000     # 读取超时120秒（关键！）
    write: 30000

5.3 使用流式响应提升交互感

Clawdbot支持SSE流式返回。在代理配置中必须开启WebSocket支持（Nginx示例）：

location /api/chat {
    proxy_pass http://127.0.0.1:11434;
    proxy_set_header Host $host;
    # 以下三行启用流式传输
    proxy_buffering off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

这样用户就能看到文字逐字生成，体验接近ChatGPT。

6. 总结：一条清晰的服务链路图

回顾整个流程，本质是构建一条无损、低延迟、可运维的数据通道：

Clawdbot (8080) 
    ↓ 发起HTTP请求（目标：http://x.x.x.x:18789/api/chat）
代理网关 (18789) 
    ↓ 反向代理（透传请求头+body）
Ollama (11434) 
    ↓ 加载qwen3:32b模型，GPU加速推理
    ↓ 返回JSON或SSE流

记住三个铁律：
🔹 Clawdbot的base-url永远指向代理端口（18789），不是Ollama原端口（11434）
🔹 代理必须监听0.0.0.0，不能只绑127.0.0.1
🔹 所有超时设置以Ollama实际推理耗时为准，宁长勿短

现在，打开你的Clawdbot Web界面（如http://your-server:8080），输入一个问题，看着Qwen3-32B用专业级逻辑给出回答——这才是私有大模型落地最踏实的时刻。

获取更多AI镜像

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

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

GPT-5.5 的 6 大使用误区，90% 开发者踩坑

avatar AI Agent技术社区
cover

灵梭：一个依赖，让你的 Spring Boot 应用会说话、会记忆、会思考、会行动

avatar AI Agent技术社区
cover

跑了12个AI Agent项目后，我算出了财务/客服/法务场景的真实ROI

avatar AI Agent技术社区