dify 添加 ollama 报错

在 Dify 里加一个 Ollama 模型供应商，填完地址点保存却红了，或者测试连接转圈半天没反应——这种问题大多不是 Dify 坏了，而是地址写错、模型没拉下来、上下文设太大这几件事之一。这篇不解释原理，只给一条从外到内的排查路线：先确认服务本身活着，再查 Dify 能不能碰到它，最后看参数和资源。

在 Dify 里加一个 Ollama 模型供应商，填完地址点保存却红了，或者测试连接转圈半天没反应——这种问题大多不是 Dify 坏了，而是地址写错、模型没拉下来、上下文设太大这几件事之一。先别急着重装，按从外到内的顺序走一遍，通常几分钟就能定位到是哪一层出的问题。

这篇不解释原理，只给一条排查路线：先确认 Ollama 服务本身活着，再查 Dify 能不能碰到它，然后看模型名和参数，最后回到资源和日志。每一步都给判断标准，照着做就行。如果你更想先确认自己用的中转站或模型服务本身可不可信，可以顺手到 /sites 看看相关的检测结论。

第一步：先确认 Ollama 自己是活的

排查顺序的第一原则是：别在 Dify 里折腾一个可能根本没起来的服务。在装 Ollama 的那台机器上直接请求它的接口，看有没有正常返回模型列表。返回不了，就先把 Ollama 自己修好，Dify 侧怎么改都没用。

1. 本机直接请求接口在 Ollama 所在机器上用命令行请求它的接口，看能不能列出本地模型。列不出来说明服务没起或端口不对，先解决这个。
2. 确认监听网卡只看本机能通还不够。确认它监听的是所有网卡而不是只绑本机回环；只绑回环时，同一台机器通、跨机器一定连不上。
3. 确认模型已拉取在本地列表里找到你要用的那个模型。没拉下来时报的错，跟「服务不通」长得完全不一样，别混在一起查。
4. 测两边连通性Dify 和 Ollama 在不同机器或不同容器时，先测这两边能不能互相 ping 通、端口能不能通，再回到 Dify 界面点测试。

第二步：地址怎么填，以及跨容器怎么通

这一层出错最常见，尤其是 Dify 用容器跑、Ollama 装在宿主机上的场景。容器里的 localhost 指向容器自己，不是宿主机，套用宿主机网络地址才能真正连出去。判断标准很简单：浏览器能打开接口地址，不代表 Dify 容器内部也能打开，这两件事要分开验。

• 先把地址填成最小可用形式，不要带多余路径和查询串，能通之后再考虑加复杂度
• 同一个容器编排网络里，优先用服务名而不是写死的 IP，避免下次重启又连不上
• 如果前面有网关或反向代理，注意地址末尾别多拼一层路径，也别漏掉协议头
• 验证时别只看 Dify 的报错文案，两边分别测一次，确认请求到底走到了哪一层

第三步：模型名和参数对不上

服务能通、地址也对，还是报错，八成卡在模型名或参数上。模型名要写本地列表里那个准确的标识，多一个标签后缀或少一个都可能被拒。参数方面，上下文长度、最大输出这类别一上来就拉满，超出本地显存时会表现为加载失败或直接超时。

模型名

以本地列表里的实际标识为准，多一个后缀或少一个都可能被拒

上下文长度

别一上来拉满，超出本地显存时表现为加载失败或超时

采样参数

先调回默认值再试，排除参数本身把请求打挂

量化版本

同名模型存在多个版本时，确认填的是你实际拉下来的那个

一个实用的动作：换成本地最小的那个模型试一次。小模型能通、大模型不通，基本可以定位到资源而不是配置。这一步做完，参数层的嫌疑就排得差不多了。具体各家模型支持的参数范围，可以到 /models 对照当时的资料。

第四步：资源和日志，看哪一边先出问题

走到这一步，配置基本没问题了，剩下的就是资源和日志。本地显存或内存不够时，第一次请求会卡很久然后失败，观察任务管理器往往比读报错信息更快。同时打开 Dify 侧日志和 Ollama 侧日志，看请求到底有没有到达 Ollama：没到达就是网络层的事，到达了但报错就是模型或资源层的事。

• 第一次请求卡很久再失败，先看本地显存和内存占用，别急着改配置
• 两边日志对照着看，确认请求有没有真的到达 Ollama 那一侧
• 小模型通、大模型不通，优先怀疑资源，不要反复改地址
• 长文本一进去就报错，先把输入截短复测，区分上下文超限还是服务不稳
• 改完一处只测一次，别同时改地址和参数，不然不知道是哪一步生效了

如果你在对比不同接入方案的稳定性和成本，别凭感觉判断，到 /price-watch 核对当时的数字，再到 /rankings 看看不同来源的横向表现，避免被一次性测速误导。