11434 连接被拒:发起方、监听方, 六种成因

■ space · 文字车道

发起方地图

一半的报错都是位置问题:监听方没事 —— 是发起方站到了监听方够不着的地方。

跑在裸 Linux 上的容器需要 --add-host=host.docker.internal:host-gateway —— Docker 自家文档就是为这个场景命名的这个旗标 · 同一网络里容器连容器: http://<服务名>:11434

六种成因,按概率排

从上往下走 —— 第一条对上你报错的行就带着修法:

OLLAMA 到底跑着没有？

桌面版本(macOS、Windows)把 Ollama 当托盘应用在跑,退出它比你想象的容易。Linux 装法由 systemd 服务在跑,重启之后它可能从来没被 enable。 ollama list 发给服务器,回的应该是一张模型表;如果它也回你一个连接错误,把服务器启起来,并把启动做成永久:

systemctl status ollama
sudo systemctl enable --now ollama   # start + survive reboots
journalctl -u ollama -n 50           # if it keeps dying, read why

验证: systemctl is-active ollama → active · ollama list → 一张模型表

端口、主机、LAN

Ollama 监听在 127.0.0.1:11434 ,除非另有吩咐。自定义端口:只要你哪天设过 OLLAMA_HOST=127.0.0.1:11435,服务器就会在 11435 答话,而每个还在打 11434 的客户端都吃闭门羹 —— 要确认真正在监听的是谁,用 ss -ltn | grep 1143。IPv6 陷阱:有些机器上 localhost 先就被解析成 ::1 在先,而一个只绑 127.0.0.1 的服务器永远看不见这些尝试 —— 分辨测试只要两秒: curl http://127.0.0.1:11434 通,而 curl http://localhost:11434 被拒。改呼 127.0.0.1,两个栈都绑,或者让客户端直接指 IP。

暴露到 LAN:默认 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 · 从另一台机器: curl http://<host-ip>:11434 → 「Ollama is running」

「refused」的两个邻居,其实是两种不同故障:防火墙还堵着 11434,产生的是 超时,不是拒绝 —— refused 是一声主动的「不」,timeout 是包根本没到。而浏览器 JavaScript 从别的源调 API,需要设好 OLLAMA_ORIGINS:那些调用 到达了,在 CORS 这一层被挡驾 —— 从外面看一模一样。

被拒的连接是位置问题,不是程序坏了:该监听的东西没在监听,或者发起方站到了监听方够不着的地方。

它反复回来

那就是一个进程占着端口,另一个次次输掉抢占。 ss -ltnp | grep 11434 会喊出握着 socket 的进程;手动启动的第二个 Ollama 实例正是惯犯。杀掉流浪者,让服务当唯一主人,错误从此消停。

验证: ss -ltnp | grep 11434 → 一行,一个 PID —— 就是服务

2026 年 9 月,Ollama 的 GitHub 星数过了 181,000 —— 跑它的机器越多,同一周里搜索这六种答案的人就越多。等服务器回了话,下一桩最常见的抱怨就是那块它死活不肯用的 GPU。诊断工作,离你一条 curl。

发起方地图到此为止 · 没有任何 fetch · 全程本地