Windows局域网部署Ollama完整指南：从本机到内网访问

实际部署 Ollama 时很多人都会撞上同一个问题本机访问一切正常可一旦要让局域网里的其他机器调用立刻卡住。同事顺手敲了一个curl http://192.168.1.100:11434/api/tags等了几秒然后告诉你“连接不上”。你回头在自己电脑上跑curl http://localhost:11434/api/tags一切照常。于是开始怀疑是不是系统、驱动、模型的问题。这个场景我在很多 Windows 本地部署项目里反复看到。真正的问题是Ollama 在 Windows 上默认只监听127.0.0.1也就是“只服务本机”。局域网访问不是一个开关也不是改一个参数就完了它需要三层配合服务监听所有网卡、防火墙放行端口、调用方使用正确地址和 API 路径。任何一个环节断了都会表现为“本机能用别人连不上”。这篇文章我会按一套完整的实操流程讲清楚在 Windows 上把 Ollama 部署成本地模型服务、并让内网其他机器调用时需要做的事同时把那些最容易导致失败的环境细节、排查顺序和边界也说清楚。1. 先搞清楚 Ollama 默认是怎么监听网络的1.1 默认绑定 127.0.0.1是“单机可用”最直接的假象Ollama 安装完成后默认会把 HTTP 服务绑定到127.0.0.1:11434。这个地址是回环地址只有你本机上的程序可以访问。它带来一个很典型的“假象”你打开浏览器访问http://localhost:11434看到模型运行正常你用本机命令测 API响应正常你觉得服务已经跑起来了。但这个服务对网卡上其他 IP 没有任何监听。你局域网里的同事访问你的 IP:11434数据包根本不会到达 Ollama 进程。它并不是被拒绝而是没有服务在监听。在 Windows 上尤其容易误解这一点因为很多程序装完就直接监听0.0.0.0或::用户不需要关心绑定地址。而 Ollama 选择了保守策略默认只服务本机避免一安装就把模型服务暴露到网络。这个设计对单人学习很友好但对“要在内网共享模型”的场景就多了一个需要主动改掉的环境变量。1.2 局域网访问至少要做三件事而不是一两个步骤我把局域网访问拆成三层每次排查都按这个顺序来监听地址Ollama 必须监听0.0.0.0:11434而不是127.0.0.1:11434。防火墙Windows 防火墙要允许外部设备访问 TCP 11434 端口。调用方另一台机器必须使用正确的内网 IP 和 API 路径而不是 localhost。这三件事是“与”的关系任何一个不满足结果就是连接失败。第一件事由环境变量控制第二件事是 Windows 网络策略第三件事体现为调用代码或命令的写法。很多人卡在第一步就误以为“配置过环境变量但没用”实际上可能是第二步防火墙没放行。也有人改了防火墙但忘了重启 Ollama 服务导致监听地址还是旧的。所以一定要把这三件分开验证而不是合在一起猜。1.3 服务方式和命令行方式对配置生效有不同影响Windows 上 Ollama 的常见运行方式有两种安装后作为后台应用/服务常驻或者你手动开一个终端执行ollama serve。区别在于环境变量读取时机。如果你通过“设置 - 系统 - 高级系统设置 - 环境变量”添加了OLLAMA_HOST并希望后台常驻的 Ollama 使用它必须重启 Ollama通常是右键托盘图标退出再重新启动。如果是通过setx命令设置新开的终端才会读到已开着的终端不会自动更新。如果手动在终端里启动则可以用临时环境变量方式比如 PowerShell 里的$env:OLLAMA_HOST 0.0.0.0:11434再执行ollama serve这种模式适合调试但不适合长期服务。这就解释了一个很常见的现象明明把变量加到了系统环境变量里Ollama 却还是只听127.0.0.1。原因就是进程启动时没有拿到新的配置。2. Windows 上从安装到能被局域网访问的完整流程2.1 先装好并确认 Ollama 在单机环境可用不管是要做局域网共享还是只是自己玩第一步都是把 Ollama 装好并先把单机跑通。下载安装包后一步步安装。装完打开一个终端先确认基本命令ollama list如果提示没有模型就拉一个适合 Windows 本地部署的模型下来。比如ollama run qwen2.5:7b第一次运行会先下载后面再启动就快了。拉取成功后在另一个终端里检查 API 是否正常curl http://localhost:11434/api/tags能返回一个带models字段的 JSON就说明 Ollama 的 HTTP 服务在本机正常。这里不建议还没验证单机就急着改局域网配置。先确定“服务本身没问题”后面排错范围会小很多。2.2 修改 OLLAMA_HOST让服务监听所有网卡让 Ollama 接受局域网访问的核心是环境变量OLLAMA_HOST。常见设置方法是setx OLLAMA_HOST 0.0.0.0:11434执行完之后重启 Ollama。重启后再看一下现状ollama list看不到监听地址所以要用另一个方式确认。可以用netstat -ano | findstr 11434查看进程是否监听在0.0.0.0:11434。如果是127.0.0.1:11434说明配置没生效或者还没重启。也可以用临时变量方式做快速验证$env:OLLAMA_HOST 0.0.0.0:11434 ollama serve这种方式适合调试但关闭终端后服务会停。对长期部署更推荐把setx和固定 IP 的机器配合使用。注意setx只会影响新开的终端当前已经打开的 PowerShell 窗口并不会自动拿到新值。如果你刚执行完setx就让同一个窗口去启动 Ollama很可能会踩空。最好新开终端再启动或者重启 Ollama。2.3 Windows 防火墙放行 11434 端口服务监听之后下一步是防火墙。很多情况下局域网连不上不是因为 Ollama 没监听而是 Windows 防火墙默认拦掉了外部入站连接。如果只需要放行 TCP 11434可以右键开始菜单选择“Windows 终端(管理员)”执行netsh advfirewall firewall add rule nameOllama LAN dirin actionallow protocolTCP localport11434 profileprivate,domain这里把规则限制在private,domain也就是内网、家庭或办公网络环境。不建议在public上下文放行因为公共网络通常是不可信环境。如果不喜欢命令行也可以在“Windows 安全中心 - 防火墙和网络保护 - 高级设置 - 入站规则”里新建规则选择“端口”协议选 TCP端口填 11434操作选“允许连接”应用范围按你的实际网络类型选择。要注意的是如果 Ollama 所在电脑连接的网络被 Windows 识别成“公用网络”而你又在规则里只允许“专用”仍然会被拦住。2.4 内网其他机器上的最终验证配置完成后先查一下服务器本机的内网 IPipconfig找到 IPv4 地址例如192.168.1.100。然后到同网段另一台机器执行curl http://192.168.1.100:11434/api/tags如果返回 JSON说明从网络层到 Ollama 服务都通了。如果仍然是连接超时或拒绝可以按这个顺序快速复核Ollama 进程是否以新的OLLAMA_HOST启动netstat是否显示0.0.0.0:11434防火墙规则是否作用在当前网络类型两台机器是否真的在同一网段。另外提醒一个细节不要拿服务器本机的localhost结果当成局域网结果。在服务器本机测试通过只能说明 Ollama 进程正常不能说明防火墙和网络路径正常。3. 局域网里其他程序怎么真正调用这个模型3.1 常用 API 端点和最小调用示例Ollama 的 HTTP API 设计很直接。列出模型用/api/tags生成回复用/api/generate多轮对话用/api/chat。对局域网调用来说真正会频繁用到的是后面两个。一个典型的生成请求长这样curl http://192.168.1.100:11434/api/generate -d {\model\:\qwen2.5:7b\,\prompt\:\你好请用一句话介绍你自己\,\stream\:false}如果不开启流式返回的会是一个完整 JSON里面包含response、done、eval_count等字段。开启stream:true时返回的是多行 JSON每一行对应一个增量片段适合做打字机效果。如果要用 Python 调用可以用requests或官方提供的ollama库。用requests写最小示例import requests url http://192.168.1.100:11434/api/chat payload { model: qwen2.5:7b, messages: [{role: user, content: 你好}], stream: False } r requests.post(url, jsonpayload) print(r.json()[message][content])这里最核心的变化就是 URL 里的 IP从localhost换成了局域网内 Ollama 所在机器的 IP。你的程序不需要做其他改动只要 base_url 指向这台机器即可。3.2 调用时最容易踩的三个错第一个是地址写错。在服务器本机顺手写了localhost或127.0.0.1然后在另一台机器上执行自然连不上。局域网内应该使用服务端的内网 IP而不是客户端自己的本地回环地址。第二个是端口漏写或写错。http://192.168.1.100:11434/api/tags看起来简单但很多人会顺手写成http://192.168.1.100/api/tags结果被默认 80 端口拒绝。Ollama 默认端口是11434除非你通过OLLAMA_HOST改成了别的端口否则必须带。第三个是模型名不一致。调用时报model not found并不是网络问题。需要确认服务端是否已经拉取对应模型。可以用curl http://192.168.1.100:11434/api/tags查看可用的模型列表再检查代码里写的模型名是否完全一致包括:7b这样的标签后缀。3.3 接入已有系统时的配置思路对很多开发者来说真正用途不是手动敲 curl而是让一个已有系统接上本地模型。常见的接入方式是把“模型服务地址”配置成http://192.168.1.100:11434。比如有些项目支持 OpenAI 兼容接口Ollama 也提供了/v1/chat/completions这样的端点前提是 Ollama 版本支持。如果版本较新就可以把 base_url 从https://api.openai.com/v1换成http://192.168.1.100:11434/v1模型名改成如qwen2.5:7b。具体支持范围建议以你当前 Ollama 版本的接口文档为准。接入时不要抱着“一配就好”的心态。先单独测试 Ollama 的 API再测试你的程序读取配置后是否真的把请求发到了目标地址。日志里如果能看到请求落到 Ollama 所在机器说明配置成功如果请求落到本机就要去查 base_url 的拼接逻辑。4. 从命令行到 Open WebUI局域网使用的两种形态4.1 直接 API 调用和图形界面适用场景完全不同局域网里的使用者通常分两类一类是开发者他们要调 API 把模型集成进自己的服务另一类是普通使用者他们希望打开一个页面像聊天工具一样用模型。后一种情况直接发给每个人一行 curl 命令体验很差也不利于管理上下文和模型参数。所以当你要把一个内网 Ollama 服务分享给团队时通常不是只开放 API而是再部署一个 Web 界面。常见的是 Open WebUI它支持通过浏览器登录后使用 Ollama 后端。这样 Ollama 负责模型推理Open WebUI 负责会话、历史记录、用户管理等。4.2 用 Docker 部署 Open WebUI 并连接 Ollama如果 Windows 上已经装了 Docker Desktop并且能用 WSL2 后端可以按常见方式用容器运行 Open WebUI。比较常见的一条命令示例是docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main启动之后在容器环境变量里把OLLAMA_BASE_URL设置成http://host.docker.internal:11434让 Open WebUI 知道去宿主机的 Ollama 取模型。如果你把容器运行在独立的服务器上也可以用固定的内网 IP比如http://192.168.1.100:11434效果一样。然后浏览器访问http://localhost:3000第一次注册账号进去后选择模型开始对话。如果容器能连通 Ollama你会在模型列表里看到已经拉取过的模型。这里有一个容易踩的坑Docker 容器里的localhost不是宿主机。如果不额外处理容器内的程序访问localhost:11434会指向容器自己找不到 Ollama。所以常见做法是用host.docker.internal这个特殊域名或在启动命令里通过--add-host把它映射到宿主机。在 Linux 主机上这个域名有时候不自动存在需要用host-gateway处理。Windows 上的 Docker Desktop 通常能映射host.docker.internal但建议还是按上面命令显式加--add-host减少版本差异带来的问题。4.3 没有 Docker 时的备选如果不装 Docker也可以用其他支持 Ollama 的 Web 界面项目。这些项目有的要求 Python 环境有的需要 Node 环境部署成本通常比 Docker 高但也不是不能做。选型时要重点看三件事项目是否还在更新是否支持 Ollama 的 API 地址配置是否提供基础的登录和会话管理。我个人的建议是如果只是临时演示用 API 客户端或写一个几十行的小页面就够了如果要给团队长期用优先考虑 Docker 这类可复现的方式别在 Windows 宿主上手工安装一堆依赖。毕竟工具链越复杂以后升级和迁移越容易出问题。4.4 界面解决体验问题但解决不了权限问题加上 Open WebUI 之后多了一层登录保护和会话管理但 Ollama 本身的 HTTP API 仍然是“打开着的”。如果你只开放了 3000 端口给内网那同事会通过页面登录使用但如果 Ollama 的 11434 端口也是一切入站都放行那同一内网里任何人仍然可以绕过页面直接调 API。所以在局域网内部署时不应把“有页面登录”等同于“API 安全”。更稳妥的做法是如果只希望团队用 Web 界面就只开放 3000 端口11434 端口要么只对需要 API 集成的人开放要么通过防火墙限制来源 IP。这样能避免有人无意间把流量扫到端口后直接消耗模型资源。5. 配置完成不代表长期稳定排查顺序和边界5.1 从现象到根因的排查顺序局域网连不上 Ollama最忌讳的是到处乱试。我的建议是固定一条排查链路先看现象再看输入再看环境再看参数最后看工具边界。针对 Ollama 场景可以简化成这张表现象先查后查常见根因连接超时局域网 IP 是否正确防火墙是否放行 11434IP 写错、防火墙拦了连接被拒绝Ollama 进程是否在跑监听地址是否为 0.0.0.0服务没启动、环境变量未生效404请求的 API 路径是否正确Ollama 版本是否支持该端点路径拼错、版本过旧model not found模型名是否与服务端一致模型是否已下载标签写错、没有这条模型响应很慢是否在加载模型磁盘/内存是否够用模型过大、介质瓶颈具体到一次排障我会让用户在服务器上先执行curl http://localhost:11434/api/tags。如果本地都失败说明 Ollama 本身有问题先不要查网络。如果本地成功再用服务器上ipconfig拿到的 IP 测试。如果局域网失败就去看netstat -ano | findstr 11434确认监听地址。监听地址没问题再看防火墙规则是否匹配当前网络配置文件。5.2 Windows 环境里几个容易反复踩的细节第一防火墙规则作用在哪个网络配置文件上。同一个物理网卡在“专用网络”和“公用网络”下规则可能不同。如果你添加规则时只选了profileprivate但 Windows 把当前网络识别成了公用那规则不会生效。第二环境变量里多了空格或引号。比如setx OLLAMA_HOST 0.0.0.0:11434 末尾多了空格看起来差不多实际上解析可能失败。设置完最好用echo %OLLAMA_HOST%或 PowerShell 里的$env:OLLAMA_HOST确认一下。第三磁盘空间不足。模型文件会占用大量空间如果系统盘只有十几个 GB 剩余拉取大模型很容易半途失败。规划路径时最好提前把OLLAMA_MODELS指向容量充足的磁盘。设置方式与OLLAMA_HOST类似比如setx OLLAMA_MODELS D:\ollama_models并重启 Ollama。如果目录不存在Ollama 可能会自动创建建议还是手动建好目录并确认权限。5.3 千万不要直接暴露到公网Ollama 默认没有内置的用户鉴权和 API Key 机制。只要监听0.0.0.0并且网络上能路由到这个端口任何人都可以对它发起请求。这里的后果不只是“别人能用你的模型”还包括磁盘、内存、显存被耗尽模型被占用后内部任务超时甚至因为长时间高负载导致 Windows 系统假死。所以在做局域网部署时要有一个边界意识只在可信内网开放。防火墙规则不针对public网络。如果有多张网卡尽量只让需要的那张网卡暴露。如果确实需要跨网络访问应在前端加反向代理、身份认证和流量控制而不是直接把 Ollama 端口暴露出去。这个话题没有“稳妥的公网裸奔方案”。公网访问意味着你要先解决认证、传输加密、限流、审计等一堆问题这已经超出了“Ollama 配置”的范畴。对绝大多数 Windows 本机部署场景内网足够。5.4 长期使用还要补的工程能力局域网开放以后你就不是在管理一个“本机工具”而是在维护一个“内网服务”。几个容易被忽略的点日志Ollama 的后台运行日志在哪里出事时怎么查看。Windows 下可以查看 Windows 事件或进程输出具体路径会随安装方式不同提前确认好。版本固定Ollama 升级后API 行为和默认端口可能有变化。团队内要约定一个可用的版本不要每台机器自己随便升级。资源监控模型同时被多个请求占用时Ollama 默认情况下是排队还是并行需要理解清楚。OLLAMA_NUM_PARALLEL等参数会影响并行行为但不建议一上来就调大先让默认配置稳定。清理模型ollama rm可以把不用的模型删掉避免磁盘空间持续膨胀。这些事不会在你首次部署时暴露但运行三周后一定会遇到。提前在文档里写清楚能省很多沟通成本。6. 真正值得记住的是一套“先单机、再开放、后保护”的部署顺序6.1 为什么顺序很重要很多局域网访问失败都是因为配置顺序反了还没验证单机就直接改监听、开防火墙、让同事来测。结果 Ollama 本身有问题却被误判成网络问题或者本身没问题但同事一测就连不上你开始怀疑是不是服务没启动。如果严格按“先单机、再开放、后保护”的顺序来每一个阶段都有明确的验证出口。单机阶段验证 Ollama 和模型可用开放阶段验证监听和防火墙保护阶段验证访问边界和资源控制。这样一个阶段失败不会牵扯到下一个阶段的因素。6.2 三阶段的检查清单阶段核心动作验证方式单机安装 Ollama拉取模型curl http://localhost:11434/api/tags开放设置 OLLAMA_HOST放行防火墙另一台机器curl http://内网IP:11434/api/tags保护限制来源、关闭不需要的端口、规划存储从非授权位置测试无法访问这个清单不用背理解每步在解决哪一层问题就行。下次再遇到连接失败先问自己现在是哪一层出了问题6.3 给 Windows 局域网部署的一句话建议如果你的最终目标只是自己笔记本上跑个模型玩那局域网访问不是必选项默认配置反而更安全。如果确实要让内网其他机器调用我建议找一台有固定内网 IP、硬盘空间充足的 Windows 机器从一开始就规划好OLLAMA_HOST和OLLAMA_MODELS再配合防火墙限制而不是装好了才临时改环境变量。这和“要不要用 Docker”“要不要上 Open WebUI”无关。只要想清楚“Ollama 是模型服务不是单机小工具”你就不会再把127.0.0.1当成默认真相。单机跑通只是起点开放访问要配置配置完之后还要保护。这三件事里前两件事让你能用最后一件决定你能用多久。