openclaw+ollama部署

很多人是先在本地把 ollama 跑通了，再去接 openclaw，结果卡在「模型列表空的」「请求超时」「配置改了没生效」这几步上。这篇不讲这两个东西各自是什么，只拆联合部署的顺序：先确认 ollama 服务对谁可见，再决定 openclaw 从哪里读模型，最后按顺序验一遍。适合第一次把两者拼起来、又不想反复重装的人。

不少人先在本地把 ollama 跑通，觉得没问题，转头去接 openclaw，结果卡在「模型列表空的」「请求超时」「改完配置没反应」这几步。问题多半不在模型本身，而在两者之间的地址、端口和名字没对齐。这篇只拆联合部署的顺序和排查路径，讲清先动哪一层、后动哪一层，适合第一次把两者拼起来、又不想反复重装的人。

整体思路一句话：先让 ollama 服务对正确的对象可见，再让 openclaw 从正确的地址读模型，最后按层验证。下面按动手前预检、部署顺序、配置填写、排障顺序、不适用场景五块展开，每块都给能直接照做的动作和判断标准。

动手前先确认三件事

这三件事没确认就开配，后面出问题会同时怀疑好几个环节，越排越乱。花几分钟先把服务本身验活，再想清楚 openclaw 跑在哪，最后把模型拉好、名字记准，后面能省掉大半返工。

• ollama 服务本身是活的：能列出模型、能用命令行跑通一次对话，否则后面全是白折腾。
• 想清楚 openclaw 跑在哪：同一台机器、同局域网另一台、还是容器里，这三种情况填的地址完全不一样。
• 先把要用的模型拉下来并存好，别等到配置阶段才发现模型名对不上；模型库和部署测算可到 /models 与 /models/deploy 对一遍当时的资料。

部署顺序：先服务后客户端

顺序反过来做——先配客户端再调服务——会反复重启，出问题时也分不清是哪一层坏了。正确做法是每一层单独确认，通过后再进下一层。服务地址和监听端口先定下来，本机自用和局域网共用是两种配法，别混着试。

1. 定服务地址与监听端口先决定 ollama 只给本机用，还是给局域网其他机器用，据此确认服务监听在哪个地址、哪个端口；改完用命令行在本机验一次能正常返回。
2. 在 openclaw 侧填模型来源填的是服务地址加模型名，不是模型文件路径，这是最容易填错的一格；填完先别上复杂任务。
3. 用最小请求验连通发一条最简单的请求，只看两件事：请求能出去、回复能回来。这一步过了再换真实任务。

这张表看着简单，但地址选错是最高频的失败原因。填之前先问一句：openclaw 所在的进程或容器，从这个位置出发能到达哪个地址？以那个视角为准，而不是以你在浏览器里能不能打开为准。

配置项怎么填、哪些改了要重启

配置里通常分三块：服务地址、模型名、可选的鉴权或超时参数。三块里地址和模型名是硬门槛，错一个就连不上或找不到模型；鉴权和超时属于调优项，先放默认值也能跑。

服务地址

填 openclaw 视角下能到达的 ollama 地址，不是浏览器能打开的地址。

模型名

必须和 ollama 里列出来的完全一致，带不带标签后缀经常差一个字符就找不到。

超时参数

先给宽松值跑通，再按实际情况收紧，别一开始就设得很短。

鉴权参数

服务没开鉴权就别乱填，填了反而会被拒。

改完配置一般需要重启 openclaw 侧进程才生效，只重启 ollama 是没用的。判断依据很简单：改完配置发一次请求，如果行为和改之前一模一样，多半是配置没被重新加载。

连不上就按这个顺序排

连不上时最忌讳同时改好几处。按服务层、网络层、应用层的顺序一层层往下查，每层确认没问题再进下一层，这样最多几次就能定位到是哪一层坏了。

• 先看服务层：ollama 进程在不在、端口通不通，这一步不通就别看 openclaw 的日志。
• 再看网络层：跨机器访问时，服务是否只绑在本机回环上，多数「能 ping 通但请求失败」都出在这。
• 最后看应用层：模型名是否写错、超时是否太短、返回的错误码指向哪一侧。
• 如果本地环境本身就不稳，先用 /tools/speed-test 量一个延迟基线，再判断是网络慢还是模型慢。

排障时记住一个原则：日志只看当前这一层，跨层日志容易把人带偏。本层通了再翻下一层的日志，效率会高很多。

什么情况下这套方案不合适

本机拼装的方式适合个人验证和小规模自用，但不是所有场景都该这么搭。多人同时用、要求稳定吞吐的场景，本机拼装容易互相抢资源，该考虑更正规的服务化部署。需要对外提供服务、走公网访问的，先把暴露面和鉴权想清楚，别直接把服务端口开出去。只是临时试一个模型效果，不值得搭这套，直接用命令行跑一次更快。

先服务后客户端，先连通后调优，排障永远从最外层往里查。