装完 Ollama 用命令行聊天没问题，一换成代码里的 requests 或 SDK 就懵了：地址填什么？端口是哪个？为什么 localhost 能通、局域网另一台机器就不行？这篇按「默认地址 → 改端口 → 调用示例 → 排查顺序」走一遍，给的是判断方法和可执行动作，具体端口数值以你本机实际配置为准。
装完 Ollama 用命令行聊天挺顺，一换成代码里的 requests 或 SDK 就懵了：地址到底填什么？端口是哪个？为什么本机 localhost 能通，换到局域网另一台机器就不行？这几个问题几乎每个刚接本地推理服务的人都会撞一遍。
这篇按「默认地址 → 改端口和监听范围 → 调用示例 → 连不上的排查顺序」走一遍。给的是判断方法和能直接做的动作，具体端口数值、模型名以你本机实际配置和当时拉到的模型为准，别照抄别人博客里的数字。
默认地址长什么样：从命令能通到代码能调
Ollama 起服务后会监听在本机的一个 HTTP 端口上。命令行工具之所以不用你填地址，是因为它内置了默认值，直接连本机那个端口。写代码时你得显式把这个根地址拼进请求里，否则 requests 不知道往哪儿发。
这里最容易踩的坑是混淆两层东西：服务根地址（只有协议、主机、端口，比如 http://主机:端口）和具体接口路径（生成、对话、模型列表、OpenAI 兼容那一组）。根地址后面接错路径，返回的往往就是 404。先分清这两层，再去拼 URL。
- 服务根地址
- 协议+主机+端口，不含任何接口路径，是拼所有请求的底座
- 接口路径
- 挂在根地址后面的具体端点，决定你调的是生成、对话还是模型列表
- 回环地址
- 只允许本机访问的地址，默认监听它意味着外网和其他机器都连不上
动手前先确认服务真的活着：用命令行列一下本地已有模型，能列出来说明服务在跑，这时候再去纠结地址才有意义。列不出来就是服务没起，后面怎么改地址都白搭。怕把框架名、引擎名当成地址，可以先去站内 /ai-dict 把「推理服务」「端口」这类词对一遍，概念对齐了再动手。
改端口、放开局域网：什么时候要动，怎么动
默认只绑本机回环地址，这是为了安全——别人扫不到你的服务。只有当你确实需要另一台机器、或者容器里的应用来调它，才需要考虑把监听范围放开到局域网或全部网卡。不是必须就别放，放开的每一步都要想清楚谁能访问到。
- 改监听地址和端口通过启动参数或环境变量指定新的监听主机和端口，改完必须重启服务才生效，光改配置不重启等于没改。
- 容器场景加一步容器里跑的 Ollama 还要确认端口有没有映射到宿主机，容器内能通不代表宿主机能通，这是两个网络命名空间的差别。
- 验证监听是否真的放开在另一台机器上用同样的根地址发一个最小请求，能返回才算放开成功，不要只看配置文件写没写。
不适用的情况也要说清：机器直接暴露在公网、或者公司网络明令禁止开放端口时，不要为了图方便把监听绑到全部网卡。正确做法是走反向代理、加访问控制，或者干脆只在内网用。开发机上怎么方便怎么来，生产环境这条线不能越。
调用示例该写什么：三种常见接法
调用方式按你已有的代码栈来选，不用三种都学。核心区别只有两个：路径长什么样、请求体里的字段叫什么，把这两点对上就能跑通。
| 接法 | 根地址怎么填 | 适合什么情况 |
|---|---|---|
| 原生接口 | 根地址 + 原生路径 | 想用完整原生能力、不介意对接一套新请求体 |
| OpenAI 兼容接口 | 根地址 + 兼容路径 | 已有 OpenAI SDK 代码，想少改代码直接迁移 |
| 第三方客户端库 | 通常配置根地址即可 | 只想快速验证，不在意底层细节 |
原生接口的请求体里带模型名和提示内容，返回可能是流式的分块，也可能是一次性 JSON。新手建议先跑通最小请求——只给模型名和一句提示，别一上来就把温度、上下文长度、系统提示全加上，出错时根本不知道是哪一项的锅。
- OpenAI 兼容那一组接口最省事：把根地址指过去、随便填一个占位密钥，就能复用现成代码，迁移成本最低
- 不管用哪种，先用命令行或 curl 复现一遍最小请求，能区分是客户端库的问题还是地址的问题
- 换模型只改请求体里的模型名字段；换接口风格才改路径和请求体结构，两者混改最容易定位不到错
- 第三方库出问题时，优先回退到 curl 验证，能跑通就是库的配置问题，跑不通就是地址或服务问题
想量一下本地响应到底算快还是慢，可以先到站内 /tools/speed-test 跑一条基线，再拿它跟本地响应时间对比。注意本地推理受机器配置、模型大小、是否首次加载影响很大，基线只能当参考，别拿它当硬指标。
连不上时的排查顺序：从近到远四步
连不上别乱试，按从近到远的顺序走一遍，基本能定位到问题在哪一层。跳步排查是最浪费时间的。
- 第一步：看服务状态进程在不在、用命令行能不能列出模型。列不出来就是服务没起或模型没拉，先解决这一层。
- 第二步：看地址本身协议、主机、端口有没有多写斜杠、少写端口，或者复制粘贴时带上隐藏字符。把地址单独打出来看一眼。
- 第三步：看网络路径本机能通外部不通，就查监听地址、防火墙规则、容器端口映射这三处，按顺序排除。
- 第四步：看应用层返回 404 多半是路径拼错，返回超时多半是模型正在加载或请求把机器占满了，这时候等一等或换小模型试。
这套顺序的价值在于：每走一步都能明确排除掉一整类原因，而不是靠猜。如果你连服务是不是正常都判断不了，问题的根其实不在地址，而在对服务状态没底。
地址填错只会报 404 或连不上，服务没起才是那个让你查半天地址也查不出来的真凶。下一步想横向比较不同本地推理方案在部署难度和调用方式上的差别，可以去站内模型资料库对一遍术语，或者到工具目录看看别人常用的客户端和调试工具，省得每个坑都自己踩。→
常见问题
为什么浏览器打开这个地址显示一堆报错，是不是没装好？
不一定。服务根地址本身不提供网页界面，直接访问看到报错或空白是正常的，它主要是给程序调用的。要确认装没装好，用命令行列一下本地模型列表更直接；真要图形界面，得另配客户端或界面工具。
地址在本机能调，同事那台机器调不通怎么办？
按顺序排除三件事：服务是不是只绑了本机回环地址；防火墙有没有放行这个端口；如果是容器跑的，端口有没有映射到宿主机。这三处任意一个没处理，外部都连不上，跟模型本身没关系。
换了端口之后老代码全报错，是不是要重装？
不用重装。端口是配置项，改了之后所有写死旧端口的调用方都要跟着改，包括环境变量、配置文件、客户端初始化那几行。建议把根地址抽成一个环境变量统一维护，以后换机器换端口只改一处。
