Clawdbot+Qwen3-32B：18789端口转发配置全流程

1. 为什么需要18789端口转发？——从模型服务到可用Chat平台的最后一步

你是否遇到过这样的情况：Qwen3-32B模型已在本地用Ollama成功加载，ollama run qwen3:32b能正常响应；Clawdbot也已启动，界面打开顺畅；但输入问题后，页面始终显示“连接中…”或直接报错“Failed to fetch”？

这不是模型能力问题，也不是前端界面故障——而是服务链路未打通。Ollama默认监听127.0.0.1:11434，这是一个仅限本机访问的回环地址；而Clawdbot作为独立Web应用，运行在容器或另一进程里，它无法直连localhost:11434（尤其当两者处于不同网络命名空间时）。更关键的是，Clawdbot前端通过浏览器发起请求，而现代浏览器出于安全策略，会阻止跨域请求直接访问11434这类非标准HTTP端口。

这就是18789端口转发的核心价值：它不是简单的“换一个数字”，而是一条可信、可控、可调试的代理通道。它把Ollama的私有API接口，安全地暴露给Clawdbot网关，并统一收敛至一个符合Web规范的端口（18789），让前后端通信回归标准HTTP流程。整个过程不修改Ollama源码、不侵入Clawdbot逻辑、不依赖外部云服务，完全在本地闭环完成。

本文将带你从零开始，完整走通这条链路：
确认Ollama Qwen3-32B服务就绪状态
配置轻量级反向代理（Nginx / Caddy / socat三选一）
将http://localhost:18789/v1/chat/completions精准映射到http://host.docker.internal:11434/api/chat
验证Clawdbot前端调用无跨域、无超时、响应稳定
排查常见失败点（Docker网络、权限、路径重写）

全程无需编译、不装复杂中间件，所有命令可复制即用。

2. 前置检查：确认Qwen3-32B与Ollama服务已就绪

在配置转发前，必须确保底层模型服务健康运行。这一步常被跳过，却是后续90%失败的根源。

2.1 检查Ollama是否正在运行并加载Qwen3-32B

打开终端，执行：

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

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

# 确认Qwen3-32B模型已拉取并可用
ollama list

预期输出中应包含：

qwen3:32b    latest    12.4GB    2025-04-10 15:22

若未出现，请先拉取模型：

ollama pull qwen3:32b

注意：qwen3:32b是Ollama模型标签名，非HuggingFace原始ID。该镜像已由社区优化，支持GQA注意力与YaRN长上下文，显存占用比原生FP16降低约60%。

2.2 验证Ollama API可被本地访问

Ollama默认绑定127.0.0.1:11434。我们用curl模拟Clawdbot的请求格式进行测试：

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

成功响应特征：返回JSON，含"message": {"role": "assistant", "content": "..."} 失败典型表现：

  • curl: (7) Failed to connect to localhost port 11434: Connection refused → Ollama未启动
  • {"error":"model not found"} → 模型名拼写错误或未拉取
  • {"error":"context deadline exceeded"} → GPU显存不足（Qwen3-32B INT4需≥22GB空闲显存）

2.3 关键认知：Docker环境下的网络隔离

如果你使用Docker运行Clawdbot（绝大多数生产部署场景），必须理解这个事实：
Docker容器内的localhost ≠ 宿主机的localhost。容器默认处于独立网络命名空间，127.0.0.1指向容器自身，而非宿主机。

因此，在Clawdbot容器内直接请求http://localhost:11434必然失败。解决方案有两个：

  • 推荐：通过host.docker.internal（Docker Desktop）或172.17.0.1（Linux Docker）访问宿主机Ollama
  • 更优：配置反向代理，让Clawdbot只认http://clawdbot-gateway:18789，代理层负责解决网络寻址

我们将采用后者，因其更健壮、可复用、符合微服务设计原则。

3. 三种端口转发方案实操：Nginx / Caddy / socat（任选其一）

我们提供三种技术路径，覆盖不同技术栈偏好。它们目标一致：将18789端口的HTTP请求，无损转发至Ollama的11434接口，并正确处理路径、头信息与流式响应。

3.1 方案一：Nginx（最稳定，适合生产环境）

