设置ollama监听在0 0 0 0

本地跑 Ollama 挺顺，但换到另一台机器、容器里、或者手机上一连就报连接被拒，多半是它只绑了本机回环地址。这篇不聊模型选型，只讲绑地址这一件事：改哪个环境变量、Windows 和 Linux 各怎么落地、怎么判断是真的通了还是防火墙在骗你，以及对外开之前该做的几项收尾。

本地跑 Ollama 挺顺，可换台机器、进容器、或者手机上一连就报连接被拒，十有八九不是模型的问题，而是它只绑了本机回环地址。默认状态下服务只监听 127.0.0.1，意思是只有这台机器自己能连，局域网里其他设备根本碰不到端口。这篇不谈模型选型，只讲绑地址这一件事：改哪个变量、Windows 和 Linux 各自怎么落地、怎么判断是真通了还是防火墙在骗你，以及对外开之前该做哪几项收尾。

先把预期摆正：改监听地址是个五分钟能做完的动作，难的是判断它到底生效没有，以及开出去之后谁都能调这件事你接不接受。下面每个小节都给可执行的动作和判断标准，照着做基本不会卡。要查当前各家模型的接入方式和价格，到 /price-watch 核对当时的数字，别凭记忆拍。

先弄清「监听在 0.0.0.0」到底改变了什么

0.0.0.0 不是一个具体 IP，它的含义是「本机所有网卡都收」，包括有线、无线、虚拟网卡、容器网桥。写成 0.0.0.0 之后，别人只要路由能到这台机器，就能连上这个端口。反过来说，它并不会帮你打通网络、也不会自动放行防火墙，只解决了「服务愿不愿意接」这一层。

服务绑在哪

进程监听哪个地址，决定它接不接受来自外部的连接请求

防火墙放不放行

系统或云平台的过滤规则，决定包能不能到达那个端口

路由能不能到

调用方所在网络能否找到这台机器，跨网段、跨虚拟网络时最容易卡在这

鉴权有没有

这个服务默认不带认证，谁能连上谁就能调，跟前面三件事是独立的

什么情况下不该动这个开关：机器直接挂在公网、没有内网隔离、也没有反向代理做认证的时候，先别开。真要开，也得先想好一旦被扫到怎么关掉。判断标准很简单——如果这台机器能被不特定的人路由到，而你又没有前置的认证层，那就属于不该开的场景。

改哪个变量：OLLAMA_HOST 的正确写法

绑定地址和端口由同一个环境变量控制，格式是「地址:端口」。很多人只写端口，结果发现还是只有本机能连，就是因为没写地址部分。写全更稳，比如写成 0.0.0.0 加冒号再加端口。端口选一个不容易和别的服务撞的，改完要记住这个数字，后面所有排查都用得上。

# Linux / macOS 临时验证用（只对当前终端生效）
export OLLAMA_HOST=0.0.0.0:11434
ollama serve

# 检查当前进程实际监听的地址
ss -tlnp | grep 11434

写死内网 IP 更收敛，出了事影响面小；写 0.0.0.0 换网段不用再改配置，但开放面大。选哪个看你的机器是不是多网卡、是不是经常换网络环境。还有一个坑：环境变量只对「之后启动的进程」生效。你改了配置文件或者导出了变量，但旧进程还在跑，那配置等于没改。改完必须重启服务，这一步跳过的话后面所有排查都是白费。

Windows 上的落地步骤

Windows 上先分清 Ollama 是怎么起来的：是开机自启的服务，还是你手动点开的托盘程序。两种的生效方式不一样，搞错了会以为改了没用。托盘程序一般从环境变量读配置，改完要退出再重新打开；服务方式则要改服务本身的环境变量再重启服务。

1. 确认启动方式在任务管理器或服务列表里看 Ollama 是不是作为服务在跑；如果是托盘图标，右键退出后再重开才算重启
2. 设置变量把绑定地址和端口写进系统环境变量，地址部分写 0.0.0.0，改完注销或重开程序让它生效
3. 看端口有没有真的监听用系统自带的网络命令查看端口监听状态，确认绑定地址显示的是全部网卡而不是仅回环
4. 放行防火墙Windows 防火墙默认拦入站，需要为这个端口单独加一条入站规则，来源范围尽量限定到内网网段，不要图省事放成任意来源
5. 换机验证从同一内网的另一台机器去连，本机连本机永远通，证明不了任何事

Linux 与 systemd 服务下的落地步骤

Linux 上如果 Ollama 是 systemd 管理的服务，要改的是服务单元里的环境变量，不是你 shell 里临时 export 的那个。这两者经常被混为一谈：你在终端里导出了变量，然后 systemctl restart，服务读的还是它自己的单元配置，跟你终端里的无关。

