Clawdbot+Qwen3:32B部署教程：解决Ollama API跨域与网关鉴权问题

1. 为什么需要这个配置：从“连不上”到“稳运行”的真实痛点

你是不是也遇到过这样的情况：本地跑通了Qwen3:32B，Ollama命令行调用一切正常，可一旦把Clawdbot前端页面接入，浏览器控制台立刻报错——CORS error、Failed to fetch、Network Error轮番轰炸？刷新几次后又突然提示401 Unauthorized或502 Bad Gateway？别急，这不是模型的问题，也不是代码写错了，而是典型的API网关层配置断点。

Clawdbot作为轻量级Chat平台前端，设计初衷是直连后端推理服务；而Qwen3:32B这类大参数量模型，通常需通过Ollama托管在本地或内网服务器上。两者之间看似只差一个HTTP请求，实则横跨三道关卡：浏览器同源策略（CORS）→ 反向代理路由规则 → 网关层身份校验（Auth）。缺一不可，错一即瘫。

本教程不讲抽象原理，只聚焦一件事：让你的Clawdbot页面，干净利落地调通私有部署的Qwen3:32B，且全程无跨域警告、无鉴权拦截、无端口冲突。所有操作均基于Linux环境（Ubuntu 22.04 / CentOS 8），无需修改Ollama源码，不依赖Docker Compose编排，纯配置驱动，15分钟内可完成验证。

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

2.1 前置条件检查清单

请在执行前确认以下五项均已就绪。任一缺失都将导致后续步骤失败：

  • Ollama已安装并运行：终端执行 ollama list 应返回模型列表，ollama serve 进程处于活跃状态（默认监听 127.0.0.1:11434）
  • Qwen3:32B模型已拉取：执行 ollama pull qwen3:32b，完成后 ollama list 中应显示 qwen3 + 32b 标签
  • Clawdbot前端资源已构建完成：静态文件位于 ./clawdbot/dist/ 目录下，含 index.html、main.js 等核心文件
  • 系统具备基础工具链：curl、jq、nginx（或 caddy）、systemctl 均可用
  • 非root用户具备sudo权限：用于配置系统级服务与端口绑定

注意：本方案不使用Ollama内置Web UI，也不启用其--host参数暴露公网接口。所有通信严格限定于内网环回（localhost），安全边界清晰。

2.2 验证Ollama API是否就绪

在终端中执行以下命令，确认基础API通路：

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 '.message.content'

若返回 "你好！很高兴见到你。" 或类似响应，说明Ollama服务健康，模型加载成功。若超时或报404，请先检查 ollama serve 是否后台运行，或尝试 ollama ps 查看模型状态。

3. 核心问题拆解：跨域与鉴权到底卡在哪？

Clawdbot前端本质是一个单页应用（SPA），所有请求由浏览器JavaScript发起。当它试图直接访问 http://localhost:11434/api/chat 时，会触发两个硬性限制：

3.1 浏览器同源策略（CORS）拦截

  • Clawdbot页面通常托管在 http://localhost:8080（开发模式）或 https://chat.yourdomain.com（生产模式）
  • Ollama默认API仅响应 127.0.0.1:11434 的请求，不返回 Access-Control-Allow-Origin 头
  • 浏览器判定为跨域请求，直接阻断，控制台显示 Blocked by CORS policy

3.2 网关层鉴权拦截（常见于企业级部署）

  • 很多团队会在Ollama前加一层Nginx/Caddy网关，统一处理SSL、限流、日志
  • 若网关启用了Basic Auth、JWT校验或IP白名单，而Clawdbot请求未携带对应Header或凭证，将被直接返回 401 或 403
  • 此类错误常被误判为“模型没启动”，实则是网关在说：“你没带门禁卡，不能进”

