星图平台Qwen3-VL:30B部署避坑：Ollama base_url格式、Clawdbot端口冲突、HTTPS代理配置

1. 部署前的关键认知：这不是普通模型，而是多模态大模型的本地化落地

很多人第一次接触 Qwen3-VL:30B 时，会下意识把它当成一个“升级版的纯文本模型”来部署——结果在 Ollama 调不通、Clawdbot 连不上、飞书收不到回复的循环里反复折腾。其实问题根源不在模型本身，而在于我们对多模态服务链路的理解偏差。

Qwen3-VL:30B 不只是“能读文字”，它真正强的是“看懂图片+理解上下文+生成精准响应”的闭环能力。这意味着它的部署不是单点配置，而是一条包含 Ollama 推理服务 → Clawdbot 网关代理 → 外部应用（如飞书）调用 的完整通路。任何一个环节的协议、地址或权限没对齐，整条链路就会静默失败。

本文不讲原理，不堆参数，只聚焦你在星图平台上真实踩过的三个高频深坑：

• Ollama 的 base_url 写错格式，导致 Python 客户端始终 404；
• Clawdbot 默认端口 18789 和星图平台公网映射规则冲突，页面白屏无响应；
• HTTPS 代理环境下，Clawdbot 无法信任星图平台的自签名证书，API 请求被拦截。

每一个坑，我们都用“错误现象 + 根本原因 + 一行命令修复”的方式呈现，确保你复制粘贴就能跑通。

2. Ollama base_url 格式避坑：别让 URL 少了 /v1，也别多了 https://localhost

2.1 常见错误写法与后果

你在星图平台控制台看到的 Ollama Web 页面地址是这样的：

https://gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net/

很多同学直接把这个地址原样填进 Python 代码的 base_url：

#  错误示范：少了 /v1，且用了 https://localhost
base_url="https://localhost:11434"  # 本地回环地址在云环境根本不可达
base_url="https://gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net"  # 缺少 /v1 路径

结果就是：ConnectionError 或 404 Not Found。因为 Ollama 的 OpenAI 兼容 API 并不暴露在根路径，所有请求必须走 /v1/chat/completions 这类子路径。

2.2 正确格式：严格遵循“协议+域名+端口+/v1”

星图平台为每个 GPU Pod 分配的公网地址，本质是一个反向代理。它把外部 https://xxx-11434.web.gpu.csdn.net 的请求，转发到容器内 http://127.0.0.1:11434 的 Ollama 服务。因此：

• 对外调用（Python 脚本、Clawdbot 配置）必须用 星图提供的完整 HTTPS 地址 + /v1
• 对内调用（Clawdbot 指向本地 Ollama）必须用 http://127.0.0.1:11434/v1（注意是 http，不是 https）

正确示例：

#  对外调用：用星图分配的公网地址 + /v1
client = OpenAI(
    base_url="https://gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net/v1",
    api_key="ollama"
)

#  对内调用（Clawdbot 配置中）：用 http + 127.0.0.1 + /v1
"baseUrl": "http://127.0.0.1:11434/v1"

关键提醒：星图平台的公网地址是 HTTPS，但容器内部的 Ollama 服务默认只监听 HTTP。Clawdbot 配置里如果写成 https://127.0.0.1:11434/v1，会因证书问题直接拒绝连接——这是新手最常忽略的协议细节。

3. Clawdbot 端口冲突避坑：18789 不是万能端口，得看星图怎么映射

3.1 为什么访问 https://xxx-18789.web.gpu.csdn.net 会白屏？

Clawdbot 启动后默认监听 127.0.0.1:18789，这是一个典型的“仅限本机访问”绑定。而星图平台的公网 URL（如 xxx-18789.web.gpu.csdn.net）背后，是一个 Nginx 反向代理，它需要把外部请求转发到容器内的 18789 端口。

但问题来了：星图平台的端口映射规则，默认只开放 80、443、8888、11434 等预设端口。18789 不在白名单里，所以你的请求根本到不了 Clawdbot 进程，浏览器自然显示空白页。

3.2 两步解决：改监听地址 + 开放代理信任

你不需要去申请开通端口，只需修改 Clawdbot 配置，让它主动适配星图的代理机制：

第一步：修改 ~/.clawdbot/clawdbot.json，将 bind 从 loopback 改为 lan

"gateway": {
  "mode": "local",
  "bind": "lan",   // ← 关键！改为 lan 表示监听 0.0.0.0，接受所有来源
  "port": 18789,
  ...
}

第二步：强制信任星图代理，添加 trustedProxies

"gateway": {
  ...
  "trustedProxies": ["0.0.0.0/0"],  // ← 关键！告诉 Clawdbot：所有 IP 都可信
  "controlUi": {
    "enabled": true,
    "allowInsecureAuth": true  // ← 允许非 HTTPS 认证（星图公网是 HTTPS，但代理到容器是 HTTP）
  }
}

