Clawdbot-Qwen3:32B部署教程：8080端口代理至18789网关的完整步骤详解

Clawdbot-Qwen3:32B部署教程：8080端口代理至18789网关的完整步骤详解

1. 为什么需要这一步代理配置

你可能已经试过直接运行Qwen3:32B，也搭好了Clawdbot前端界面，但打开网页时却提示“连接失败”或“无法访问API”。这不是模型没跑起来，而是服务之间没打通——就像家里装好了高速宽带，但路由器没把信号分到各个房间。

Clawdbot本身不直接运行大模型，它是个智能对话平台，真正干活的是后端的Qwen3:32B。而Ollama启动的模型默认只监听本地127.0.0.1:11434，Clawdbot前端（运行在浏览器里）根本连不上这个地址；同时，Web网关通常有固定端口策略，比如只允许18789端口对外暴露。所以必须加一层“转接”，把Clawdbot发来的请求，从它习惯的8080端口，稳稳送到18789网关，再由网关转发给Ollama的模型服务。

这个过程不涉及模型微调、参数优化或性能压测，纯粹是让各组件能“听懂彼此说话”。整套流程跑通后，你就能在浏览器里像用ChatGPT一样和Qwen3:32B对话，所有推理都在你自己的机器上完成，数据不出内网，响应延迟可控，这才是私有化AI落地的第一块真实地砖。

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

在动手改配置前，请先确保以下三项服务已就绪且运行正常。少一个，后续代理就会卡在半路。

2.1 检查Ollama是否已加载Qwen3:32B

打开终端，执行：

ollama list

你应该看到类似这样的输出：

NAME ID SIZE MODIFIED qwen3:32b abcdef123456 19.2 GB 2 hours ago

如果没有，请先拉取模型：

ollama pull qwen3:32b

注意：Qwen3:32B体积较大（约19GB），请确保磁盘剩余空间大于25GB，并使用稳定网络。国内用户建议提前配置Ollama镜像源（如阿里云或清华源），避免拉取超时。

2.2 验证Ollama API是否可访问

Ollama默认启动后会监听http://127.0.0.1:11434。我们用curl快速验证：

curl http://127.0.0.1:11434/api/tags

如果返回包含qwen3:32b的JSON列表，说明模型服务已就绪。若提示Connection refused，请检查Ollama是否正在运行：

systemctl --user status ollama # Linux systemd用户 # 或 ps aux | grep ollama # 其他系统

如未运行，手动启动：

ollama serve &

2.3 确认Clawdbot前端已构建并监听8080端口

Clawdbot通常以静态文件方式部署，需确认其HTTP服务确实在8080端口提供页面。进入Clawdbot项目目录，执行：

netstat -tuln | grep :8080 # 或 lsof -i :8080

应看到类似node或python3进程占用该端口。如果没启动，根据Clawdbot文档启动服务，例如：

cd clawdbot-web npm install && npm run dev # 或使用Python简易服务器（仅测试用） python3 -m http.server 8080 --directory ./dist

此时在浏览器中访问http://localhost:8080，应能看到Clawdbot登录/聊天界面（即你提供的第二张图所示页面）。

3. 代理配置核心：8080 → 18789 → 11434 的三级跳

Clawdbot前端默认尝试向/api/chat发起POST请求，目标是http://localhost:8080/api/chat。但它实际需要的是Ollama的http://127.0.0.1:11434/api/chat。中间缺的不是一座桥，而是两段适配器：

• 第一段：Clawdbot前端发出的请求，要被8080端口的服务捕获并重写路径；
• 第二段：重写后的请求，要转发到18789网关；
• 第三段：18789网关再将请求代理至127.0.0.1:11434，并把Ollama响应原路送回。

整个链路如下：

浏览器 ←(HTTPS/HTTP)→ Clawdbot前端 (localhost:8080) ↓ Clawdbot前端 AJAX请求 → 本地反向代理 (如Nginx/Caddy) 监听 8080 ↓ 反向代理重写路径 + 转发 → Web网关 (localhost:18789) ↓ Web网关转发 → Ollama API (127.0.0.1:11434)

关键点在于：Clawdbot前端代码里不能硬写11434端口，否则跨域且不可部署；所有后端地址必须由代理层统一接管。

