ragflow ollama url

在 RAGFlow 里加 Ollama 模型，最容易卡在两件事：地址填 localhost 反而连不上，以及填了地址但拉不到模型列表。这篇不重复讲协议兼容，只给地址写法的判断依据、按顺序的连通性排查动作，以及怎么把结果留下来方便下次复用。

在 RAGFlow 里加 Ollama 模型，大多数人不是卡在协议兼容，而是卡在地址上。典型症状有两个：地址填了 localhost 反而连不上；地址看着没错，但模型列表一直是空的。

这篇只讲地址怎么写、连不上按什么顺序查、跑通之后怎么把结果留下来。判断依据给你，具体填哪个值你自己对着环境套。

地址该填哪个：先看你俩在不在同一个网络里

填地址之前先回答两个问题：RAGFlow 是跑在容器里还是直接跑在宿主机上？Ollama 跟它在不在同一台机器？这两个答案组合起来，地址的写法基本就唯一了，不用靠反复试。

注意最后一列只是常见情况，不是绝对规则。比如你的容器网络做了自定义桥接，或者走的是同一个编排网络里的服务名，那标识形式会不一样，以你环境里实际能解析到的为准。

• 先写清楚环境：RAGFlow 在哪跑、Ollama 在哪跑、两者之间是直连还是隔着网络层
• 端口别凭印象写，先去 Ollama 自己的接口文档确认默认监听端口，再回到 RAGFlow 的表单字段名上对照
• 地址里带不带协议头、末尾要不要斜杠，以 RAGFlow 页面上那行字段说明为准，别照抄别人的截图
• 如果 Ollama 是被单独部署的，顺手确认它的监听配置不是只绑定本地回环，否则外部永远进不来

连通性排查：按「进程→端口→网络→应用」四步走

连不上不要一上来就改表单。从下往上查，一层过了再进下一层，能省掉大量来回试的时间。

1. 第一步：确认服务在跑在 Ollama 所在的那台机器上，看进程是否活着、监听状态是否正常。这一步不通过，后面全是白费。
2. 第二步：从 RAGFlow 侧发起请求在 RAGFlow 所在的容器或主机上，用最朴素的方式请求一次 Ollama 的接口。能返回内容，才说明网络这一层通了。
3. 第三步：查网络层同机看是不是绑定了回环地址；跨机看防火墙、安全组、端口映射；容器场景额外确认网络模式，决定用哪个标识去访问。
4. 第四步：回到 RAGFlow 表单前面都通了再动表单。确认协议头、端口、斜杠这些细节，具体格式以页面上的字段提示为准。
5. 每步留痕每过一层存一条命令或一张截图，下次换机器直接照抄，不用从头猜。

地址通了但模型列表空：往下查什么

地址已经能通，但下拉里读不到任何模型，这是另一类问题。它和地址对不对没关系，往下查的方向也完全不同。

• 先确认 Ollama 那一侧本地到底有哪些模型可用，很多时候是模型还没被拉下来
• 配置改完之后要重新触发一次读取，只刷新页面不一定生效
• 模型名和标签要对得上，写错一个字符就会表现为拉不到
• 排除服务侧的整体波动：去站内 /ai-status 看一眼，确认不是依赖的服务在抖动，再回到自己的配置里

什么情况下这条不适用：如果你压根就没打算用本地模型，而是准备接远端推理服务，那模型列表空是另一套原因，不用按这个顺序查。

跑通之后：把配置固定下来并顺手测一次

地址一旦调通，别急着往下走流程。先把这套配置记下来，团队里几个人共用同一套环境时，能省掉重复踩同一批坑。

正式接进知识库流程之前，先发一条最简单的请求，验证端到端能出结果。不要等到索引阶段才发现不通，那时候排查成本高得多。

如果之后要把本地 Ollama 换成远端推理或走中转接入，地址口径和可用性都会变。切换前先去站内页面核对当时的接入方式和状态，别照着原来的地址直接改。