Ollama 本机能访问，远程请求却报 Connection refused

在 Ollama 服务器上请求 127.0.0.1:11434 正常，另一台机器访问却报 Connection refused。先看请求发到了哪个地址，以及服务有没有在那个地址和端口监听。

下面按 Ollama 0.5.2 的本地服务配置与 HTTP API 说明。拒绝连接发生在 HTTP 处理之前；它不是模型不存在，也不能靠修改 OLLAMA_ORIGINS 就自动恢复。

127.0.0.1 和 0.0.0.0 分别用在什么地方

Ollama 0.5.2 默认绑定服务器自己的 127.0.0.1:11434。远程客户端中的 127.0.0.1 指客户端自己，无法直接到达服务器。0.0.0.0 用来表示监听所有 IPv4 接口，也不应当成服务器的远程访问地址。

先在服务器本机确认原地址的 /api/tags 能返回模型列表；再核对远程请求的主机、协议和端口。若本机也拒绝连接，应检查服务是否启动、是否已退出或实际端口不同，不能先归因于远程防火墙。

Linux 使用系统服务时，终端中 export OLLAMA_HOST=... 不会修改已经运行的服务环境。0.5.2 的配置说明使用 systemctl edit ollama.service 设置服务 override，修改后需重载并重启。重启会中断正在处理的请求，应先保存旧配置，在维护窗口操作，再读实际日志和监听地址。

只需要自己远程开发时，用 SSH 隧道

已有授权 SSH 入口时，可以保留 Ollama 的回环监听，在客户端建立本地转发。以下示例中，dev 是已有服务器的登录用户名，server.example.com 是服务器主机名，两者都应替换为实际值。客户端的 11435 需未被占用：

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:11435:127.0.0.1:11434 \
  -l dev server.example.com

连接存续期间，另一个客户端终端请求本地转发端口：

curl --fail --show-error http://127.0.0.1:11435/api/tags

这里第二个 127.0.0.1:11434 从 SSH 服务器一侧连接 Ollama。它不是让 Ollama 在公网监听，也不会自动解决服务器上的服务未启动。SSH 策略必须允许转发，服务器身份按原来的信任配置验证，不要关闭主机密钥检查。

先用模型列表确认通路，再把应用的 Ollama base URL 改为 http://127.0.0.1:11435。测试结束关闭转发会话，恢复原客户端地址；隧道关闭后应用不能继续通过该端口访问。

容器里 localhost 是另一个网络位置

应用在普通独立网络的容器里时，localhost 指该容器，不是宿主机，也不是旁边的 Ollama 容器。两个服务位于同一个 Docker 网络时，客户端通常通过 Ollama 服务名及容器内端口连接；宿主机服务则需要按实际平台配置可达地址。

不要同时创建一个手动 ollama serve 来碰运气：它可能监听另一个端口、使用另一个账号和模型目录，让后续诊断更混乱。先沿现有服务确定网络与目标。已有 Compose 地址问题的基本检查可参照跨容器连接地址的区分，其中 PostgreSQL 初始化逻辑不适用于 Ollama。

共享服务需要监听变更时，配置完整访问边界

确实要让其他应用持续访问，才评估绑定私网地址或经受控反向代理提供入口。Ollama 的本地 API 不能被当成默认已有应用鉴权的公网服务；监听变更应配合现有身份验证、网络访问范围和请求限制，不直接开放所有接口与端口。

TCP 可以连接后，若浏览器单独报 CORS，再核对它的实际 Origin 与 OLLAMA_ORIGINS。CORS 是浏览器对响应访问的限制，不是服务端认证，也不是监听配置。若返回的是带模型名的 404，网络已进入另一个问题分支，应继续检查模型名和对应实例。