Nginx是工业级反向代理，对长连接、流式响应（SSE）支持完善，且配置一次长期有效。

步骤1：创建Nginx配置文件 clawdbot-qwen.conf

upstream ollama_backend {
    # Linux宿主机：使用docker0网关IP
    server 172.17.0.1:11434;
    # macOS/Windows Docker Desktop：使用特殊域名
    # server host.docker.internal:11434;
}

server {
    listen 18789;
    server_name localhost;

    location /v1/chat/completions {
        proxy_pass http://ollama_backend/api/chat;
        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 chat API返回chunked JSON）
        proxy_buffering off;
        proxy_cache off;
        proxy_send_timeout 300;
        proxy_read_timeout 300;
    }

    # 兜底：其他路径返回404，避免误暴露Ollama管理接口
    location / {
        return 404;
    }
}

步骤2：启动Nginx（Docker方式，免安装）

# 拉取官方Nginx镜像
docker pull nginx:alpine

# 运行代理容器，挂载配置文件
docker run -d \
  --name clawdbot-proxy \
  -p 18789:18789 \
  -v $(pwd)/clawdbot-qwen.conf:/etc/nginx/conf.d/default.conf:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --restart=always \
  nginx:alpine

验证：curl http://localhost:18789/v1/chat/completions -X POST ... 应返回与直接调Ollama相同结果。

3.2 方案二：Caddy（最简洁，适合快速验证）

Caddy内置HTTPS和自动配置，语法极简，适合开发者快速试错。

步骤1：创建Caddyfile

:18789 {
    reverse_proxy http://host.docker.internal:11434 {
        # 路径重写：/v1/chat/completions → /api/chat
        @ollama_api path /v1/chat/completions
        handle @ollama_api {
            uri replace "/v1/chat/completions" "/api/chat"
            reverse_proxy http://host.docker.internal:11434
        }
        # 流式响应支持
        transport http {
            read_timeout 300s
            write_timeout 300s
        }
    }
}

步骤2：一键启动（需提前安装Caddy）

# macOS
brew install caddy
caddy run --config ./Caddyfile

# Linux（一键脚本）
curl https://getcaddy.com | bash -s personal
sudo setcap cap_net_bind_service=+ep /usr/local/bin/caddy
caddy run --config ./Caddyfile

提示：Caddy会自动处理host.docker.internal解析，无需额外配置。

3.3 方案三：socat（最轻量，适合资源受限环境）

当服务器无法安装Nginx/Caddy时，socat是终极备选——它只有单二进制文件，内存占用<1MB。

步骤：启动端口转发（后台运行）

# 安装socat（Ubuntu/Debian）
sudo apt-get install socat

# 启动18789→11434转发（支持HTTP头透传）
nohup socat TCP4-LISTEN:18789,fork,reuseaddr TCP4:127.0.0.1:11434 &

# 验证进程
ps aux | grep socat

注意：socat不处理路径重写，因此Clawdbot需配置为直接请求/api/chat（修改其前端代码或环境变量）。此方案仅推荐临时调试。

4. Clawdbot端配置：指向18789网关并启用流式响应

Clawdbot需明确知道“AI大脑”现在位于http://localhost:18789，而非默认的Ollama地址。配置位置取决于部署方式。

4.1 Docker Compose部署（推荐）

编辑你的docker-compose.yml，在Clawdbot服务下添加环境变量：

services:
  clawdbot:
    image: your-clawdbot-image
    ports:
      - "8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:18789  # 关键！指向代理
      - OLLAMA_MODEL=qwen3:32b
      - STREAMING_ENABLED=true  # 必须开启，否则无法显示打字效果
    # 若使用自定义网络，确保与代理容器同网段
    networks:
      - clawdbot-net

然后重启服务：

docker-compose down && docker-compose up -d

4.2 直接运行（Node.js环境）

若Clawdbot以Node.js进程运行，设置环境变量后启动：

OLLAMA_BASE_URL=http://localhost:18789 \
OLLAMA_MODEL=qwen3:32b \
STREAMING_ENABLED=true \
npm start

4.3 前端硬编码（不推荐，仅应急）

