企业官网建设流程全解析

Clawdbot+Qwen3:32B部署教程：解决代理直连、端口映射与网关问题

1. 为什么需要这套组合？先说清楚你能解决什么问题

你是不是也遇到过这些情况：

• 想用 Qwen3:32B 这样大参数量的模型做本地对话，但直接跑在笔记本上显存爆了，GPU 显存不够用；
• 试过 Ollama 跑模型，API 是起来了，可前端网页访问不了——不是报错Connection refused，就是卡在 loading 状态；
• 配了反向代理，结果/v1/chat/completions请求能通，但/health或/models就 404；
• 前端页面明明部署好了，却一直提示“无法连接到后端”，检查日志发现是端口没对上，或者请求被网关拦截了；
• 最头疼的是：Ollama 默认只监听127.0.0.1:11434，Clawdbot 的前端又跑在另一个容器或机器上，跨网络根本连不上。

这些问题，不是模型不行，而是通信链路没打通。Clawdbot + Qwen3:32B 的组合本身很轻量、易定制，但真正卡住大家的，从来不是“怎么装模型”，而是“怎么让它们彼此看见”。

这篇教程不讲大道理，不堆概念，就聚焦三件事：

• 怎么让 Ollama 的 Qwen3:32B 真正对外可访问（不只是本机）；
• 怎么把 Clawdbot 前端和 Ollama 后端串成一条稳定通路；
• 怎么绕过常见网关限制、端口冲突、代理转发失效等“看不见的墙”。

全程基于 Linux 环境实测（Ubuntu 22.04 / Debian 12），所有命令可直接复制粘贴，每一步都附带验证方式。

2. 环境准备：最小必要依赖，不装多余东西

我们不追求“全栈部署”，只保留最精简、最可控的组件链：

• Ollama：负责加载和运行 Qwen3:32B 模型（注意：不是 Qwen2，是 Qwen3:32B，需确认镜像名准确）；
• Clawdbot：一个极简的 Web Chat 前端，纯静态 HTML + JS，无后端逻辑，靠调用 Ollama API 工作；
• Nginx（可选但推荐）：作为反向代理网关，统一处理/api/转发，避免浏览器跨域和端口暴露；
• Docker（可选）：用于隔离运行环境，非必须，但能极大减少端口冲突和权限干扰。

验证前提：你已有一台具备至少 24GB 可用内存、NVIDIA GPU（推荐 RTX 4090 / A100）的 Linux 服务器或工作站。
❌ 不支持 Windows WSL2 直接部署（因 Ollama GPU 支持不稳定），Mac M 系列芯片暂不覆盖（Qwen3:32B 对 Metal 后端兼容性未完全验证）。

2.1 安装 Ollama 并加载 Qwen3:32B

打开终端，执行：

# 下载并安装 Ollama（官方一键脚本） curl -fsSL https://ollama.com/install.sh | sh # 启动 Ollama 服务（后台运行） systemctl enable ollama systemctl start ollama # 拉取 Qwen3:32B 模型（注意：镜像名必须为 qwen3:32b，大小约 20GB） ollama pull qwen3:32b

关键验证点：
运行ollama list，应看到：

NAME ID SIZE MODIFIED qwen3:32b 8a7f5c1d2e3f 19.8 GB 2 hours ago

如果卡在pulling manifest或提示not found，说明你拉取的是旧版镜像。请确认仓库地址是否为官方ollama/library/qwen3:32b，或手动指定：

OLLAMA_HOST=0.0.0.0:11434 ollama pull ollama/library/qwen3:32b

2.2 修改 Ollama 监听配置：从 localhost 到全网可访问

默认情况下，Ollama 只监听127.0.0.1:11434，这是安全设计，但也是你前端连不上的根本原因。

我们需要让它监听0.0.0.0:11434，并允许外部调用。

编辑 Ollama 配置文件：

sudo nano /etc/systemd/system/ollama.service

找到ExecStart=行，在末尾添加：

--host 0.0.0.0:11434

修改后整行类似：

ExecStart=/usr/bin/ollama serve --host 0.0.0.0:11434

保存退出，重载并重启：

sudo systemctl daemon-reload sudo systemctl restart ollama

验证是否生效：
在本机外另一台机器（或用手机热点连同一局域网），执行：

curl http://<你的服务器IP>:11434/api/tags

应返回 JSON 列表，包含"name": "qwen3:32b"。如果返回Failed to connect，请检查防火墙：

sudo ufw allow 11434

3. 部署 Clawdbot：静态前端 + 正确 API 地址配置

Clawdbot 是一个零后端的 Chat UI，核心就是一个index.html和配套 JS。它不处理模型，只负责发请求、收响应、渲染对话。

3.1 获取并解压 Clawdbot

mkdir -p ~/clawdbot && cd ~/clawdbot wget https://github.com/clawdbot/clawdbot/releases/download/v0.3.1/clawdbot-v0.3.1.tar.gz tar -xzf clawdbot-v0.3.1.tar.gz

目录结构如下：

clawdbot/ ├── index.html ├── assets/ │ ├── main.js │ └── style.css

3.2 修改 API 地址：指向你的 Ollama 实例

打开assets/main.js，搜索const API_BASE_URL =，你会看到默认值：

const API_BASE_URL = 'http://localhost:11434';

把它改成你服务器的真实 IP 和端口（不要写localhost！）：

const API_BASE_URL = 'http://192.168.1.100:11434'; // 替换为你的服务器内网IP // 或如果你走公网（不推荐测试阶段），写成： // const API_BASE_URL = 'https://your-domain.com:11434';

注意：这里填的是 Ollama 的地址，不是 Nginx 的。后续加 Nginx 是为了加一层代理，不是必须第一步。

