先从我实际踩过的一段经历聊起。前阵子帮团队组了一台Ubuntu工作站显卡装好了、驱动也调通了Ollama一启动就能在本地跑Llama 3。但问题马上来了我是想让大家都能用这个模型办公室里同事用的是Windows笔记本、Mac不可能人人都在自己电脑上装一套Ollama、再拉一个十几GB的模型。团队里还有几个人用Open WebUI直接在浏览器里聊天。如果Ollama只能监听本机回环地址其他机器根本访问不到这台工作站就成了“一人独占”的玩具。解决办法其实不复杂把Ollama的监听地址从127.0.0.1改成0.0.0.0再放行防火墙端口就行。整个过程熟练的话5分钟以内真的能搞定不熟练的话看完这篇文章也够用了。这篇文章会把原理、配置和踩坑点一次讲透适合已经在Ubuntu上跑通Ollama、正打算在局域网共享服务的同学也适合刚装完Ollama、想彻底搞懂“怎么让别的设备也能访问”的初学者。1. 核心思路为什么默认连不上又该从哪里下手1.1 先搞明白Ollama默认“只对本机开放”的原因Ollama在Linux下默认监听的是127.0.0.1:11434这个127.0.0.1又叫回环地址意思是“只有本机自己访问自己”。想在浏览器里打开http://localhost:11434没问题想在局域网另一台电脑上访问http://服务器IP:11434连接会直接被拒绝。这其实是有意的安全设计。大模型服务天然比较“重”一个模型占掉十几GB显存接口又没有内置账号密码验证机制。如果默认就监听0.0.0.0也就是所有网络接口那只要局域网里的任何设备知道这个端口就能直接往服务里发推理请求后果不难想象。所以官方默认把口子收紧只允许本机回环访问。理解了这层原因后面的配置思路就清晰了你必须主动告诉Ollama“放心对外开放”同时自己把系统防火墙这道门打开让别人的请求能进得来。两个条件缺一个共享就不成立。1.2 局域网共享方案选型对比要让Ollama监听局域网常见的改法有三种临时改环境变量在终端执行export OLLAMA_HOST0.0.0.0:11434然后当前终端里启动ollama serve。这种方式适合临时测试终端一关服务就恢复原样不适合做长期服务。直接改系统环境变量比如写进/etc/environment这个方案对桌面端偶尔有效但对systemd托管的Ollama服务往往不起作用因为服务进程不读取这个文件很多人就卡在这里。用systemd override配置也就是systemctl edit ollama这是目前最推荐的方式配置固化、重启生效、升级不丢也是下面实操部分采用的做法。用systemd配置还有一个好处不依赖你是用install脚本装的Ollama还是手动下载二进制包再注册成服务。只要服务是systemd管理的override方式都统一有效。如果Ollama当前只是前台运行、没被注册成服务那可以先从export方式起步跑通共享后再考虑做成服务。1.3 共享之后的访问链路配置完成后整个访问链路是这样局域网内的任何一台设备把请求发到http://主机IP:11434Ubuntu主机的防火墙放行该端口systemd托管的Ollama进程再把这个请求接收下来最终交给本地运行的模型执行推理。Ollama的原生API比如/api/tags、/api/chat和兼容OpenAI的/v1/chat/completions接口都监听同一个端口所以你既可以用curl直接调也可以在任何支持OpenAI兼容接口的工具里填服务器IP:11434/v1当作Base URL使用。有一个细节容易忽略如果客户端用的是浏览器里打开的网页工具比如Open WebUI、Chatbox的网页版本浏览器会先发一个OPTIONS预检请求来确认跨域规则。Ollama默认对跨域请求有限制所以还需要通过OLLAMA_ORIGINS环境变量放行。这个问题后面在常见问题部分会专门展开。2. 准备工作环境检查与基础依赖2.1 Ubuntu版本与系统环境确认开始配置前别急着动手先确认一下当前系统的基本情况。不同Ubuntu版本的防火墙命令大同小异但确认一遍总归稳妥。lsb_release -a uname -a如果输出显示Ubuntu 20.04、22.04或24.04都适用本文的配置方式。uname -a主要看内核架构正常的x86_64服务器没问题如果是ARM架构的机器比如树莓派、部分ARM云主机Ollama安装包和后续兼容性会有些差异需要额外注意。还要确认一下11434端口现在有没有被别的进程占用。之前我见过一台机器上同时装了Prometheus一类的监控端口规划和Ollama撞了导致Ollama一直起不来。检查命令如下sudo ss -tlnp | grep 11434如果没有输出说明端口空闲。如果有输出看下是不是Ollama自己如果显示的是别的进程就需要先处理端口冲突。2.2 Ollama的安装与服务状态确认如果你的Ollama是通过官方安装脚本安装的curl -fsSL https://ollama.com/install.sh | sh装完通常会自动注册一个叫ollama的systemd服务并且立刻启动。先确认版本和运行状态ollama --version sudo systemctl status ollama --no-pager再确认想共享的模型已经拉下来了ollama list这个命令会列出本地已有的模型比如llama3:8b、qwen2.5:7b之类的。如果列表是空的说明还没有模型先ollama pull llama3.1:8b把模型拉下来再说。注意模型文件的存储位置默认在/usr/share/ollama/.ollama/models系统服务方式运行时不同安装方式路径可能有差异共享配置本身不涉及模型迁移但如果后续想改模型存储路径就得额外关心这个目录。2.3 局域网IP与网段规划共享服务的前提是客户端和服务器在同一个局域网里所以先摸清服务器自己的IPip addr show通常输出里会有一个192.168.x.x或10.x.x.x这样的地址就是内网IP。记录下这个IP以及它的网段。假设IP是192.168.1.100默认掩码是255.255.255.0那客户端要访问的地址就是http://192.168.1.100:11434防火墙放行的时候也可以精确到192.168.1.0/24这个网段。如果服务器同时接了有线网和无线网ip addr里会出现多个网卡要认准实际接入局域网的哪一个IP。曾经就有人把无线网卡的IP当成对外地址放行规则写错了死活连不上浪费了十几分钟。3. 局域网共享配置两个关键改动一次搞定3.1 修改监听地址为0.0.0.0这是整个共享最重要的一步我的做法是直接编辑systemd服务的override配置sudo systemctl edit ollama执行后系统会自动新建并打开一个空白配置文件路径实际上在/etc/systemd/system/ollama.service.d/override.conf。在这里写入下面两行[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434OLLAMA_HOST0.0.0.0表示监听所有网络接口不只是回环地址。冒号后面的11434是端口也可以省略不写Ollama默认就会用11434但写上更明确。有些教程会让你在/etc/environment里写OLLAMA_HOST0.0.0.0:11434这个做法对systemd服务无效。我最初也试过改完以后systemctl restart ollama端口监听还是停留在127.0.0.1白忙活一场。后来才发现systemd启动的进程压根不读/etc/environment文件正确做法就是刚才说的override或者直接把变量写进服务文件本身。如果你不想用systemctl edit也可以手动创建并编辑sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_ORIGINS* EOF我顺手把OLLAMA_ORIGINS*也放进去了。这个变量用于控制跨域请求的来源*表示允许任意来源对于浏览器访问的网页工具来说很有必要。如果在同一个工具里有多个Ollama实例比如有多台GPU服务器可以设成具体的域名或IP列表但大多数内网场景直接*就够用。改完以后必须重新加载systemd配置并重启Ollama服务sudo systemctl daemon-reload sudo systemctl restart ollama重启后检查监听地址sudo ss -tlnp | grep 11434如果输出里出现了类似0.0.0.0:11434或者*:11434的监听记录说明Ollama已经对外开放了。如果还是127.0.0.1:11434说明override配置没生效按第5章排查。3.2 防火墙放行11434端口监听地址改成0.0.0.0之后另一个常见的“隐形阻断”就是防火墙。Ubuntu一般自带的是UFWUncomplicated Firewall默认状态下可能是关闭的也可能是开启的。先看状态sudo ufw status verbose输出Status: inactive代表防火墙没启用这种情况理论上端口就是通的不用再配置。但如果之前手动开过防火墙、或者装完系统时一键开启了UFW那就必须放行端口。我不太建议直接sudo ufw allow 11434把端口对所有IP开放虽然最省事但确实不够稳妥。更推荐把放行范围限制在局域网网段命令如下sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp这条规则的意思是只允许192.168.1.0到192.168.1.255这个网段的设备访问TCP 11434端口其他来源一概拒绝。如果你确定客户端分布在多个网段比如公司里有办公网和访客网那就分别加两条规则或者用sudo ufw allow from 10.0.0.0/8 to any port 11434 proto tcp覆盖私网段。配置完毕后重载防火墙让规则生效sudo ufw reload sudo ufw status verbose如果看到类似11434/tcp ALLOW 192.168.1.0/24的信息防火墙这关就通了。注意如果系统用不是UFW而是firewalld部分定制系统可能预装管理命令会不同先用sudo systemctl status firewalld确认实际管理工具避免像无头苍蝇一样乱试。3.3 本机与远程双向验证配置完成后先在本机验证Ollama服务是否正常响应curl http://127.0.0.1:11434/api/tags正常会返回一个JSON里面包含你本地的模型列表。接着换服务器自己的局域网IP测一遍curl http://192.168.1.100:11434/api/tags这一步能确认Ollama确实在局域网IP上监听如果本机IP访问没问题但局域网IP访问失败通常是监听地址没改成功回到3.1节检查。然后换一台同一局域网的电脑验证。以Windows为例在命令行里执行curl http://192.168.1.100:11434/api/tags或者直接把http://192.168.1.100:11434贴到浏览器里。如果能看到Ollama is running的提示页面说明共享已经完全打通。注意Windows的curl在PowerShell里可能是Invoke-WebRequest的别名如果curl命令报错就用浏览器访问的方式验证最直观。4. 实操记录从安装到局域网可用的完整流程4.1 场景与目标我给团队部署的机器配置大致是Ubuntu 22.04 LTS一张RTX 4090显卡驱动和CUDA已经装好。Ollama是之前用官脚本装的模型拉的是llama3.1:8b和qwen2.5:14b。目标很明确让办公室里所有同事的电脑Windows为主少数Mac都能直接通过IP访问这台服务器上的大模型并且在Open WebUI聊天界面里随时切换模型。4.2 执行过的每一步命令我按顺序执行了下面这些操作你可以直接照着敲前提是把IP换成你自己的。# 1. 确认状态 ollama --version sudo systemctl status ollama --no-pager ip addr show sudo ufw status verbose # 2. 关闭搜狗输入法等无关因素干扰只关注服务本身 # 3. 修改systemd override配置 sudo systemctl edit ollama在打开的编辑器里粘贴[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_ORIGINS*保存退出。然后继续# 4. 重载并重启 sudo systemctl daemon-reload sudo systemctl restart ollama # 5. 确认监听地址重点看是否有 0.0.0.0:11434 sudo ss -tlnp | grep 11434 # 6. 放行防火墙注意替换为你的实际网段 sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp sudo ufw reload # 7. 本机验证 curl http://127.0.0.1:11434/api/tags curl http://192.168.1.100:11434/api/tags执行完第5步我看到监听地址变成了*:11434心里基本有底了。第7步两个curl都能返回模型列表说明服务本身没问题。最后让同事在Windows浏览器里访问http://192.168.1.100:11434页面上出现了Ollama is running同时我用Chatbox添加了一个OpenAI兼容的API地址http://192.168.1.100:11434/v1填上模型名llama3.1:8b发了一句“你好”模型正常回复。整个过程确实只花了几分钟主要时间都花在确认网段和填写客户端配置上。4.3 多客户端接入方式参考共享打通之后不同客户端接入的方式略有差异这里列几个常见的Open WebUI服务器上用Docker部署Open WebUI时需要把OLLAMA_BASE_URL环境变量指向http://host.docker.internal:11434容器场景或者如果Open WebUI直接跑在宿主机就填http://127.0.0.1:11434。如果是客户端访问远程Open WebUI那Open WebUI本身又成了另一个服务需要单独考虑它的局域网访问和防火墙。Chatbox软件里新增API提供方类型选OpenAI兼容Base URL填http://192.168.1.100:11434/v1API Key随便填比如ollama模型选llama3.1:8b就能直接用。Python脚本用openai库把base_url改为http://192.168.1.100:11434/v1即可。示例from openai import OpenAI client OpenAI( base_urlhttp://192.168.1.100:11434/v1, api_keyollama ) resp client.chat.completions.create( modelllama3.1:8b, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)这种方式对开发同学特别友好之前写着localhost:11434的代码现在把地址改一下就能连远程的模型服务不用每台机器都拉一套模型。5. 常见问题与排查技巧实录5.1 局域网无法访问的高频原因共享配置看似简单但实际部署时遇到的问题真的不少。我把常见的问题整理成了一个速查表方便你快速定位现象可能原因快速排查方法curl http://IP:11434超时或拒绝本机curl正常监听地址没改成0.0.0.0ss -tlnp | grep 11434看监听的是127.0.0.1还是0.0.0.0本机能访问局域网内其他机器不行防火墙没放行或规则写错sudo ufw status verbose确认规则覆盖客户端网段其他机器能访问但网页工具报跨域错误没有设置OLLAMA_ORIGINS在override配置里加EnvironmentOLLAMA_ORIGINS*并重启服务重启后配置失效环境变量写进了/etc/environment改用systemctl edit ollama写override再daemon-reload所有机器都访问不了服务本身没起来systemctl status ollama看日志确认模型是否在加载这几个原因里远程机器超时最常见的原因就是防火墙。曾经有一台Ubuntu服务器的UFW状态显示inactive我就以为肯定没墙结果后来发现是之前装云厂商安全组件时启用了iptables规则直接挡掉了非本机流量。如果UFW明明关着但还是不通建议检查一下iptables -L -n输出必要时先停掉可疑的DROP规则再测。5.2 关于CORS和OpenAI兼容接口的坑在给网页端工具配置Ollama地址时经常遇到“请求被CORS策略阻止”或是“跨域错误”的情况具体表现是服务本身是通的、curl能访问但浏览器里的应用就是连不上。原因在于浏览器安全机制网页应用和API服务不是同一个源端口不同、IP不同、协议不同都算跨域浏览器会先发送一个OPTIONS预检请求Ollama必须明确允许来源才能通过。解决办法就是设置OLLAMA_ORIGINS*sudo systemctl edit ollama在override配置里加上[Service] EnvironmentOLLAMA_ORIGINS*然后重启sudo systemctl daemon-reload sudo systemctl restart ollama如果是本地用原生API测试比如直接写Python脚本调Ollama不走浏览器那么跨域问题不存在可以不用管OLLAMA_ORIGINS。但如果用Open WebUI、NextChat这类网页前端就必须设置这个变量否则工具会一直报连接失败。5.3 性能、私密性与长期维护建议共享服务跑起来之后有些问题会在使用几天后慢慢浮现这里分享几个从实操中得到的建议并发问题比想象中来得快。别小看团队的调用量七八个人同时提问一张4090的显存可能瞬间被打满模型推理速度明显下降。如果有多块GPU可以考虑跑多个Ollama实例或者换用支持多卡负载均衡的部署方式。只是简单共享的话就做好心理准备人多的时候慢不代表配置有问题。防火墙规则尽量精确。能写网段就写网段不要图省事ufw allow 11434对全公网开放。Ollama没有内置账号密码体系一旦暴露到公网任何人都可以白嫖你的显卡算力严重的还会被恶意刷爆显存。有条件的话建议在上层加一层身份验证比如用Open WebUI自带的登录功能做代理或写一个简单的Nginx反向代理配合Basic Auth。留意模型仓库的磁盘占用。多人共享后大家可能会不断尝试新模型/usr/share/ollama/.ollama/models目录会迅速膨胀。我建议过团队每个月清理一次用ollama rm删掉不用的模型。也可以在~/.ollama/models或系统服务对应的models目录里看一下实际占用必要时做磁盘配额或定期清理。最后分享一个我自己的使用习惯重复配置几次以后我发现一个很有用的检查技巧不要只盯着ollama list里的模型还要学会看systemctl cat ollama输出。这个命令会把服务当前生效的所有配置一次性展示出来包括override里的环境变量是否真的被加载。如果看到Environment里没有OLLAMA_HOST那多半是编辑错了文件或者忘了重载daemon。还有一点如果临时想测一个新端口或新地址又不想改系统里的服务配置可以先干跑一个前台进程。比如OLLAMA_HOST0.0.0.0:11435 ollama serve这样会在11435端口起一个临时服务用完CtrlC停掉即可不影响原来的systemd服务。这个方式做实验特别方便尤其适合验证防火墙规则或客户端配置是否正确。共享大模型这个事本质就是“环境变量防火墙”两道关闯过去之后整个团队的开发效率能提一个台阶。