打开Clawdbot项目中的API调用文件（如src/utils/api.js），找到Ollama请求URL，改为：

// 修改前（可能指向11434）
const API_BASE = 'http://localhost:11434';

// 修改后（指向18789代理）
const API_BASE = 'http://localhost:18789';

核心要点：Clawdbot发送的请求路径必须是/v1/chat/completions（OpenAI兼容格式），而代理层负责将其转为Ollama所需的/api/chat。这是OpenAI生态适配的关键抽象。

5. 全链路验证与高频问题排查

配置完成后，务必执行端到端验证。以下检查清单覆盖95%线上问题。

5.1 四步黄金验证法

步骤 操作 预期结果 说明
① 代理层 curl -v http://localhost:18789/health HTTP 200 OK 证明Nginx/Caddy/socat已监听18789
② 转发层 curl -v http://localhost:18789/v1/chat/completions -X POST ... 返回JSON响应 证明路径重写与转发成功
③ 容器网络 进入Clawdbot容器：docker exec -it clawdbot sh，执行ping host.docker.internal 通 确认容器能访问宿主机
④ 最终效果 打开http://localhost:8080，输入问题 实时流式回复 用户可见的最终结果

5.2 高频问题速查表

现象 可能原因 解决方案
Clawdbot报错“Network Error” 代理未运行，或端口被占用 lsof -i :18789 查进程，kill后重试
返回404 Not Found Nginx/Caddy路径规则未匹配 /v1/chat/completions 检查配置中location是否精确匹配，注意末尾斜杠
响应卡住，无内容 代理未关闭buffering，Ollama流式响应被缓存 Nginx加proxy_buffering off;，Caddy加transport http { ... }
中文乱码或emoji异常 缺少字符集声明 Nginx加charset utf-8;，Caddy加header Content-Type "application/json; charset=utf-8"
Docker内无法解析host.docker.internal Linux Docker未启用该特性 改用172.17.0.1，或启动容器时加--add-host=host.docker.internal:host-gateway

5.3 性能与稳定性加固建议

  • 超时设置：Qwen3-32B生成首token较慢（尤其首次加载），建议代理层proxy_read_timeout设为300秒
  • 并发限制：单卡RTX 4090运行Qwen3-32B INT4时，建议代理层限制并发连接≤8，避免GPU OOM
  • 日志追踪：在Nginx配置中添加access_log /var/log/nginx/clawdbot-access.log;，便于分析请求模式

6. 总结：一条清晰、可靠、可扩展的AI服务链路

至此，你已构建起一条从大模型到用户界面的完整数据通路：
Qwen3-32B（Ollama） → 18789端口代理（Nginx/Caddy） → Clawdbot Web网关 → 浏览器前端

这条链路的价值远不止于“让聊天框动起来”：
🔹 解耦架构：模型升级（如切换Qwen3-32B-GGUF）、前端迭代（Clawdbot新版本）、网关调整（增加鉴权）可独立进行
🔹 安全收敛：所有AI请求统一经过18789端口，便于审计、限流、熔断
🔹 生态兼容：/v1/chat/completions标准路径，未来可无缝替换为vLLM、Ollama其他模型，甚至Azure OpenAI

你不需要成为网络专家也能完成这一切——核心在于理解端口转发的本质是协议适配，而非技术炫技。当curl http://localhost:18789/v1/chat/completions返回第一行JSON时，你就已经站在了大模型应用落地的坚实地基上。

下一步，你可以：
→ 为18789端口添加Basic Auth实现简易鉴权
→ 配置Nginx SSL证书，启用HTTPS访问
→ 将Clawdbot与企业微信/钉钉集成，让AI助手走进工作流

真正的AI生产力，始于一个能稳定响应的端口。

获取更多AI镜像

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

Logo
龙虾开发者社区

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

更多推荐

cover

360Claw 企业终端部署实战：DLP 策略与 Agent 出口白名单的平衡术

avatar 龙虾开发者社区
cover

提示词缓存命中率暴跌：ClawSDK 如何实现版本变更时的零宕机过渡

avatar 龙虾开发者社区
cover

Telegram Bot 驱动 Agent：Webhook 验签与重放攻击防御清单

avatar 龙虾开发者社区