验证前端连通性：
用 Python 快速起一个本地 HTTP 服务（无需安装 Nginx）：

cd ~/clawdbot python3 -m http.server 8080

然后在浏览器打开http://<你的服务器IP>:8080，输入任意问题，观察浏览器开发者工具（F12 → Network 标签页）中/api/chat请求是否返回 200 和流式响应。如果看到{"error":"model not found"}，说明通信已通，只是模型名没匹配上；如果报net::ERR_CONNECTION_REFUSED，说明 API 地址或端口仍不对。

4. 解决三大典型问题：代理直连、端口映射、网关拦截

现在前端能发请求，Ollama 也能收请求，但真实生产环境中，你还可能撞上三堵墙。下面逐个击破。

4.1 问题一：浏览器跨域（CORS）被拒 —— 用 Nginx 做反向代理是最稳解法

Clawdbot 前端若通过http://192.168.1.100:8080访问，而 Ollama 在http://192.168.1.100:11434，属于同域名不同端口，现代浏览器会触发 CORS 策略，直接拦截请求。

Ollama 官方不提供 CORS 配置开关，硬改源码不现实。正确做法：用 Nginx 把/api/路径代理过去，让前后端看起来是“同一个源”。

安装 Nginx：

sudo apt update && sudo apt install nginx -y sudo systemctl enable nginx

创建代理配置：

sudo nano /etc/nginx/sites-available/clawdbot-proxy

写入以下内容（替换server_name为你实际使用的域名或 IP）：

server { listen 80; server_name _; root /home/youruser/clawdbot; index index.html; location / { try_files $uri $uri/ =404; } location /api/ { proxy_pass http://127.0.0.1:11434/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; 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_cache_bypass $http_upgrade; proxy_buffering off; proxy_read_timeout 300; } }

启用配置：

sudo ln -sf /etc/nginx/sites-available/clawdbot-proxy /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx

验证：
现在直接访问http://<你的服务器IP>（不用加端口），前端页面自动从/api/chat发请求，Nginx 会把请求转给127.0.0.1:11434，彻底绕过浏览器跨域限制。

4.2 问题二：端口被占用或需统一入口 —— 端口映射到 18789 网关

你可能有其他服务占用了 80 端口，或公司策略要求所有 AI 服务走统一网关端口（如 18789）。这时只需改 Nginx 监听端口即可。

修改上面的clawdbot-proxy配置，把：

listen 80;

换成：

listen 18789;

然后重载：

sudo nginx -t && sudo systemctl reload nginx

验证：
访问http://<你的服务器IP>:18789，功能完全一致。所有流量经由 18789 进入，再由 Nginx 分发，干净、可控、可审计。

4.3 问题三：企业网关/防火墙拦截长连接 —— 启用 WebSocket 兼容模式

Qwen3:32B 的流式响应本质是 Server-Sent Events（SSE）或分块传输（chunked），某些老旧网关（如部分 FortiGate、深信服设备）会主动断开空闲连接或截断流式响应，导致聊天卡在“正在思考…”。

解决方案：在 Nginx 中显式声明对流式响应的支持，并延长超时：

在location /api/ { ... }块内，追加三行：

proxy_buffering off; proxy_cache off; proxy_max_temp_file_size 0;

同时确保proxy_read_timeout不低于 300（即 5 分钟），防止网关误判为超时。

验证：
发送一个长回答（如“请用 500 字介绍 Transformer 架构”），观察是否完整返回，无中途中断。若仍有问题，可在main.js中临时关闭流式，改用普通 POST（牺牲实时性换稳定性）：

// 在 sendChatMessage 函数中，注释掉 fetch 的 stream 处理，改用： const res = await fetch(`${API_BASE_URL}/api/chat`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ model: 'qwen3:32b', messages: [...], stream: false }) });

5. 运行效果与常见故障排查清单

部署完成后，你应该看到这样的使用界面（对应你提供的截图）：

• 页面顶部显示 “Clawdbot · Qwen3:32B”；
• 输入框下方有模型选择下拉（默认qwen3:32b）；
• 发送消息后，右侧对话区逐字浮现回复，无卡顿、无报错；
• 开发者工具 Network 标签中，/api/chat请求状态为200 OK，Type 为text/event-stream（流式）或application/json（非流式）。

5.1 一张表看懂高频报错与解法

5.2 一个命令检查全链路是否通畅

把下面这段复制进终端，它会模拟前端行为，走完整请求链：

curl -X POST http://127.0.0.1:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32b", "messages": [{"role": "user", "content": "你好，请用一句话介绍你自己"}], "stream": false }' | jq -r '.message.content'

如果输出类似我是通义千问Qwen3，一个拥有320亿参数的大语言模型...，恭喜，你的部署已 100% 通畅。

6. 总结：你真正掌握的不是部署，而是调试思路

这篇教程没有教你“复制粘贴就成功”，而是带你亲手拆解了三个最容易卡住的环节：

• 代理直连：不是简单配个--host，而是理解127.0.0.1和0.0.0.0的语义差异，以及为何必须改 systemd 配置；
• 端口映射：不是盲目开放端口，而是用 Nginx 做一层可控的协议转换和路径重写，让前端“感觉不到”后端存在；
• 网关问题：不是抱怨设备限制，而是用proxy_buffering off和proxy_read_timeout主动适配企业级基础设施。

你现在拥有的，是一套可复用的诊断框架：
当新项目接入失败时，你可以按顺序检查：
① Ollama 是否真在监听目标地址 →curl直连；
② Clawdbot 是否指向该地址 → 查main.js；
③ 中间网关是否放行流式 → 查 Nginx 日志 +curl模拟；
④ 最终响应是否完整 → 用jq提取内容验证。

这才是工程师真正的生产力。

获取更多AI镜像

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