本地跑着 Ollama，自己电脑上一切都好，换台机器或者手机去连就报连接被拒——多半不是模型的问题，是它默认只肯听本机。这篇不聊模型选型，只讲怎么把服务地址和端口改对、改完怎么验、连不上时按什么顺序查，最后给一个能直接抄的配置清单。
本地跑着 Ollama，自己这台机器上网页能用、脚本也能通，换台笔记本或者拿手机去连就报连接被拒。多数人第一反应是模型或客户端出问题，其实大概率是 Ollama 默认只肯听本机回环地址——这是它的正常行为，不是坏了。
这篇只讲一件事：怎么把服务的侦听地址和端口改对，让同一局域网里的其他设备能调它，改完怎么逐层验证，连不上时按什么顺序排查。模型选型和调用参数这里不展开，最后给一份能直接照着做的配置清单。
先搞清默认只肯听谁
Ollama 启动后默认绑在本机回环地址上，所以同机的浏览器和脚本能连，隔壁那台机器一律连不上。这是预期行为，不是服务崩了，也不是防火墙突然抽风。要确认它当前到底绑在哪，最靠谱的是看启动日志里那行监听信息，比反复猜环境变量有没有生效快得多。
- 服务地址
- 决定「谁能来连」，只写回环地址就只有本机能连
- 端口
- 决定「从哪个门进」，服务和客户端两边必须写一致
- 完整调用地址
- 协议 + 主机 + 端口一个都不能少，只写个纯 IP 是最常见的低级错误
改侦听地址：让别的机器能进来
核心动作是把监听地址从回环改成全网卡，方式是在启动服务之前设置环境变量，改的是服务端行为，不是模型、也不是客户端。Linux 一般走系统服务的方式配置这一项，改完重启服务；macOS 用图形客户端的话要留个心眼，它和命令行启动读的可能不是同一份配置，很容易改了个寂寞。
- 先确认当前绑定打开启动日志确认当前监听地址，记下来作为回退依据。
- 设置监听地址在启动服务前设置环境变量，把监听地址指到全网卡；Linux 走服务配置，Windows 走系统环境变量面板。
- 重启服务让新配置真正生效。Windows 上设完环境变量只关终端窗口不算重启，要重开终端和客户端。
- 内网另一台机器验证用另一台设备的浏览器或 curl 去请求，能通说明这一层过了。
改全网卡意味着同一内网里任何人都能访问，团队内部共用没问题；但公用 Wi-Fi、开放办公网段就别这么干。真要对外提供服务，中间加一层反向代理和鉴权，别把裸接口直接挂公网。这条不算绝对禁令，只是判断标准：你的网段里如果有不受信任的设备，就不适用直接开全网卡。
改端口：换个数并避开冲突
端口被别的进程占着时，服务要么起不来，要么悄无声息退回原端口，表面看像配置没生效。动手前先确认你想要的端口是空的。改端口同样走环境变量或服务配置，地址和端口要一起设——只改一个，常见结果是「能连上但连错了别的服务」。
| 改动项 | 改在哪 | 容易漏的地方 |
|---|---|---|
| 监听地址 | 启动前的环境变量或系统服务配置 | 只改了图形客户端，没改命令行那套 |
| 端口 | 环境变量或服务配置 | 服务端改了，客户端还是旧端口 |
| 客户端地址 | 调用方配置或脚本 | 协议、主机、端口写不全 |
| 防火墙放行 | 系统防火墙或安全策略 | 服务改对了，端口没放行，看着跟没改一样 |
容器或虚拟机里跑的时候，端口映射和容器内部的监听端口是两层，两层都得对，只改一层会出现「宿主机连不上容器内服务」的典型症状。客户端那边填的必须是新端口，很多人只改了服务端忘了改调用方，然后回头怀疑服务配置没生效。
改完怎么验，连不上怎么查
验证顺序比验证本身更重要：本机自测 → 用本机 IP 自测 → 内网另一台机器测 → 应用侧测。每一步只引入一个新变量，出问题时能立刻定位卡在哪一层。跳着测往往查半天不知道是服务没起来还是网络不通。
- 连不上先分三类：服务根本没起来、防火墙拦了、地址端口填错了
- 按上面三类顺序排查，比反复重启服务快得多
- 防火墙和系统安全策略是内网访问失败的高频原因，服务改对了但端口没放行，表现和没改一模一样
- 过了网络这层再谈速度，想量化响应快慢，可以到 /tools/speed-test 先量出延迟基线，再判断慢是网络还是模型本身
一份能直接抄的清单
改之前先记下当前的地址和端口，方便回退；改完记得重启的是服务，不是只重启客户端。环境变量、服务配置、客户端地址、防火墙放行，这四件事全部做完才算真的改完。多人共用的机器，建议把这次改动写进部署文档，不然下一个人接手又是一轮从头排查。
- 改前记录原地址和端口，留好回退路径
- 监听地址指向全网卡，并确认当前网段可信任
- 端口换成空闲的，服务端和客户端同步改
- 防火墙放行新端口，容器场景两层映射都检查
- 用内网另一台设备做最终验证，不只看本机
部署形态差别大、或者你想先算清楚资源再动手，可以到 /models/deploy 看部署测算的口径；对监听、网卡、端口这些基础概念还拿不准，到 /ai-dict/category/infra 补一下术语。至于各家服务当下的具体规格和数字，站内页面会持续更新，以那里当时显示为准。判断标准比一次性记住某个数字有用得多——网段变了、部署方式换了，结论都得跟着重算。
下一步想先确认自己的网络和调用链路有没有隐患，可以从站内工具目录挑几个做连通与延迟自测；常用中转与官方入口的当前状态也建议顺手核一遍，省得把网络问题误当成服务问题。→常见问题
改完还是连不上，最先查什么？
先确认服务真的起来了，再看它实际绑在哪个地址上，最后查防火墙有没有放行那个端口。很多人卡在第一步之外，其实服务压根没重启成功，或者改的是终端环境变量而客户端走的是另一份配置。按「服务是否存活 → 实际监听地址 → 防火墙 → 客户端填的地址端口」这个顺序走，基本两三轮就能定位。
把监听地址改成全网卡安全吗？
同内网、自己可控的机器上没问题，等于把接口开放给同网段。但千万不要在公用 Wi-Fi、咖啡厅网络或者直接暴露到公网的环境这么干，裸接口没有鉴权，任何人扫到都能调你的模型、看你的对话。要对外用就套一层反向代理，加访问控制和鉴权，再考虑暴露。
改了端口为什么模型列表还在原来的地方？
多半是服务端改了、客户端没改。服务端换端口后，所有调用方——浏览器页面、SDK、别的工具——都得把新的地址端口填进去，否则它们还在敲旧端口，表现就是连不上或者连到另一个服务。另外容器场景里还有一层端口映射，容器内监听和宿主机映射是两回事，两层都要对上。
