在本机跑 Ollama 很顺，一到同事那台机器或另一台服务器上调用就懵了：到底该填 127.0.0.1、局域网 IP，还是 0.0.0.0？填错了只会看到连接被拒绝，看不出是地址错还是防火墙挡。这篇按系统把确认监听地址的动作拆成可照做的步骤，并说清哪些情况要改绑定、哪些情况改完反而更麻烦。
在本机跑 Ollama 很顺，一到同事那台机器或另一台服务器上调用就懵了：到底该填 127.0.0.1、局域网 IP，还是 0.0.0.0？填错了只会看到连接被拒绝，看不出是地址错还是防火墙挡。这篇按系统把确认监听地址的动作拆成可照做的步骤，并说清哪些情况要改绑定、哪些情况改完反而更麻烦。
先记住一句话：不要猜地址，去服务那台机器上把「实际监听」查出来。查出来的那串 IP 加端口才是跨机要填的值，其他都是推出来的。下面按 Windows、Linux/macOS、跨机排查、拿到地址之后四段讲，每段都给出可照做的动作和判断标准。
先分清三种「地址」，填错才报错
常见错误是把「服务监听的绑定值」直接当客户端要填的目标地址。绑定地址决定服务听哪张网卡，访问地址决定你从哪台机器发起，两者经常不是一个东西。分不清这两层，就会在客户端反复改配置，改到怀疑服务坏了，其实服务根本没听在那张网卡上。
| 你看到的地址 | 含义 | 能不能填进客户端 |
|---|---|---|
| 127.0.0.1 或 localhost | 只监听本机回环，外部机器连不进来 | 只能在本机调用时填 |
| 0.0.0.0 | 监听全部网卡，对所有网卡开放 | 不能填，它只是绑定值 |
| 具体局域网 IP | 服务听在这张网卡上 | 跨机调用就填这个 |
先分清默认端口这件事
- 默认端口是统一的，客户端和服务端填的端口不一致，照样连不上，先确认两边是同一个端口
- 端口能在启动参数或环境变量里改，改成什么就得跟着填什么，别默认它还是原来的值
- 地址对但端口错，报错形态和地址错很像，排查时把两个变量分开验证，一次只改一个
Windows：查监听与试本地连通
Windows 上最直接的思路是两步：先看端口监听在哪个本地地址上，再用本机地址自测一次接口活没活。两步都通了，问题就只在跨机那段路上，不用回头折腾服务本身。
- 查监听地址用 netstat 一类命令看目标端口处于监听状态时绑定的本地地址。出现 0.0.0.0 说明对外网卡都开着，出现 127.0.0.1 说明只有本机能连。具体命令写法到站内资料库对照，注意过滤出监听状态那一行
- 本机自测在同一台机器上用本机地址请求一次接口，能正常返回说明服务是活的，这一步不通就别急着跨机排查
- 确认跨机要填的值在服务机上查它自己的局域网 IP，把这个 IP 加端口作为客户端要填的目标地址，不要填服务配置里的绑定值
- 注意重启后变化服务随桌面程序启动时，重启或切换网络后监听地址可能变，重新查一遍比猜快，尤其是笔记本换了 Wi-Fi 之后
Linux 与 macOS：按进程查真正生效的值
Linux 和 macOS 上要养成一个习惯：配置文件和实际值不一致时，以实际监听为准。环境变量会覆盖默认绑定，所以先看进程是怎么起来的，再看它实际听在哪，最后才回头去看配置。
- 先看服务进程的启动参数，确认有没有绑定地址相关的参数
- 再看进程实际监听在哪个地址和端口，以这一项为准
- 查当前会话里有没有设过相关环境变量，它会覆盖默认绑定
- macOS 上额外确认是否开了只允许本机访问的开关，形态和 Linux 不一样
- 每次改动后重新确认一遍监听地址，别改完就当已经生效
改绑定前先想清楚的一件事
把服务监听到对外网卡上，意味着同一个网络里的其他设备也能连上你的模型。如果能用的人数可控、网络可信，那就没问题；如果是开放网络或你不确定谁在这个网段里，不开就是更省事的选择。权限相关的口径可以到站内安全入口核对，别为了图方便把不该开的口子开着。
跨机调用还卡着，按这个顺序排
跨机连不上，先别改服务配置。按固定顺序走一遍，能快速定位卡在哪一层：是绑定没生效，还是网络层被挡了。顺序错了会在客户端反复试，浪费时间还容易改乱配置。
- 确认服务端监听在对外网卡上回到服务机查监听地址，是 0.0.0.0 或具体局域网 IP 才算对外，仍是 127.0.0.1 就先改绑定，后面的步骤先别做
- 在服务机上用自身局域网 IP 调一次这一步验证绑定是否真的生效。不通说明绑定没起作用，回到上一节改；通了说明服务侧没问题
- 换到客户端机器用同样地址调一次第二步通、这一步不通，问题基本在网络层：网段、防火墙、安全组、容器网络，逐项放行，不要一上来就改服务配置
- 第二步就不通怎么办说明绑定根本没生效，回到上一节把绑定改对，别在客户端那边瞎试
拿到地址之后顺手做的两件事
地址能通只是第一关，模型名、并发、超时这些参数各自还会单独报错。但先把地址这件事固化下来，能省掉以后每个人重新排查一遍的成本。
- 先记下可用的基准延迟，之后换网络、换机器、换模型时拿它对比，慢是网络问题还是推理问题一眼能分
- 多人共用时把地址、端口、绑定方式写成一行贴在团队文档里，省得每个人重新排查
- 地址能通不等于配置正确，模型名、并发、超时这些参数各自还会单独报错，地址只是第一关
- 如果迟迟调不通，可以把地址和端口交给对方复现，比只描述「连不上」有用得多
| 现象 | 最可能卡在哪 | 下一个动作 |
|---|---|---|
| 本机自测都不通 | 服务没起或端口不对 | 回到服务机查进程和监听 |
| 本机通、同网段不通 | 绑定没生效 | 改绑定到对外网卡后复测 |
| 同网段通、跨网段不通 | 防火墙或安全组 | 逐项放行，别动服务配置 |
| 能连上但响应慢 | 网络或推理本身 | 先量基准延迟再对比 |
常见问题
Ollama 默认的地址是哪个，我直接填 127.0.0.1 为什么别人连不上？
127.0.0.1 是回环地址，只代表服务所在那台机器自己，别的机器填这个等于让它连自己。跨机调用必须填服务机在局域网里的实际 IP，并且要让服务监听在对外网卡上，两件事缺一不可。
看到 0.0.0.0 是不是就可以直接拿它当接口地址用了？
不行。0.0.0.0 表达的是「监听所有网卡」这个状态，不是目的地。它只是告诉你服务已经对外开放，真正调用时仍然要写服务机的具体 IP。把 0.0.0.0 填进客户端地址栏是很常见的误区。
改成对外开放后还是连不上，最可能是哪一步？
先确认服务进程真的重新加载了新绑定，可以在服务机上用自身局域网 IP 调一次；如果这一层通、从别的机器不通，问题就在网络层，按网段、防火墙、安全组、容器网络逐项排查，不用再动服务配置。