3.3 端口映射混乱导致连接失败

  • 教程截图中提到“8080端口转发到18789网关”——这恰恰是典型误区
  • 若Clawdbot前端配置请求地址为 http://localhost:8080/api/chat，而Nginx实际监听 :18789 并反向代理至 127.0.0.1:11434，但未正确配置proxy_pass或location路径，则请求根本无法抵达Ollama

正确思路：让网关成为“透明通道”，而非“新关卡”。即：Clawdbot发往网关的请求，网关不做鉴权、不改头、不拦截，原样透传给Ollama，并补全必需的CORS头。

4. 三步落地：Nginx网关配置实战（推荐方案）

我们采用Nginx作为轻量反向代理，因其配置直观、社区支持广、资源占用低。以下配置经实测兼容Qwen3:32B高并发流式响应。

4.1 创建专用Nginx配置文件

新建 /etc/nginx/conf.d/clawdbot-qwen3.conf：

upstream ollama_backend {
    server 127.0.0.1:11434;
    keepalive 32;
}

server {
    listen 18789;
    server_name localhost;

    # 允许所有来源（开发环境）或指定前端域名（生产环境）
    set $cors_origin "*";
    # 生产环境请替换为：set $cors_origin "https://chat.yourdomain.com";

    location /api/ {
        proxy_pass http://ollama_backend/;
        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;

        # 关键：透传Ollama的流式响应
        proxy_buffering off;
        proxy_cache off;
        proxy_redirect off;

        # 关键：注入CORS头，解决浏览器拦截
        add_header 'Access-Control-Allow-Origin' $cors_origin;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
        add_header 'Access-Control-Allow-Credentials' 'true';

        # 处理预检请求（OPTIONS）
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' $cors_origin;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE';
            add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }

    # 静态资源兜底（如Clawdbot前端托管于此）
    location / {
        root /var/www/clawdbot;
        try_files $uri $uri/ /index.html;
    }
}

4.2 启动并验证Nginx网关

执行以下命令：

# 测试配置语法
sudo nginx -t

# 重载配置（不中断服务）
sudo systemctl reload nginx

# 检查18789端口是否监听
sudo ss -tuln | grep ':18789'

若输出包含 LISTEN 0 511 *:18789 *:*，说明网关已就绪。

4.3 手动测试网关通路

绕过前端，直接用curl模拟Clawdbot请求：

# 发送带CORS头的请求（模拟浏览器）
curl -X POST http://localhost:18789/api/chat \
  -H "Origin: http://localhost:8080" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:32b",
    "messages": [{"role": "user", "content": "用一句话解释量子纠缠"}],
    "stream": false
  }' -i | head -n 20

成功标志：

  • 响应头中包含 Access-Control-Allow-Origin: *
  • HTTP状态码为 200 OK
  • 响应体中 message.content 字段返回合理文本

若失败，请重点检查：

  • Nginx配置中 proxy_pass 末尾的 / 是否遗漏（必须有，否则路径拼接错误）
  • upstream 地址是否与 ollama serve 实际监听地址一致
  • 防火墙是否放行 18789 端口（sudo ufw allow 18789）

5. Clawdbot前端配置与页面集成

Clawdbot本身不内置后端，其config.js或构建时环境变量决定API地址。根据你的部署方式选择：

5.1 开发模式（Vite/HMR）配置

修改 clawdbot/src/config.js：

export const API_BASE_URL = 'http://localhost:18789'; // 指向你的Nginx网关
export const MODEL_NAME = 'qwen3:32b';

然后运行 npm run dev，打开 http://localhost:8080 即可直连。

5.2 生产构建模式配置

若使用 vite build 构建静态包，需在构建前设置环境变量：

# 构建时注入API地址
VITE_API_BASE_URL="http://localhost:18789" npm run build

构建产物放入Nginx配置中的 /var/www/clawdbot 目录，重启Nginx即可。

5.3 页面效果验证要点

