Ollama 在 Windows 上部署本地大模型后默认只监听 127.0.0.1:11434也就是只有本机能访问。这个默认行为带来的问题很直接你在这台电脑上把模型跑起来了同一个办公室的另一台电脑想通过接口或网页调用它却发现始终连不上。这篇文章就把 Ollama 局域网访问的完整链路拆开讲覆盖 Windows 部署、环境变量修改、防火墙放行、内网调用方式和常见排查。适合已经在用 Ollama、或者正准备在 Windows 上部署本地大模型、需要把模型能力共享给局域网内其他机器的人。最值得先搞清楚的是局域网访问能不能通关键不在模型效果而在三个环节——服务监听地址、Windows 防火墙规则、客户端请求的 IP 和模型名。这三个环节对齐了剩下的就是调用方式的差别。1. 先弄明白 Ollama 局域网访问到底要解决什么问题1.1 默认情况下为什么其他机器连不上Ollama 本质上是一个本地 HTTP 服务启动后默认绑定的地址是 127.0.0.1也就是 loopback 回环地址。这个地址的含义是“只接受来自本机的连接”。所以不管防火墙放不放行、不管局域网 IP 填得多正确只要监听地址还是 127.0.0.1其他机器发过来的请求都会被系统直接拒绝。很多人第一次遇到“本机正常、局域网连不上”时第一反应是去查防火墙或者检查网线、Wi-Fi 信号。其实最优先要确认的是 Ollama 服务到底监听在哪个地址上。判断方法很简单在 Windows 的命令行里执行netstat -ano | findstr 11434如果结果里看到127.0.0.1:11434说明服务仍然只监听本机如果看到0.0.0.0:11434或者具体的局域网 IP才说明监听地址已经对外开放。这一步是整个局域网访问问题的分水岭。1.2 局域网访问的完整链路拆开来看一次从局域网其他机器发起的大模型请求要经过这样一条链路客户端知道服务端的局域网 IP比如192.168.1.100。客户端向192.168.1.100:11434发起 HTTP 请求。请求到达服务端 Windows 系统后先经过 Windows 防火墙的入站规则检查。防火墙放行后请求到达 Ollama 服务。Ollama 根据请求里的模型名加载或调用对应模型生成结果并返回。因此这条链路中任何一环出问题调用都会失败。常见情况无非四类客户端 IP 写错、监听地址没改、防火墙没放行、模型名不匹配。后面的排查过程也基本按这个顺序走。理解这条链路还有一个好处你不会再把问题简单归因于“模型太大”或“Ollama 不行”而是能快速判断到底是网络层、系统层还是应用层的问题。2. Windows 环境部署 Ollama 的前置准备2.1 安装、启动和基础验证在 Windows 上部署 Ollama 的第一步是下载 Windows 安装包。安装过程比较常规一路下一步即可。装上之后Ollama 会作为后台服务运行系统托盘里能看到对应图标。安装完成后先打开 PowerShell 或 CMD执行ollama --version能正常输出版本号说明安装成功。再执行ollama list查看本地已有模型。刚开始一般是空列表因为模型需要单独拉取。这一步不要跳过它能帮你确认命令行路径和用户权限是否正常。这里有个很常见的体验问题在某些网络环境下Ollama 安装包或模型文件下载速度很慢甚至一直卡住。遇到这种情况不要反复点下载也不要连续重试同一个动作。可以先检查网络是否稳定、磁盘空间是否充足再考虑使用国内可访问的镜像站点来下载安装包。模型拉取慢时还可以先把模型存储目录切到空间更充足的盘再重新执行拉取。2.2 拉取模型前先想清楚硬件条件Ollama 支持 CPU 和 GPU 两种运行方式。Windows 上如果机器有 NVIDIA 显卡Ollama 会优先调用 GPU 推理没有显卡或者显存不足时会退回 CPU 推理。GPU 推理速度快CPU 推理也能跑但速度会明显慢尤其是大一点的模型。选模型的通用原则是先看自己的显存和内存大小。同一系列模型通常会有不同参数规模版本比如 1.5B、7B、14B、32B 这些档位。参数规模越大占用显存和内存越多单次生成耗时也可能更长。具体有哪些标签以 Ollama 官方模型库为准不要只看模型名字就盲目拉取。第一次尝试我建议先拉一个参数规模较小的模型把链路跑通再考虑更大的。比如ollama pull deepseek-r1:1.5b拉取完成后直接用ollama run deepseek-r1:1.5b进入交互界面随便输入一句中文测试能正常回复就说明模型本身可用。如果你打算多个场景共用也建议先固定一个模型做验证不要在初期同时拉好几个大模型否则后面排查时很难分清延迟和报错到底来自哪个模型。2.3 跑通之前不要急着改局域网配置很多人喜欢先把局域网访问配置好再拉模型。我建议反过来先在本地把模型跑通再改OLLAMA_HOST和防火墙。原因很简单本地跑通意味着安装、模型文件、依赖、权限都没有问题。如果本地都跑不通就急着开放局域网出了问题后既有可能是模型问题也有可能是网络问题排查范围会扩大一倍。这一步的验证标准也很明确本地能通过ollama run正常对话并且执行curl http://127.0.0.1:11434/api/version能返回版本信息。达到这个状态再进入局域网开放阶段。3. 修改环境变量让 Ollama 监听局域网地址3.1 设置 OLLAMA_HOST 的正确步骤Ollama 通过环境变量OLLAMA_HOST控制监听地址。改成0.0.0.0表示监听所有网络接口这是最省事的做法。Windows 上的操作路径按Win键搜索“编辑系统环境变量”打开“环境变量”窗口。在“用户变量”或“系统变量”区域点击“新建”。变量名填OLLAMA_HOST变量值填0.0.0.0。点确定保存。完全退出 Ollama再从开始菜单或桌面快捷方式重新启动。重新执行netstat -ano | findstr 11434确认监听地址已经变成0.0.0.0:11434。设置成0.0.0.0的好处是不管这台机器之后 IP 怎么变只要网卡存在服务都会在所有网卡上监听。如果你希望更严格也可以填具体的局域网 IP比如192.168.1.100这样服务只监听这个地址不在其他网卡上暴露。3.2 修改后不生效的常见原因环境变量修改后不生效绝大多数情况是“没有彻底重启 Ollama”。在 Windows 上只关闭命令行窗口或者只关掉托盘菜单里的进程是不够的因为 Ollama 可能仍然在后台以服务形式运行。最稳妥的办法是在托盘图标上右键选择退出。打开任务管理器在进程里找ollama.exe如果还在手动结束进程。重新启动 Ollama。再用netstat确认监听地址。另外一个容易忽略的点是环境变量分为用户变量和系统变量。如果你当前登录的用户不是管理员系统变量的修改可能不会立刻反映到当前会话里。我实际测试时一般直接在用户变量里设置OLLAMA_HOST效果一样而且不用反复提升权限。关键是不要两边设置成不一样的值否则容易造成混乱。3.3 防火墙放行 11434 端口监听地址改完之后还要确认 Windows 防火墙允许入站连接访问 11434 端口。这一步不做局域网其他机器的请求会被系统拦截表现出来就是“能 ping 通但端口连不上”。图形界面操作方式打开“Windows Defender 防火墙”。点击“高级设置”。在左侧选择“入站规则”。点击“新建规则”类型选“端口”。协议选 TCP特定本地端口填11434。操作选“允许连接”。配置文件可以全选或者至少包含当前网络使用的配置文件。命名规则保存完成。如果想用命令行快速添加可以在管理员权限的 PowerShell 里执行netsh advfirewall firewall add rule nameOllama LAN dirin actionallow protocolTCP localport11434注意如果当前 Windows 网络配置文件是“公用网络”部分情况下放行规则不会生效。建议把局域网环境设置为“专用网络”再检查防火墙规则。4. 内网其他机器如何调用 Ollama4.1 先确认服务端 IP 和连通性在服务端打开 PowerShell执行ipconfig找到当前网卡对应的 IPv4 地址比如192.168.1.100。然后在客户端机器上先做两层验证ping 192.168.1.100Test-NetConnection 192.168.1.100 -Port 11434如果TcpTestSucceeded返回True说明网络链路和端口都通了。这一步很值得做因为它把问题范围直接缩小到“网络通不通”和“服务是否正常”两个层面。如果 ping 不通优先查网段、网关和 IP 是否填写正确如果 ping 通但端口连不上优先查防火墙和监听地址。4.2 通过 Ollama 原生 API 调用Ollama 自带 HTTP API常用的有/api/generate和/api/chat。前者适合一次性文本生成后者适合多轮对话。在客户端机器上用 curl 测试curl http://192.168.1.100:11434/api/generate -d {\model\: \deepseek-r1:1.5b\, \prompt\: \你好请简单介绍一下自己\, \stream\: false}返回结果里会包含response字段里面是模型生成的内容。注意这里的model名称必须和服务器上ollama list显示的完全一致少了版本标签或者名字写错都会返回model not found。在 Windows CMD 里执行 curl 时要注意 JSON 引号转义如果觉得麻烦可以换成 PowerShell 或直接用 Python 脚本测试。用 Python 调用/api/chat的示例import requests url http://192.168.1.100:11434/api/chat payload { model: deepseek-r1:1.5b, messages: [ {role: user, content: 你好请用一句话介绍你自己} ], stream: False } resp requests.post(url, jsonpayload, timeout120) data resp.json() print(data[message][content])4.3 使用 OpenAI 兼容接口接入现有项目Ollama 还提供了 OpenAI 兼容接口地址是http://192.168.1.100:11434/v1这意味着原本使用 OpenAI SDK 的项目只需要把base_url改成这个地址再把 API Key 随便填一个占位值就能把请求转发到本地模型上。对于已经写了大量调用代码的团队来说这是成本最低的接入方式。新增项目时也可以直接按 OpenAI 接口规范来写之后想切换其他兼容服务只需要改配置不用改代码。from openai import OpenAI client OpenAI( base_urlhttp://192.168.1.100:11434/v1, api_keyollama, ) resp client.chat.completions.create( modeldeepseek-r1:1.5b, messages[{role: user, content: 你好}], ) print(resp.choices[0].message.content)4.4 想给非技术人员提供访问入口可以加一个 Web 界面如果局域网内有人不会写代码只想要一个类似聊天软件的页面可以在同一台 Windows 机器或者其他机器上部署一个 Web 界面让它连接 Ollama 的 API。常见方案是 Open WebUI 这类项目它需要以容器方式运行。对 Windows 用户来说先装好容器环境再拉取镜像启动即可接入时把 Ollama 的地址填成局域网地址。这个方案多了一层依赖初次搭建会比直接用 API 复杂但对团队协作和日常使用更友好。它适合场景稳定、人数不多、需要长期使用的环境如果只是临时测试直接用 API 就够了没必要多维护一套服务。5. 资源占用、并发和批量调用注意事项5.1 多人同时调用时最先被消耗的是显存和内存局域网开放之后可能有多台机器同时发起请求。这时最先暴露出来的不是代码问题而是硬件资源压力。Ollama 默认会缓存已加载的模型如果显存不足模型可能被换入换出导致响应延迟明显上升甚至出现请求超时。在服务端执行ollama ps可以看到当前有哪些模型正在运行、占用的显存和内存大小。如果发现同时加载了多个大模型可以通过环境变量OLLAMA_MAX_LOADED_MODELS限制同时加载的模型数量通过OLLAMA_NUM_PARALLEL控制每个模型并行处理请求的数量。注意这些参数都是环境变量修改方式和OLLAMA_HOST一样改完必须重启 Ollama 才生效。5.2 判断批量任务能不能扛住不能只看单条响应速度单条请求快不等于并发批量请求也快。常见做法是先用一条请求验证功能和输出格式再逐步增加并发数。如果只是学习测试默认参数通常够用如果要给团队或业务使用就要重点关注这几个指标单次请求耗时决定交互体验。并发请求数同时有多少个客户端在调用。吞吐量单位时间内能完成多少请求。失败率和超时次数并发上去之后是否频繁报错。服务端资源占用显存、内存、CPU、磁盘读写是否稳定。不要一上来就开最大并发。我见过不少项目模型本身没问题结果多人同时调用后进程卡死或响应超时最后查下来都是并发压力超过了硬件承受范围。从小并发慢慢往上加是最稳的测试方式。5.3 模型存储目录和日志处理默认情况下Ollama 模型文件存放在当前用户目录下的.ollama\models文件夹里。如果你下载的模型比较大C 盘空间又紧张可以通过环境变量OLLAMA_MODELS把模型存储目录改到其他盘。改完之后原来的模型文件不会自动迁移需要手动复制或重新拉取。日志方面Ollama 在 Windows 上以服务形式运行时日志一般不容易直接看到。排查问题时可以先在 PowerShell 里执行ollama serve保持前台运行这样标准输出会直接打印到终端方便观察请求日志和错误信息。不过这样操作前要确保默认的后台服务已停止否则会端口冲突。6. 常见问题排查清单6.1 按现象定位问题优先级下面这张表是我在实测中经常参考的排查顺序从最可能的原因开始现象优先检查处理方式本机能访问其他机器连不上监听地址是否还是 127.0.0.1修改OLLAMA_HOST0.0.0.0并彻底重启 Ollamaping 通端口连不上Windows 防火墙入站规则放行 TCP 11434确认网络配置文件不是“公用”请求返回 404、model not found模型名不匹配在服务端执行ollama list获取准确模型名请求超时或响应很慢显存、内存、模型规模换小模型或限制并发观察ollama ps拉模型时一直卡住或失败网络、磁盘空间、存储路径检查磁盘空间更换网络使用可用镜像源设置了 OLLAMA_HOST 却不生效环境变量类型、服务未彻底重启用户变量或系统变量二选一统一设置结束后台 ollama 进程客户端能连上但输出乱码终端编码和输出格式检查终端编码、请求是否开启 stream、输入文本编码6.2 几个容易误判的细节第一个容易被误判的是“改了OLLAMA_HOST但 netstat 没变化”。这种情况先别急着怀疑环境变量先确认后台是否真的退出。Windows 上 Ollama 可能同时存在托盘进程和后台服务进程任务管理器里把ollama.exe全部结束再重启最可靠。第二个容易误判的是“客户端换了网络就连不上”。如果服务端和客户端分别在两个不同的网段或者中间隔着路由器的 AP 隔离即使 IP 填对了端口也可能不通。排查时先确认两台机器是否真的在同一个网络域里最简单的方式就是互相 ping 一下。第三个容易被忽略的是安全问题。开放0.0.0.0监听意味着同一个网段内所有机器都能访问你的模型如果这台机器还暴露在更广的网络里就可能被非预期的人调用。内部测试问题不大但如果要长期提供服务建议在防火墙规则里限制允许访问的 IP 范围只放行指定客户端而不是对所有来源放行。6.3 一次完整的排障顺序当你遇到“局域网调用失败”时可以按这个顺序走一遍在服务端执行netstat -ano | findstr 11434确认监听地址是0.0.0.0:11434。在服务端本机执行curl http://127.0.0.1:11434/api/version确认服务本身正常。在客户端执行ping 服务端IP确认网络连通。在客户端执行Test-NetConnection 服务端IP -Port 11434确认端口通。用一条最小请求curl http://服务端IP:11434/api/generate确认 API 能返回。如果第 4 步失败回服务端检查防火墙入站规则和网络配置文件类型。如果第 5 步报模型不存在回服务端执行ollama list确认模型名。实际踩过几次之后会发现多数局域网访问问题不是 Ollama 本身有 bug而是监听地址、防火墙规则和模型名这三件事没有对齐。先把这三件事逐个确认再往并发、资源、Web 界面这些方向扩展就能少走很多弯路。我个人更建议把整个流程分成三个阶段本地跑通、单机开放、局域网调用。每个阶段都验证通过之后再考虑多人并发和界面化部署。这样即使出了问题也能很快定位到具体环节。