核心内容摘要
丁香般的叙事艺术：掌握“丁香婷婷拍拍拍”15字爆款标题的深层逻辑
ClawdbotQwen
B保姆级教程日志排查、错误码解读与
常见问题解决
为什么需要这篇教程你刚部署好Clawdbot也成功接入了Qwen
B大模型页面能打开、输入框能打字、发送按钮也能点——但一问就卡住或者返回“连接超时”“模型未响应”“502 Bad Gateway”这类提示。
你翻遍控制台看到一堆滚动日志却分不清哪条是关键线索你查文档发现错误码只有一行定义没说怎么修你重启服务问题照旧。
这不是你的问题。
Clawdbot Qwen
B 这套组合虽强大但涉及Ollama本地模型服务、Clawdbot应用层、Nginx/内部代理网关、端口转发链路四层协作任一环节出偏都会表现为“聊天没反应”。
而官方文档通常只讲“怎么装”不讲“坏了怎么查”。
本教程不重复部署步骤不堆砌参数说明全程聚焦你真正卡住的三个时刻日志里满屏滚动哪一行该盯控制台报ERR_CONNECTION_REFUSED或504 Gateway Timeout背后对应哪一层故障输入后无响应、响应延迟高、回答错乱——分别该检查什么所有操作均基于真实排障场景验证命令可复制粘贴判断逻辑清晰到能写进值班手册。
整体架构与关键链路图解在动手查问题前先建立一张“故障地图”。
Clawdbot调用Qwen
B不是直连而是经过明确的四段路径Clawdbot前端浏览器 ↓ HTTPS 请求80/443 Clawdbot后端服务Node.js ↓ HTTP 请求localhost:3000 → 代理转发 内部Web网关Nginx / 自研代理 ↓ 端口映射8080 → 18789 Ollama服务Qwen
B API关键节点与默认端口如下表所示后续所有排查都围绕它们展开组件默认监听地址作用常见异常表现Clawdbot后端http://localhost:3000接收前端请求构造对网关的代理请求ECONNREFUSED连不上3000端口、500 Internal Server ErrorWeb网关代理http://localhost:8080接收Clawdbot请求转发至Ollama502 Bad Gateway、504 Gateway TimeoutOllama API服务http://localhost:11434原始→ 映射为:18789提供/api/chat接口运行Qwen
Bcurl -v http://localhost:18789/api/chat无响应、超时Qwen
B模型加载状态—模型需预加载非启动即可用ollama list显示qwen3:32b但状态为not loaded重要提醒文中所有18789端口均为经网关映射后的对外暴露端口不是Ollama原生端口11434。
若直接 curl11434成功但18789失败问题一定出在网关或映射规则。
日志排查三步定位法日志不是用来“看全”的而是用来“抓关键信号”的。
我们按从外到内顺序逐层过滤无关信息3分钟锁定根因。
1 第一步看Clawdbot后端日志定位是否抵达应用层打开终端进入Clawdbot项目目录执行npm run dev # 或你实际使用的启动命令当在网页中发送一条消息后观察终端输出。
重点关注以下三类日志健康信号说明请求已进入ClawdbotPOST /api/chat 200或Forwarding to http://localhost:8080/api/chat→ 表示Clawdbot正常接收并开始代理问题不在前端或网络策略。
❌阻断信号Clawdbot自身异常Error: connect ECONNREFUSED ::1:3000TypeError: Cannot read property map of undefined→ 说明Clawdbot进程未启动、端口被占、或代码逻辑报错立即停止往下查先修复Clawdbot服务。
转发信号但无响应Clawdbot发出请求但没收到回包Forwarding to http://localhost:8080/api/chat→ 后续无Received response from gateway或任何HTTP状态码→ 问题在Clawdbot与网关之间进入第二步。
2 第二步看Web网关日志定位代理是否生效根据你使用的网关类型执行对应命令若使用Nginx最常见tail -f /var/log/nginx/error.log # 或查看access日志确认请求是否到达 tail -f /var/log/nginx/access.log | grep POST /api/chat若使用自研Go/Python代理查其运行终端或日志文件# 假设日志输出到 proxy.log tail -f ./logs/proxy.log关键判断依据网关收到请求日志中出现类似POST /api/chat HTTP/
1 502或POST /api/chat HTTP/
1 504→ 说明Clawdbot请求已抵达网关但网关无法从下游Ollama获得有效响应。
❌网关无任何日志tail -f后完全静默→ Clawdbot根本没把请求发到网关地址检查Clawdbot配置中的GATEWAY_URL是否为http://localhost:8080而非http://
127.
0.
1:8080或带https。
网关日志报连接拒绝connect() failed (111: Connection refused) while connecting to upstream→ 网关尝试连接localhost:18789失败说明Ollama服务未监听该端口或端口映射未生效。
3 第三步直连Ollama API验证模型服务是否就绪绕过所有中间层用curl直接测试Ollama接口是否可用# 测试基础连通性不带模型 curl -v http://localhost:18789 # 测试模型API发送最小化请求 curl -X POST http://localhost:18789/api/chat \ -H Content-Type: application/json \ -d { model: qwen3:32b, messages: [{role: user, content: 你好}], stream: false }结果分析返回JSON且含message.content字段说明Ollama服务、模型加载、端口映射全部正常。
问题必在Clawdbot或网关的请求构造如header缺失、body格式错误。
❌Failed to connect或Connection timed out检查Ollama是否运行ps aux | grep ollama检查端口映射ss -tuln | grep 18789应有LISTEN状态检查Ollama是否加载模型ollama list→ 确认qwen3:32b状态为loaded非not loaded返回404 Not Found或400 Bad Request说明端口通但API路径或参数有误。
重点检查Clawdbot发送的请求URL是否为/api/chat不是/chat或/v1/chat/completions以及model字段值是否严格匹配ollama list输出的名称区分大小写、冒号、空格。
错误码速查表与根因对照浏览器控制台F12 → Console或Clawdbot日志中出现的错误码是最快指向故障层的路标。
下表按出现频率从高到低排序每条均附可执行的验证命令错误码出现场景根本原因一句话诊断命令修复方向502 Bad Gateway网关日志或浏览器Network面板网关无法连接下游Ollamacurl -I http://localhost:18789检查Ollama是否运行、18789端口是否监听、模型是否loaded504 Gateway Timeout网关日志或浏览器Network面板网关连上了Ollama但Ollama未在超时时间内返回ollama ps查看qwen
b是否在运行中ollama show qwen3:32b --modelfile确认无内存限制增加Ollama内存分配OLLAMA_NUM_GPU1 OLLAMA_GPU_LAYERS40 ollama run qwen3:32b调大网关超时Nginx:proxy_read_timeout 300;ERR_CONNECTION_REFUSED浏览器Console或Clawdbot日志Clawdbot后端未启动或前端请求地址错误lsof -i :3000查3000端口占用grep -r GATEWAY_URL .env src/启动Clawdbot修正.env中GATEWAY_URLhttp://localhost:8080400 Bad Request浏览器Network → Response请求body格式错误如messages数组为空、model名拼错curl -v http://localhost:18789/api/chat -d {model:qwen3:32b,messages:[{role:user,content:test}]}检查Clawdbot源码中fetch调用的body结构确保messages非空、role为user/assistant、model精确匹配404 Not Found浏览器Network → Response请求URL路径错误网关未配置对应路由curl -v http://localhost:8080/api/chat网关层curl -v http://localhost:18789/api/chatOllama层检查网关配置是否将/api/chat路径正确代理至http://localhost:18789/api/chat实操提示遇到502/504不要立刻重装Ollama。
90%的情况是ollama ps显示模型进程存在但ollama list中状态为not loaded——此时只需执行ollama run qwen3:32b让其热加载一次即可恢复。
高频问题实战解决方案
1 问题输入后无响应等待1分钟后返回“Request timeout”现象前端输入文字发送后转圈1分钟无返回Network面板显示Pending后变红。
排查路径curl -v http://localhost:18789/api/chat→ 有响应 → 排除Ollama层tail -f /var/log/nginx/access.log→ 有POST /api/chat记录 → 排除Clawdbot转发失败tail -f /var/log/nginx/error.log→ 发现upstream timed out (110: Connection timed out)根因Qwen
B是32B大模型首次响应需加载权重Ollama默认超时仅30秒而网关Nginx默认proxy_read_timeout为60秒但Clawdbot前端设置的fetch timeout可能更短。
解决临时方案验证用# 在Ollama启动前设置更长超时单位秒 export OLLAMA_TIMEOUT300 ollama run qwen3:32b长期方案推荐修改Nginx网关配置/etc/nginx/conf.d/clawdbot.conflocation /api/chat { proxy_pass http://localhost:18789; proxy_read_timeout 300; # 关键从60改为300 proxy_connect_timeout 300; proxy_send_timeout 300; }保存后执行sudo nginx -s reload。
2 问题回答内容错乱如中文夹杂乱码、回复不完整、突然中断现象对话中出现符号、句子截断在半句、或返回{error:stream error}。
根因Qwen
B默认启用流式响应stream: true但Clawdbot前端未正确处理SSEServer-Sent Events数据流或网关未透传Content-Type: text/event-stream头。
验证# 关闭流式强制获取完整响应 curl -X POST http://localhost:18789/api/chat \ -H Content-Type: application/json \ -d {model:qwen3:32b,messages:[{role:user,content:你好}],stream:false}→ 若此命令返回完整JSON则确认是流式处理问题。
解决前端修复检查Clawdbot中调用/api/chat的代码确保请求body中显式设置stream: false开发调试阶段首选或若必须用stream需用EventSource或fetch().then(res res.body.getReader())正确解析SSE网关修复Nginx添加流式支持头location /api/chat { proxy_pass http://localhost:18789; proxy_buffering off; # 关键禁用缓冲 proxy_cache off; proxy_http_version
1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }
3 问题Clawdbot启动报错Error: listen EADDRINUSE :::3000现象终端报端口被占用无法启动。
根因3000端口正被其他进程可能是上次未退出的Clawdbot、VS Code调试、或其他Node服务占用。
解决# 查找占用3000端口的进程PID sudo lsof -i :3000 # 或macOS sudo lsof -iTCP:3000 -sTCP:LISTEN # 强制杀死替换PID为上一步查到的数字 sudo kill -9 PID # 验证释放 lsof -i :3000 # 应无输出
6.
总结建立你的排障 checklist面对ClawdbotQwen
B的异常别再从头翻文档。
用这张清单3分钟完成闭环诊断看浏览器Network面板记下错误码502/504/400和请求URL查Clawdbot终端日志确认请求是否抵达Forwarding to http://localhost:8080查网关日志确认是否有502/504记录或完全静默直连Ollamacurl http://localhost:18789/api/chat验证底层服务查模型状态ollama list看qwen3:32b是否为loadedollama ps看进程是否存在记住90%的问题集中在端口映射、模型加载状态、超时设置这三点。
每次修复后用一个最简请求如“你好”快速验证比反复重启整个栈高效十倍。
你不需要记住所有命令只需把这张表存为书签。
下次再遇到“发送后没反应”打开它按序号执行问题大概率在第3步就露出马脚。