打开浏览器开发者工具（F12），切换到Network标签页，执行一次对话：

  • 查看 api/chat 请求：
    • Status: 200 OK（非0或502）
    • Headers → Response Headers: 包含 Access-Control-Allow-Origin
    • Preview/Response: 返回JSON结构完整，含message.content
  • 查看Console：无红色CORS或fetch错误
  • 观察聊天窗口：消息逐字流式渲染（Qwen3:32B支持stream:true，体验更自然）

小技巧：若想在生产环境隐藏网关端口，可将Nginx监听443并配置SSL，Clawdbot前端URL改为 https://yourdomain.com/api/chat，网关配置中server_name同步更新，实现“零感知”集成。

6. 常见问题排查与加固建议

6.1 典型报错速查表

现象 可能原因 快速验证命令 解决方案
net::ERR_CONNECTION_REFUSED Nginx未运行或端口未监听 curl -I http://localhost:18789 sudo systemctl start nginx
CORS error Nginx未返回CORS头 curl -I -H "Origin: http://test.com" http://localhost:18789/api/chat 检查add_header配置及if (OPTIONS)块
401 Unauthorized 网关层误配了Auth curl -v http://localhost:18789/api/tags 删除Nginx中所有auth_basic、auth_request指令
502 Bad Gateway proxy_pass地址错误或Ollama宕机 curl http://127.0.0.1:11434/api/tags 确认Ollama进程存活，proxy_pass指向正确

6.2 安全加固建议（生产必做）

  • 限制CORS来源：将配置中 set $cors_origin "*"; 替换为具体域名，如 set $cors_origin "https://chat.yourcompany.com";
  • 启用HTTPS：为Nginx配置Let's Encrypt证书，避免敏感对话明文传输
  • Ollama绑定内网地址：启动时指定 OLLAMA_HOST=127.0.0.1:11434，确保不监听0.0.0.0
  • Nginx访问日志脱敏：在log_format中过滤Authorization、api_key等敏感Header字段

6.3 性能优化提示

  • Qwen3:32B单次推理显存占用约24GB（A100），若并发>3请增加upstream keepalive值并调高Nginx worker_connections
  • 流式响应（stream:true）下，Nginx需保持长连接，务必保留 proxy_buffering off;
  • 首次加载模型较慢（约30秒），可在Clawdbot页面添加“模型加载中”提示，提升用户体验

7. 总结：一条清晰、安全、可持续的集成路径

回顾整个流程，我们并未对Ollama或Qwen3:32B做任何侵入式修改，也没有要求Clawdbot重构网络层。真正的关键在于：用Nginx这层薄薄的代理，精准地补上了浏览器、网关、模型三者之间的协议断层。

  • 跨域问题，靠add_header和OPTIONS预检响应解决；
  • 鉴权问题，靠“不设防”的透传策略规避；
  • 端口混乱问题，靠明确的listen与proxy_pass绑定理清流向。

你现在拥有的是一套可复用的模式：无论后续接入Qwen2.5、GLM-4还是自研模型，只需调整upstream地址和MODEL_NAME，其余配置零改动。这才是工程化部署该有的样子——稳定、透明、易维护。

下一步，你可以尝试：

  • 将Clawdbot与企业微信/钉钉机器人打通，实现内部AI助手
  • 在Nginx层添加limit_req模块，防止恶意刷请求
  • 用prometheus+nginx-vts-exporter监控API成功率与延迟

技术的价值，从来不在炫技，而在让复杂变得可靠，让不可控变得可预期。

获取更多AI镜像

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

Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

OpenClaw安全配置解决方案 - 开源AI助手安全部署指南

avatar 龙虾开发者社区

openclaw配置多个agent实现飞书群聊

本文介绍了基于飞书的多Agent系统架构设计，通过OpenClaw Gateway实现飞书应用与AI Agent的对接。系统采用多Agent架构，每个飞书机器人对应独立的AI Agent，拥有专属的工作空间、知识库和模型配置。

avatar 龙虾开发者社区
cover

ClawHub 小红书 Skills 完整盘点：136 个技能分类梳理

avatar 龙虾开发者社区