Ollama connection refused？60 秒定位法

这个错误从不含糊其辞：curl: (7) Failed to connect to localhost port 11434: Connection refused 是操作系统在报告——11434 端口上没有任何进程在监听。Ollama 没有"坏掉"，模型也没有损坏；网上条件反射式的答案——重装——绕开了六种无聊的成因，而每一种排除起来都只要一分钟。

先跑定位命令。在读下面任何一节之前，它就把问题切成了两半：

curl http://localhost:11434

返回 Ollama is running 说明服务端没问题，是客户端调错了地方——直接跳到"调用方"那几节。返回 Connection refused 说明要修的是服务端。我在一台用完即弃的 bench 虚拟机上复现了这个拒绝本身：机器上没有任何东西监听时，内核直接回答 bash: connect: Connection refused，根本轮不到应用层。

为什么 Ollama 报 connection refused？

因为一次 TCP 连接到达了一台没有 socket 占据 11434 端口的主机。机制就这么点——下面六种情况必居其一，这里按出现频率从高到低排列。

Ollama 真的在运行吗？

桌面版（macOS、Windows）把 Ollama 作为托盘应用运行，它比人们以为的更容易被顺手退出。Linux 安装走 systemd 服务，重启之后可能从来没被 enable 过。

# Linux：服务还活着吗？
systemctl status ollama

# 在任何平台都适用的直接检查：
ollama list

ollama list 连得上服务时，会回答一张模型表。如果它也报连接错误，就把服务拉起来并让开机自启成为常态：

sudo systemctl enable --now ollama   # Linux：启动 + 重启后仍在
journalctl -u ollama -n 50           # 如果它反复死掉，来这里读原因

服务一起来就死，在这里表现为 crash loop，journalctl 会打印原因——端口被占、磁盘满了、环境变量覆盖写错。

是端口的问题，还是你调的主机不对？

除非另有配置，Ollama 监听 127.0.0.1:11434。两种经典错位：

自定义端口。 如果你（或你照着做的某篇教程）设过 OLLAMA_HOST=127.0.0.1:11435，服务在 11435 上应答，所有还在调 11434 的客户端都会被拒绝。确认实际在监听的是什么：

ss -ltn | grep 1143

正常应该看到一行 127.0.0.1:11434。一行都没有：服务没起来（上一节）。端口或地址不一样：该更新的是你的客户端。

localhost 对 127.0.0.1。 在一些机器上，localhost 会先解析成 IPv6 地址 ::1，而只绑定 127.0.0.1 的服务永远看不到这些连接尝试。分辨这两种情况的测试只要两秒：

curl http://127.0.0.1:11434   # 通，而 curl http://localhost:11434 被拒

如果裸 IP 通而域名不通，就让服务两个都绑，或者让客户端直接指向 127.0.0.1。

为什么宿主机上正常，Docker 里就不行？

这是野外最常见的变种——这个错误的自动补全里全是 n8n、Open WebUI 和 VS Code 插件，就是这个原因。每个调用 http://localhost:11434 的容器都在调用它自己：容器内，127.0.0.1 是容器自己的 loopback，那里什么都没监听。

调用方	指向宿主机 Ollama 的正确 URL
Docker Desktop 上的容器	`http://host.docker.internal:11434`
原生 Linux 上的容器	`http://host.docker.internal:11434`，外加 `--add-host=host.docker.internal:host-gateway`
同一 Docker 网络里的容器	`http://<服务名>:11434`
局域网里的另一台机器	`http://<机器IP>:11434`（见下一节）

host-gateway 这个参数来自 Docker 官方文档对这个场景的说明；仅这一行就能修好一半来自容器的"Ollama connection refused"报告。

怎么把 Ollama 暴露给其他机器？

默认只绑定 loopback——这是有意为之，因为这套 API 没有身份验证。暴露它只需一个环境变量；把它写进 systemd 的 override 而不是你的 shell，服务才真正读得到：

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

然后 sudo systemctl restart ollama，用 ss -ltn | grep 11434 确认——地址列应该显示 0.0.0.0:11434。两个常被跳过的后续：防火墙还在拦 11434 时，症状是超时而不是拒绝（另一种失败，同一个端口）；浏览器 JS 从别的源调用 API 时需要设置 OLLAMA_ORIGINS，见 Ollama 自己的 FAQ——浏览器请求到达了，但在 CORS 层被挡下，从外面看一模一样。

connection refused 是个位置问题，不是程序坏了：该监听的没在监听，或者调用方站的地方，监听者够不着。

如果它反复出现？

那就是一个进程占着端口，另一个每次都输掉竞争。ss -ltnp | grep 11434 会显示握着 socket 的进程；手动多启的一个 Ollama 实例是惯犯。杀掉多余的那个，让 systemd 服务当唯一的主人，错误就不再回来。

集群里的下一步：服务能应答之后，它不肯用的那块 GPU 是最常见的下一个抱怨，本地跑 GGUF 模型覆盖加载那一侧。两者都收录在本地 LLM 主题页。

2026 年 9 月，Ollama 的 GitHub 星标突破了 18.1 万——跑它的机器越多，同一周内被搜索的答案就越多。定位，一条 curl 的距离。