1. 找到服务单元确认服务名，打开对应的单元文件，看它当前是通过环境变量文件还是直接在单元里写死配置
2. 写入绑定地址在正确的位置写入地址加端口的配置，地址写 0.0.0.0 或指定内网 IP，按上文的取舍决定
3. 重载并重启先让 systemd 重新读取单元配置，再重启服务。只重启不重载，新配置可能不生效
4. 核对监听状态用系统命令查看该端口被监听在哪个地址上，看到全部网卡才算成功，只看到回环说明配置没读到
5. 看日志确认翻一下服务日志，确认启动时读到的绑定地址是你写的那个，别只靠进程活着来判断

检查监听状态一定要用系统命令看绑定地址，不要只靠 curl 本机地址判断。本机地址在任何绑定方式下都是通的，这个验证没有区分度。如果你用的是容器部署，容器里的配置要在容器启动参数或编排文件里给，改宿主机环境变量对容器没用。

怎么验证「真的通了」：三段式排查顺序

验证要分三段走，跳段排查只会让你在错误的层面浪费时间。第一段在同机验证服务本身是否正常；第二段在同内网的另一台机器验证网络是否通；第三段才是远端应用接入。很多人第一步就用远端应用测，一失败就怀疑服务配置，其实问题可能只是调用方把地址写成了 localhost。

• 连不上先看监听地址对不对，这是最高频的原因
• 监听没问题再看防火墙，Windows 和 Linux 的规则位置不一样，云主机还有一层安全组
• 防火墙放行了再看路由，跨网段、跨虚拟网络时最容易卡这层
• 路由没问题最后看调用方填的地址，写成 localhost 是最典型的错误
• 容器场景单独注意：容器里的 localhost 指容器自己，不是宿主机

容器这块值得单独说。你在容器里跑服务，然后从宿主机去连，填 localhost 是连不上的，因为那是两个网络命名空间。要么用宿主机在容器网络里的地址，要么用编排里定义的网络别名。这个坑和监听配置无关，配对了也照样连不上，排查时别把两者混在一起。

客户端那边怎么填地址

服务端配好之后，客户端填什么地址是另一半。原则很简单：同一台机器用回环地址就行，跨机器必须填服务端的实际内网 IP 或主机名。主机名比 IP 更好维护，换机器不用改客户端配置，但前提是网络里能做名称解析，做不到就老老实实写 IP。

• 先确认调用端和服务端是不是同一台机器，这一步决定了后面所有填法
• 跨机器优先用主机名，前提是名称解析可用，否则退回 IP
• 容器里别用回环地址连宿主机，这是常见误配
• 改完客户端配置记得重启客户端进程，很多客户端启动时才读一次配置
• 把最终填的地址记下来，出问题时这是排查的第一手信息

对外开之前的安全收尾清单

这个服务本身不做出厂鉴权，开到内网等于同一网段谁都能调。这不是危言耸听，是它的设计定位——本地面向开发者的工具，默认假设你在受信任的环境里用。所以对外开之前，先想清楚这一点你接不接受，别等出事了才回头看。

• 开放范围：能限到某个内网网段就别放成任意来源，云主机还要看安全组那层
• 是否需要鉴权：要对外用就加一层反向代理做认证和访问控制，别裸奔
• 有没有日志：至少要知道谁在什么时候调过，出问题能追溯
• 怎么快速关掉：提前想好关服务或者撤规则的动作，别到时候现翻文档
• 谁来管：团队里指定一个人负责这项服务的对外状态，别多人各改各的

建议只在内网或虚拟专用网络里开放，公网入口一律走反向代理并加上认证与访问控制。如果你只是想在图省事的场景下临时用一下，用完就把监听改回回环地址，别长期开着。判断标准就是：如果这台机器明天被放到一个你不熟悉的网络里，现在的配置还安全吗？答案是否的话，就不该保持现状。

常见连不上的排查顺序表

连不上别凭感觉猜，按层往下走，每层给一个能直接做的验证动作。顺序是：服务是否在跑、监听地址对不对、防火墙是否放行、路由是否可达、调用地址是否写错。绝大多数问题在前两层就能定位，剩下的是网络环境差异。

1. 服务在不在跑看进程和端口有没有活跃，服务没起来后面都不用查
2. 监听地址对不对用系统命令看端口绑在哪个地址，只绑回环就是没改成功
3. 防火墙放没放行从同内网另一台机器测端口连通性，本机测没有意义
4. 路由通不通跨网段时确认两端能否互相找到，云主机还要看安全组规则
5. 调用地址写没写错最后回头看客户端填的是不是回环地址或者解析不了的主机名

什么情况下这套顺序不适用：托管在云主机上时，除了系统防火墙还有云平台的安全组，两层都要看，只查一层会得出错误结论。另外如果你的网络里有堡垒机或者跳板链路，还要确认链路本身是否允许该端口通过，这部分不在本机配置的排查范围内。