连接 ollama api 失败

调用本地 Ollama 接口报错，可能是服务没起来、端口没对上、模型没拉下来，也可能是客户端把地址拼错了，症状都是「连不上」。这篇不堆结论，只给一条从底层往上的排查路线：先确认进程和端口，再验 HTTP 与 OpenAI 兼容层，最后看模型和客户端配置，每一步都写清「什么现象说明什么」。

调用本地 Ollama 接口报错，症状看起来都是「连不上」，但原因可能差得很远：有的是服务根本没起，有的是端口没对上，有的是模型没拉下来，还有的是客户端把地址拼错了。如果一上来就改客户端配置，很容易在错误的层里打转。

这篇给一条从底层往上的排查路线：先确认进程和端口，再验 HTTP 与 OpenAI 兼容层，最后看模型和客户端配置。每一步都写清「出现什么现象说明什么问题」，你照着顺序走一遍，基本能定位到断点在哪一层。

先分清是哪一层断了：进程、端口还是模型

最常见的误区是把三类报错混在一起处理。连接被拒绝、请求超时、返回模型不存在，这三者指向的层完全不同。先给报错分个类，再决定往哪个方向查，比逐个试配置快得多。

• 先在跑 Ollama 的那台机器上本地自测一次，本地通了再去查跨机调用，避免把网络问题和进程问题混在一起
• 同一台机器上能通、另一台不通，问题基本落在监听地址、防火墙或容器端口映射上，和模型无关
• 客户端报的错要连原始状态码一起看，只看到「失败」两个字很难判断是拒绝、超时还是被拒绝的请求体
• 如果你用的是托管型中转或第三方聚合接口，这套进程级排查不适用，应按平台文档核对地址与鉴权方式

验进程与端口：默认端口、监听地址、容器映射

这一层只关心两件事：服务在不在跑、请求能不能到达那个端口。很多「连不上」其实连进程都没起来，或者服务只监听了回环地址，外部请求自然被拒。先把这两点确认掉，再谈上层。

1. 确认进程在跑在跑服务的那台机器上查看进程是否存在；不存在就先启动，启动后立刻本地探一次接口，确认它真的对外响应。
2. 核对监听地址检查启动参数里的监听地址是否允许你要调用的那台机器访问。只监听回环地址时，同机调用能通、跨机一定失败，这是最容易忽略的一处。
3. 对齐端口把调用方配置里的端口和实际监听端口对一遍。改过端口但客户端配置没同步，是最常见的一种「昨天还好好的」。
4. 理清容器映射容器里跑的情况要分清容器内端口和宿主机映射端口。映射写错时，宿主机的请求根本进不去；桥接网络下再用回环地址调宿主机服务，通常也不会成功。

改完怎么验证

每改一处只验一次，不要一次动好几项。验证方式就是本地发一个最小请求，能看到正常响应就说明这一层通了；如果本地仍报连接被拒，说明进程或端口这层还没过，先别往上查。

验接口层：原生接口与 OpenAI 兼容接口分别试一次

进程和端口都没问题，接着验接口本身。很多人卡在这里，是因为原生接口和 OpenAI 兼容接口是两套地址，客户端按 OpenAI 协议调用时拼接方式和原生路径不一样，拼错就直接返回找不到路径。

• 先用最简单的请求探一次原生接口，能列出模型列表说明服务本身健康，问题就落在后面的模型名或兼容层
• OpenAI 兼容路径要按客户端实际使用的协议来拼，少一段或多一段前缀都会导致路径不存在
• 兼容层不接受某些参数或字段时，报错看起来像连接失败，实际是请求体被拒绝，可以先用最小请求体排除
• 想先量出延迟基线再去比对，可以用站内的接口测速页，把「超时」和「慢」这两种情况分开看

如果你只是想确认服务活着，别一上来就用复杂请求体，一个最小的、不带多余参数的请求更容易暴露真实原因。请求越复杂，越容易把「请求被拒绝」误判成「连接失败」。

验模型与客户端：模型名、鉴权头、环境变量

走到这一层，说明服务、端口、接口路径基本都通了，剩下的问题通常出在模型名对不上，或者客户端配置里混进了不该有的东西。这两类问题都很隐蔽，得逐项排除。

代理类环境变量是很容易被忽略的一条：它看起来和 Ollama 无关，但会把本该直连本机的请求转发出去，表现就是「本机也连不上」。排查时可以先临时清掉这类变量再试一次。

• 调用前确认模型确实已在本机拉取，名字要和列表返回的完全一致
• 改完一处配置就复测一处，不要攒着一起改
• 同一份配置在多台机器上用时，注意每台的地址和端口是否都适合本机情况
• 如果客户端和浏览器行为不一致，优先怀疑客户端侧的代理或鉴权设置

连不上不是一种错误，而是一串分层错误；从上往下猜，不如从下往上验。