4. 实战配置：用Caddy实现8080端口代理至18789网关

我们推荐使用Caddy——它比Nginx配置更简洁，自动处理HTTPS，且对本地开发极其友好。以下为零依赖、开箱即用的配置方案。

4.1 安装Caddy（Linux/macOS）

# macOS brew install caddy # Ubuntu/Debian sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable-stable.list sudo apt update && sudo apt install caddy # Windows（PowerShell管理员运行） choco install caddy

验证安装：

caddy version

4.2 编写Caddyfile配置文件

在任意目录（如~/clawdbot-proxy）创建文件Caddyfile，内容如下：

:8080 { reverse_proxy http://127.0.0.1:18789 { header_up Host {host} header_up X-Forwarded-For {remote_host} header_up X-Forwarded-Proto {scheme} } }

这段配置的意思是：Caddy监听本机8080端口，所有进来的请求，不做任何修改，直接转发给127.0.0.1:18789。

为什么不是直接代理到11434？因为18789是你的Web网关端口，它可能还承担鉴权、日志、限流等职责。把代理逻辑分层，便于后期扩展（比如加JWT校验、请求审计）。

4.3 启动Caddy代理

在Caddyfile所在目录执行：

caddy run --config Caddyfile

你会看到类似输出：

INFO using adjacent Caddyfile INFO admin admin endpoint started {"address": "localhost:2019", "enforce_origin": false, "origins": ["localhost:2019"]} INFO tls.cache.maintenance started background certificate maintenance {"cache": "0xc0003a21e0"} INFO http.log.access.hashes no user info available, using random hash for privacy {"server_name": "srv0", "hash": "xxxxxx"} INFO http.log.access.common log common access to stdout INFO http.server.handles.rewrite rewrite {"request": {"method": "GET", "uri": "/", "proto": "HTTP/1.1", "remote_addr": "[::1]:50222", "host": "localhost:8080", "headers": {"User-Agent": ["curl/7.81.0"]}}}

此时，Caddy已在后台运行，8080端口已被它接管。

4.4 配置Web网关（18789端口）指向Ollama

现在轮到18789网关。如果你使用的是自研网关或Nginx，需添加如下反向代理规则：

# nginx.conf 或 site-enabled/clawdbot.conf 中添加 server { listen 18789; server_name localhost; location /api/chat { proxy_pass http://127.0.0.1:11434/api/chat; 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"; } location /api/tags { proxy_pass http://127.0.0.1:11434/api/tags; 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; } # 其他Ollama API路由可依此类推 }

保存后重启Nginx：

sudo nginx -t && sudo systemctl reload nginx

如果你用的是轻量级网关（如simple-gateway.py），只需确保它监听18789，并在收到/api/chat请求时，构造HTTP POST转发至http://127.0.0.1:11434/api/chat，并透传原始body和headers。

5. 前端适配与请求路径修正

Clawdbot前端代码中，API基础地址通常写在配置文件或环境变量里。你需要找到它，并改为相对路径或网关地址。

5.1 查找API配置位置

常见路径包括：

• src/config.js或src/utils/api.js
• .env文件中的VUE_APP_API_BASE_URL或REACT_APP_API_URL
• public/config.json（如果支持运行时配置）

打开对应文件，查找类似字段：

// 示例：旧配置（错误） const API_BASE = 'http://localhost:11434'; // 示例：新配置（正确） const API_BASE = '/api'; // 使用相对路径，由Caddy代理接管

强烈推荐使用相对路径/api。这样前端构建后，无论部署在http://example.com还是http://localhost:8080，请求都会自动拼接为/api/chat，再由Caddy转发至18789网关。

5.2 修改Clawdbot前端请求逻辑（可选）

如果前端强制拼接了端口号（如http://localhost:11434/api/chat），需全局搜索替换：

grep -r "11434" src/ --include="*.js" --include="*.ts" | head -10

将所有硬编码的11434替换为/api，并确保请求头中不携带Origin冲突字段（Caddy默认已处理跨域）。

5.3 构建并部署前端

完成修改后，重新构建前端：

cd clawdbot-web npm run build # 输出到 dist/ 目录

然后用Python简易服务器验证（无需Caddy）：

cd dist python3 -m http.server 8080

打开http://localhost:8080，输入问题，观察浏览器开发者工具（Network标签页）中/api/chat请求是否返回200及有效JSON响应。

6. 故障排查与高频问题解决

部署过程中90%的问题集中在网络链路和路径匹配。以下是真实踩坑总结：

6.1 请求返回502 Bad Gateway

• 原因：Caddy能连上18789，但18789网关连不上11434。
• 检查步骤：
  1. 在服务器上执行curl -v http://127.0.0.1:18789/api/tags，看是否返回Ollama模型列表；
  2. 若失败，再执行curl -v http://127.0.0.1:11434/api/tags，确认Ollama是否真在运行；
  3. 检查18789网关日志，看是否有Connection refused报错。

6.2 请求返回404 Not Found

• 原因：路径未正确重写。Clawdbot发的是/api/chat，但网关只配置了/chat。
• 解决方法：
  • 确保网关配置中location块精确匹配/api/chat（注意开头斜杠）；
  • 或在Caddy中增加重写规则：

:8080 { handle_path /api/* { uri strip_prefix /api reverse_proxy http://127.0.0.1:18789 } }

6.3 浏览器控制台报CORS错误

• 原因：前端请求头带Origin: http://localhost:8080，而网关未返回Access-Control-Allow-Origin。
• 解决方法：
  • 在18789网关配置中显式添加CORS头（Nginx示例）：

add_header 'Access-Control-Allow-Origin' '*' always; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always; add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;

• 或更安全地，只允许可信来源：

add_header 'Access-Control-Allow-Origin' 'http://localhost:8080' always;

6.4 模型响应缓慢或中断

• 原因：Qwen3:32B显存占用高，Ollama默认未启用GPU加速，或LLM推理流式响应未正确透传。
• 临时缓解：
  • 启动Ollama时指定GPU（如NVIDIA）：

OLLAMA_NUM_GPU=1 ollama serve

• 确保Caddy和网关未缓冲响应体，添加proxy_buffering off;（Nginx）或使用Caddy的flush_interval -1。

7. 验证与效果确认

全部配置完成后，按顺序执行以下三步验证：

7.1 本地服务连通性测试

# 1. 测试Caddy是否转发成功 curl -X POST http://localhost:8080/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32b", "messages": [{"role": "user", "content": "你好"}] }' # 2. 应返回Ollama标准流式JSON（含"message"字段），无HTML或404

7.2 浏览器端到端测试

1. 启动Caddy（caddy run --config Caddyfile）；
2. 启动Clawdbot前端（python3 -m http.server 8080 --directory ./dist）；
3. 访问http://localhost:8080；
4. 在聊天框输入“你好”，点击发送；
5. 观察右下角是否出现Qwen3:32B的实时回复（如你提供的第一张图所示界面）。

7.3 日志交叉验证

同时打开三个终端窗口，分别监控：

• 终端1：caddy run --config Caddyfile --adapter caddyfile --pretty（查看Caddy转发日志）；
• 终端2：journalctl -u nginx -f或网关日志文件（查看18789接收与转发）；
• 终端3：ollama serve控制台（查看模型推理日志）。

当一次提问触发三端均有日志输出，且无ERROR，即表示全链路贯通。

8. 总结：一条清晰、可控、可复现的私有AI链路

到这里，你已经亲手搭建了一条从浏览器界面，经由8080代理、18789网关，最终抵达Qwen3:32B模型的完整通路。它不依赖云服务，不上传数据，所有计算发生在本地；它结构清晰，每一层职责单一——Clawdbot管交互，Caddy管网关接入，18789管网关逻辑，Ollama管模型推理。

这条链路的价值，不在于多酷炫，而在于可预期、可调试、可交付。你可以把它打包成Docker Compose一键部署，可以加Prometheus监控各环节延迟，也可以把18789网关换成Kong做企业级API治理。而今天这一步，就是所有可能性的起点。

下一步，你可以尝试：

• 把Caddy配置写入systemd服务，实现开机自启；
• 为18789网关添加JWT认证，限制未授权访问；
• 在Clawdbot前端增加模型切换下拉框，动态选择qwen3:32b或其它Ollama模型。

技术落地，从来不是一步登天，而是把每一个“为什么连不上”变成“原来这里少了一个header”，把每一个报错变成一次确定性的修复。你现在，已经做到了。

获取更多AI镜像

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