搜「Ollama 11434 连不上」的时候，绝大多数教程会让你把 OLLAMA_HOST=0.0.0.0:11434 加上、重启服务、再试一次。这个建议不算错，但它排错了顺序。因为「连不上」至少对应三种完全不同的故障：服务端压根没进程在听、服务端只听本机回环地址、以及客户端把 URL 写错了。这三种情况的修复动作互相之间几乎没有重叠，而改绑定地址只对第二种有效，还会把一个本来只在本机跑的服务直接暴露到局域网里。
我给自己定的顺序是：先在装 Ollama 的那台机器上，用一条不加载模型、不需要请求体的 GET 请求，判断服务到底起没起。 这条请求通了，后面所有关于进程、systemd、日志的排查全部可以跳过，问题一定在客户端配置或网络可达性上；这条请求被拒绝，那么客户端里填什么地址、什么端口、什么 /v1 后缀都救不回来，得先去把服务端拉起来。
一次请求把搜索空间砍掉一半，这才是排查里最值钱的一步。下面按「花多少时间 × 多大概率解决」排顺序，而不是像官方文档那样把八种原因并列摆出来——并列清单看着全，真卡住的时候你并不知道该先试哪一个。
我没有在这台机器上完整部署并长期运行 Ollama 服务端，所以这篇不写「深度体验」，不写「哪个模型好用」，也不提供任何我自己跑出来的性能数字。它只做一件事：把「connection refused」这类报错背后可验证的判别方法、每层排查该看的证据、以及官方文档里写明但排错文章很少串起来的机制解释，整理成一套能照着做完的顺序。
稿件里的命令和环境变量行为，都来自官方文档或公开排错资料，我会逐处标来源；命令的输出示例会明确标成（示例），不冒充实测结果。另外，凡涉及版本、默认端口、模型体积这类会随发布变化的数字，一律写「以当前客户端提示和官方文档为准」，不写死。
顺带说一个背景：Ollama 是个本地推理服务端项目，社区规模很大（来源：GitHub API，查询于 2026-11-09：仓库 ollama/ollama 约 18.6 万 star、许可 MIT、最近提交 2026-11-08；star 数每天都在变，不必记）。正因为用的人多，「装完了但连不上」成了非常集中的一类问题，也正因为它是本地服务，网络层的坑比一般 Web 服务更隐蔽。
动手之前先看报错原文，别只看 IDE 弹出的「模型不可用」。不同客户端会把底层错误包装成不同说法，但底层只有三类，处理方式完全不同。
第一类是立刻被拒绝，典型原文是 curl: (7) Failed to connect to localhost port 11434: Connection refused、connect ECONNREFUSED 127.0.0.1:11434。TCP 层直接告诉你：这个地址上没有任何进程在监听。它发生在应用之下，跟模型名、API Key、鉴权、上下文长度统统无关（来源：SSD Nodes《The Ollama API and port 11434 explained》，2026-11-09 查阅）。看到它，就不要再去改客户端的模型配置了。
第二类是服务在，但请求路径不对，典型表现是返回 404、返回一段空内容、或者 IDE 提示「模型不存在」「base URL 无效」。这类请求已经到达了服务端，说明进程和端口都是好的。Ollama 的原生接口在 /api 下，而给 OpenAI 兼容客户端用的路径是 http://localhost:11434/v1——少了 /v1 后缀，请求打到了守护进程却没打到兼容层（来源：CodeRouter《Fix: connection refused on localhost:11434》，2026-11-09 查阅）。这是配置错误，不是网络故障。
第三类是挂起后超时，现象是请求转圈几十秒才失败，而不是瞬间拒绝。瞬间拒绝说明对端明确回了一个 RST；挂起通常意味着包被中途丢掉了，最常见是防火墙、安全组、或者跨网段路由不通（来源：Local AI Master《Ollama Connection Refused on Port 11434》，2026-11-09 查阅）。这类问题改任何 Ollama 配置都无效，要去查网络策略。
把这三类的判别写在最前面，是因为后面每一层排查都依赖它。我见过太多人把「404」当成「服务没起来」，然后反复重启一个其实好端端跑着的进程；也见过把「超时」当成「端口写错」，把 /v1 加了又删、删了又加。
注意执行位置：必须是运行 Ollama 服务的那台机器、那个网络命名空间里。在你自己笔记本上跑，或者在一个 Docker 容器里跑，得到的结论是反的——这点后面第五层会展开。
# 1. 最小健康探测：不需要请求体、不加载模型，只列已拉取的模型
curl -sS -m 5 http://127.0.0.1:11434/api/tags
# 2. 再小一号的探测：只问服务端版本
curl -sS -m 5 http://127.0.0.1:11434/api/version
# 3. 看监听地址到底是谁（Linux）
ss -ltnp | grep 11434
第一条是整套排查的支点。/api/tags 返回的是一个 JSON 对象，里面带 models 数组；空数组是健康状态，只说明这台机器还没拉过模型，该做的是 ollama pull，而不是重启服务（来源：SSD Nodes《The Ollama API and port 11434 explained》）。这个区别很关键：不少排错文章把「返回的列表是空的」也列进「连不上」的原因里，导致读者在一条完全正常的返回上反复折腾。
第二条用来排除「HTTP 服务活着但 API 层异常」这种少见情况。第三条比前两条更重要，因为它给出的不是「有没有监听」，而是监听在哪个地址上：127.0.0.1:11434 和 0.0.0.0:11434 在终端里只差几个字符，含义却完全相反（来源：Local AI Master，同上）。
Windows 上 ss 不可用，用 PowerShell 看端口占用和所属进程：
netstat -bano | Select-String -Pattern 11434 -Context 0,1
macOS 与 Linux 的日志位置也不同：macOS 看 ~/.ollama/logs/server.log，Linux 用 journalctl -u ollama，直接 ollama serve 前台运行时日志就打在控制台（来源：Ollama 官方 FAQ 与 troubleshooting 文档，2026-11-09 查阅）。日志能回答「为什么没起来」，而 curl 只能回答「起没起来」，两者不要互相替代。
按这一步的结果分流：curl 通了 → 直接跳到第三层（客户端配置）和第五层（网络命名空间）；curl 拒绝 → 从第一层开始逐层往下走。
下面六层不是并列的六个原因，是一条有跳过条件的决策链。每层都给出「看到什么就说明是这层」和「看到什么就直接跳过」，尽量让你少做无用功。
第一层：服务端进程根本没起来。 概率最高，成本最低。安装完成不等于守护进程在当前会话里活着（来源：RunLocalAI《Ollama: connection refused on localhost:11434》，2026-11-09 查阅）。Linux 上用 systemctl status ollama 看是不是 inactive (dead)，是就 sudo systemctl start ollama；没有 systemd 的环境（WSL2、手工解压的 macOS）用 ollama serve 前台起；macOS 从应用程序启动，Windows 从托盘启动。判据很干脆：ss 或 netstat 里查不到 11434 的监听项，就是这一层，后面五层暂时都不用看。
第二层：只绑定了回环地址。 官方 FAQ 写得很明确：Ollama 默认绑定 127.0.0.1 的 11434 端口，要改绑定地址得设 OLLAMA_HOST（来源：Ollama 官方 FAQ，2026-11-09 查阅）。所以在本机 curl 一切正常、换一台机器或用宿主机 IP 访问就被拒绝，几乎必然是这一层，不是服务崩了。判据是：ss 里能看到 127.0.0.1:11434 在听，但用另一台机器连不上。
第三层：客户端 base URL 的形状不对。 OpenAI 兼容客户端要填带 /v1 的地址；只填 http://localhost:11434 会到达守护进程但到不了兼容 API（来源：CodeRouter，同上）。另外不同工具的默认端口不一样，照着 A 工具的教程填进 B 工具，会得到一条看起来很像「服务没起」的拒绝（来源：同上）。判据：本机 /api/tags 通、客户端仍失败，且失败发生在配置层面。
第四层：端口被占，或者自己改过端口却忘了改客户端。 如果启动时日志里有 bind: address already in use，那是另一个进程占着 11434，重启 Ollama 一万次也没用（来源：RunLocalAI，同上）。同理，用 OLLAMA_HOST 把端口换成别的值之后，所有客户端都得跟着换。判据：日志出现 bind 错误，或者环境变量里存在非默认端口。
第五层：网络命名空间不是同一个。 Docker 容器里的 localhost 指容器自己，不是宿主机；WSL2 里的 localhost 和 Windows 侧也不天然互通（来源：CodeRouter、InsiderLLM，2026-11-09 查阅）。这类场景的表现特别迷惑：宿主机上 curl 明明是通的，容器里却拒绝。Docker 侧通常用 host.docker.internal 指向宿主机，Linux 上也可以用 --network=host（来源：同上）。判据：换个执行位置结果就翻转。
第六层：防火墙或安全组。 最后才查，因为它最费时间、概率最低，而且现象有辨识度——挂起后超时，而不是瞬间拒绝（来源：Local AI Master，同上）。判据吻合再去做入站规则，别在第一层就折腾防火墙。
这六层的排序理由，和站内另一篇讲限流的文章是同一个思路：先把高概率、低成本、能一条命令证伪的分支排前面。真正省时间的不是知道多少种原因，是知道哪些原因现在就可以不用查。
排错时最容易浪费时间的，是拿着一条模糊的中文描述「Ollama 连不上」去逐层试。下面这张表是把可观察现象直接映射到层级的速查表，用的时候从上往下找第一行匹配的（示例：以下为按官方文档与公开排错资料整理的映射关系，不是某次实测的记录）。
| 你实际看到的现象 | 优先查哪层 | 一条命令确认 |
|---|---|---|
Connection refused / ECONNREFUSED，且失败是瞬间的 | 第一层 | ss -ltnp \| grep 11434 无输出 |
| 本机 curl 正常，另一台机器 / 宿主机 IP 被拒绝 | 第二层 | ss 显示监听在 127.0.0.1 |
/api/tags 返回正常 JSON，IDE 仍报模型不可用 | 第三层 | 检查 base URL 是否带 /v1 |
服务端日志有 bind: address already in use | 第四层 | ss 里看占用进程 |
| 宿主机通、容器内不通 | 第五层 | 容器内 curl localhost:11434 对比宿主机 |
| 请求转圈后才失败，不是瞬间拒绝 | 第六层 | 从客户端侧测连通性 |
/api/tags 返回空 models 数组 | 不属于任何层 | 这是健康状态，去拉模型 |
最后一行值得单独强调一次：空数组不是故障。把它当故障，是这类排查里最常见的一次自我误导。
到第二层时，几乎所有教程都会直接给一行 OLLAMA_HOST=0.0.0.0:11434。能用，但它的含义是让服务监听机器上所有网卡，同一局域网内其他设备都能直接调你的本地推理接口，而原生 API 本身没有账号体系。所以我建议的顺序是：先问「调用方到底在哪」。
127.0.0.1，什么都不用改，去查第三层host.docker.internal 之类的宿主机别名，不动服务端绑定设置方式按平台差别很大，这点官方文档写得比多数转载文章清楚：Linux 以 systemd 服务运行时，用 systemctl edit ollama.service 在 [Service] 下加 Environment="OLLAMA_HOST=0.0.0.0"，然后 daemon-reload 并重启；macOS 以应用形式运行时用 launchctl setenv OLLAMA_HOST "0.0.0.0" 再重启应用；Windows 继承用户/系统环境变量，要先从托盘退出 Ollama、改完变量再重新打开（来源：Ollama 官方 FAQ，2026-11-09 查阅）。
# Linux systemd：写入持久化环境变量（改完必须重启服务）
sudo systemctl edit ollama.service
# 在 [Service] 段加入：
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload
sudo systemctl restart ollama
还有一个容易漏的点：如果是浏览器里的前端页面跨域调用，光改绑定地址不够，还要看 OLLAMA_ORIGINS——官方 FAQ 说明默认只允许来自 127.0.0.1 和 0.0.0.0 的跨域请求，额外来源要用这个变量加白名单（来源：Ollama 官方 FAQ，同上）。这种情况下 TCP 早就通了，失败发生在浏览器层，跟前面六层网络排查不是一回事。
「装完就等于服务起来了」：安装向导走完、模型也拉好了，不等于守护进程在当前会话里还活着。站内那篇 本地部署大模型实战：Ollama + Open WebUI 完整教程 走的是完整安装路径，适合对照检查自己漏了哪一步；而本文处理的是「装完了但连不上」这一分支。
「base URL 填对了但客户端就是不通」：编辑器插件类客户端多数走 OpenAI 兼容层，路径形状和原生 API 不同。Ollama + OpenCode + VS Code 打造完全免费离线的 AI 代码补全方案 里配置了完整的客户端链路，可以拿来逐字段比对 base URL、端口和模型名。
「把别的报错当成端口故障」：知识库导入失败、模型找不到、向量库报错，这些是请求已经到达服务端之后的应用层问题，跟 11434 没监听完全是两码事。OpenCode 本地知识库导入失败怎么解决 列的是后一类。反过来也一样，限流返回的是 HTTP 状态码，不是连接被拒绝，Claude API 429 限流完全解决指南 里那套重试与降速思路，对 Connection refused 一点用都没有。
「报错文案看着像鉴权失败」：有些客户端在连不上后端时会笼统报「API Key 无效」或「模型不可用」，把人往密钥配置上带。Cursor编辑器配置DeepSeek报错API Key无效 就是这类文案的典型例子。遇到这种含糊提示，回到第二步那条 curl：它不需要 Key，能通就说明密钥方向是死路。
「云端发起的请求怎么都连不上本机」：如果调用请求是从某个 SaaS 服务或云端 IDE 的服务器发出的，它根本到不了你家里的 127.0.0.1，任何本地配置都救不了（来源：CodeRouter，同上）。判据是「同一个功能在有的入口能用、有的入口永远失败」，这时该考虑内网穿透，而不是继续改 Ollama。
把前几步串成一个从上到下、每层都能停下来的检查单（示例脚本，按官方文档与公开排错资料整理；请按自己的系统替换命令，Windows 下把 ss、systemctl 换成对应命令）：
#!/usr/bin/env bash
# Ollama 11434 分层排查：自上而下，命中即停
set -u
echo "== L0 先看本机 API 通不通 =="
if curl -sS -m 5 http://127.0.0.1:11434/api/tags -o /tmp/ollama-tags.json 2>/dev/null; then
echo "服务端正常，输出模型列表摘要："
head -c 200 /tmp/ollama-tags.json; echo
echo "→ 跳过 L1/L2，直接查客户端 base URL 与网络命名空间"
else
echo "本机也被拒绝 → 进入 L1"
echo "== L1 进程 / 服务 =="
systemctl status ollama --no-pager 2>/dev/null || echo "无 systemd 服务，试 ollama serve 前台启动"
fi
echo "== L2 监听地址（127.0.0.1 还是 0.0.0.0）=="
ss -ltnp 2>/dev/null | grep 11434 || echo "无监听项"
echo "== L4 端口占用与自定义端口 =="
echo "OLLAMA_HOST=${OLLAMA_HOST:-<未设置，使用默认>}"
echo "== L6 只有「挂起后超时」才需要查防火墙 =="
echo "瞬间拒绝 = 没进程/地址不对；挂起超时 = 网络策略"
脚本不自动修复任何东西，只负责把「现在该往哪一层走」打印出来。刻意不做自动重启、不自动改环境变量——排错阶段最怕的就是同时改了两个变量，最后不知道到底是哪个起了作用。
推荐给两类人：一类是在自己机器上装了 Ollama、编辑器或脚本里报 Connection refused，但不确定该改服务端还是改客户端的人；另一类是要在 Docker、WSL2、局域网里让别的程序调用本地模型，被 localhost 的含义绕晕的人。对你们来说，这套顺序的价值不在「列得全」，而在每层都有明确的跳过条件，通常两三条命令就能定位。
不推荐给两种情况。第一，如果你看到的报错是模型推理慢、显存不够、回答质量差，那是模型与硬件层的事，和端口通不通无关，别从这篇开始查。第二，如果你只是想挑一个本地大模型工具、比较谁更好用，这篇也给不了答案——它是排查手册，不是评测，更不是项目介绍。
最后留一句我认为最实用的判断：「connection refused」几乎永远不是配置不够全，而是有一层前提没成立。 先找到那层前提，再谈怎么改。至于改完之后要不要长期把服务暴露在局域网上，我的建议是能不暴露就不暴露——本地推理最大的好处本来就是数据不出本机，别为了省一次 host.docker.internal 把它丢掉。