改完后重启服务：

clawdbot gateway --restart

此时再访问 https://gpu-pod697b0f1855ba5839425df6ea-18789.web.gpu.csdn.net，页面就能正常加载了。

验证技巧：执行 ss -tuln | grep 18789，如果看到 0.0.0.0:18789 而不是 127.0.0.1:18789，说明监听已生效。

4. HTTPS 代理配置避坑：Clawdbot 不认星图证书？那就绕过它

4.1 现象：Clawdbot 日志报 CERTIFICATE_VERIFY_FAILED

当你在 Clawdbot 控制台点击“Test Connection”测试 Ollama 连接时，日志里突然冒出：

requests.exceptions.SSLError: HTTPSConnectionPool(host='gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net', port=443): Max retries exceeded with url: /v1/models (Caused by SSLError(SSLCertVerificationError("hostname 'gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net' doesn't match any of the subject alternative names")))

这是因为 Clawdbot 内部使用 Python 的 requests 库发起 HTTPS 请求，而星图平台的公网证书是自签名的，未被系统 CA 信任。Clawdbot 默认开启 SSL 验证，于是直接拒绝连接。

4.2 安全又简单的解法：只对星图地址禁用验证

我们不全局关闭 SSL 验证（那太危险），而是精准地只为星图域名设置 verify=False。方法是在 Clawdbot 的模型配置中，为 my-ollama 提供商显式声明：

"models": {
  "providers": {
    "my-ollama": {
      "baseUrl": "https://gpu-pod697b0f1855ba5839425df6ea-11434.web.gpu.csdn.net/v1",
      "apiKey": "ollama",
      "api": "openai-completions",
      "verifySsl": false,  // ← 新增这一行！仅对这个 provider 生效
      "models": [ ... ]
    }
  }
}

注意：verifySsl: false 必须加在 my-ollama 对象里，不能放在顶层。这样既解决了证书问题，又不影响其他 HTTPS 服务（比如你后续接入飞书 API）的安全性。

补充说明：如果你坚持用 http://127.0.0.1:11434/v1（推荐），则完全不会触发此问题——因为这是纯内网 HTTP 通信，不涉及证书。

5. 三坑连通验证：一次对话，确认全链路打通

现在，我们用一个最朴素的测试，一次性验证三个坑是否都已填平：

1. Ollama base_url 格式正确（能返回响应）
2. Clawdbot 端口可访问（控制台能加载）
3. HTTPS 代理证书不阻断（模型能成功调用）

操作步骤：

1. 确保 Clawdbot 已重启：clawdbot gateway --restart
2. 打开控制台：https://gpu-pod697b0f1855ba5839425df6ea-18789.web.gpu.csdn.net
3. 在右上角输入 Token csdn（即你配置的 auth.token）
4. 进入 Chat 页面，发送一句：“请描述这张图”，然后上传一张测试图片（比如一张办公室照片）

成功标志：

• 页面立即显示“正在思考…”
• nvidia-smi 终端中，GPU 显存占用瞬间跳升（说明 Qwen3-VL:30B 真正被调用）
• 3–8 秒后，返回一段准确描述图片内容的文字（例如：“这是一间现代开放式办公区，有玻璃隔断、灰色工位和绿植…”）

失败回溯：

• 如果卡在“正在思考…”超 30 秒 → 检查 clawdbot.json 中 models.providers.my-ollama.baseUrl 是否指向 http://127.0.0.1:11434/v1（不是 https，也不是公网地址）
• 如果页面报 “Connection refused” → 检查 ss -tuln | grep 18789 是否监听 0.0.0.0
• 如果返回空内容或报错 → 查看 Clawdbot 日志 clawdbot logs，搜索 SSL 或 404 关键词

6. 总结：避坑的本质，是理解云平台的服务抽象层

部署 Qwen3-VL:30B 本身不难，难的是看清星图平台为你做了哪些“隐藏工作”：

• 它把 http://127.0.0.1:11434 封装成 https://xxx-11434.web.gpu.csdn.net，但封装不等于透传——你需要知道内外协议差异；
• 它提供 18789 端口给 Clawdbot，但不自动开放该端口——你需要主动告诉服务“我要被所有人访问”；
• 它用 HTTPS 保护公网通信，但不替你管理容器内证书信任——你需要明确告诉组件“这里可以跳过验证”。

这三点，不是 bug，而是云平台服务抽象的必然代价。避开它们，靠的不是试错，而是看清每一层封装背后的网络事实。

下篇我们将聚焦飞书接入：如何把当前这个“能看图聊天”的本地服务，变成飞书群里的正式机器人——包括 Webhook 配置、消息加签验证、图片上传回调等真实企业级集成细节。

---

获取更多AI镜像

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