企业官网建设流程全解析

最近在折腾 Ollama 的服务化部署，发现很多人卡在“本机能跑、别人访问不了”这一步，明明模型都拉下来了，局域网里其他电脑就是连不上。其实就是两个点没搞定：Ollama 默认监听地址和防火墙规则。今天把这套配置流程完整捋一遍，从安装到局域网共享，再到 ufw 防火墙放行，照着做五分钟左右就能跑通。

这篇内容适合在公司内网搭共享推理服务、实验室多机调用大模型、或者纯粹想在家里几台设备间共用一套 Ollama 环境的朋友。涉及的配置命令都不复杂，但对 Linux 服务管理不熟的话容易踩到 systemd 环境变量那个坑，我会在中间重点说明。

1. 内容整体设计与思路拆解

1.1 为什么默认配置只能本机访问

Ollama 装完之后，默认监听地址是127.0.0.1:11434。这个地址的意思是“只有本机自己发的请求才会被接收”，网络上的其他设备哪怕跟你在同一个局域网里、连同一个路由器或交换机，发过来的请求也会被操作系统直接丢弃。

这其实是绝大多数自托管服务的默认安全策略——只监听回环地址，避免服务意外暴露到不可信网络。但问题在于，Ollama 本身的定位就是“本地私有化部署大模型”，在很多场景下我们需要的是让局域网内其他机器（比如 Windows 笔记本、另一台 Ubuntu 工作站）也能调用这个推理服务，那就必须把监听地址从127.0.0.1改成0.0.0.0。

0.0.0.0在 Linux 网络里代表“所有网络接口”，配置了这个地址之后，Ollama 就会同时监听本机回环接口、有线网卡、无线网卡上的所有 IP，局域网里的其他设备就能通过你的主机 IP 来访问 11434 端口了。

这里需要提醒一句：0.0.0.0也意味着服务器上所有网络接口都会暴露这个服务。如果服务器有公网 IP，那等于把服务直接挂到了公网上，任何人都能探测到你的 11434 端口，这个风险需要提前评估。

1.2 方案选型：systemd 配置 vs 命令行参数

设置 Ollama 监听地址有两种常见方式：一种是启动时加环境变量OLLAMA_HOST=0.0.0.0:11434，另一种是修改 systemd 服务文件里的环境变量配置。

我强烈推荐用 systemd 的方式。原因很简单：如果你用命令行手动启动 Ollama，那么关掉终端窗口或者注销登录，服务就停了；而 systemd 方式会把 Ollama 注册为系统服务，开机自启、崩溃自动重启、日志统一管理，这才是一个“服务”该有的形态。

而且很多人的 Ollama 是用官方安装脚本装的，装完自带 systemd 服务文件，只是默认环境变量里没有设置OLLAMA_HOST。我们只需要在服务配置里加一行环境变量，然后重启服务就行，不需要重新安装任何东西。

1.3 Ubuntu 防火墙策略：先放行再验证

Ubuntu 默认防火墙 ufw（Uncomplicated Firewall）很多时候是关闭状态的，这也是很多人“没配防火墙也能访问”的原因。但如果你的机器开启了 ufw，或者公司安全基线要求开启防火墙，那就必须在防火墙规则里放行 11434 端口，否则就算 Ollama 监听地址改对了，外部的 TCP 连接请求也会在防火墙层面被拦掉。

我的习惯是：先把 Ollama 服务配置好、确保本机能 curl 通，再配防火墙规则，最后在另一台设备上验证。这样每一步出现问题时定位范围都特别小，不会出现“服务也没配好、防火墙也改了，不知道到底哪里出错”的尴尬情况。

2. 环境准备与 Ollama 安装细节

2.1 Ubuntu 系统版本与硬件要求

我这里用的是 Ubuntu 22.04 LTS，内核 5.15 以上，这是目前最稳妥的组合。如果你还在用 18.04 或者 20.04，建议先看一下 Ollama 官方对操作系统的最低要求——太老的系统可能 glibc 版本不够，装完跑不起来。

硬件方面，Ollama 本身不挑显卡，纯 CPU 推理也能跑，但速度确实慢。如果你的机器有 NVIDIA 显卡，建议提前装好显卡驱动和 CUDA 运行库，这样 Ollama 拉取模型后会自动检测 GPU 并加载到显存里推理。没有 GPU 的话也不用灰心，小尺寸模型（比如 7B 或者更小的量化版本）在纯 CPU 上也能用，只是推理速度会慢不少，一般每秒出几个 token 的水平。

2.2 安装 Ollama 的三种方式

官方推荐的一键安装脚本是最省事的：

curl -fsSL https://ollama.com/install.sh | sh

这个脚本会自动检测操作系统、下载对应架构的二进制文件、创建 systemd 服务、启动 Ollama。执行完可以用ollama --version确认安装结果。

如果你所在的网络环境访问官方脚本比较慢，可以换用 apt 仓库方式：

curl -fsSL https://ollama.com/ollama.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/ollama.gpg echo "deb [signed-by=/etc/apt/keyrings/ollama.gpg] https://api.ollama.com/pub/linux/apt/ stable main" | sudo tee /etc/apt/sources.list.d/ollama.list sudo apt update && sudo apt install ollama

还有一种方式是直接下载二进制包手动解压，适合对安装路径有特殊要求的场景。从 GitHub Releases 页面下载对应架构的 tar.gz 包，解压后把ollama可执行文件放到/usr/local/bin或者自定义目录即可。手动方式还需要自己搞定 systemd 服务文件，所以我一般不做首选推荐。

2.3 拉取模型测试基础服务

安装完成之后，先拉一个小的模型测试基础服务是否正常：

ollama pull qwen2.5:7b

拉取过程会显示进度条，速度取决于你的网络和模型大小。拉完之后运行ollama list确认模型列表，然后用一行命令测试推理是否正常：

ollama run qwen2.5:7b "你好，请简单介绍一下你自己"

这一步能过，说明本机 Ollama 服务是健康的，接下来就可以进入局域网共享配置了。如果你公司内网有 HTTP 代理，需要提前在环境变量里配置HTTP_PROXY和HTTPS_PROXY，不然模型拉取会很痛苦，详见后面的常见问题部分。

3. 局域网共享配置实操与防火墙设置

3.1 修改 systemd 服务配置，设置监听地址

安装脚本自动创建的 systemd 服务文件位于/etc/systemd/system/ollama.service。官方脚本生成的文件内容大致是这样的：

[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Install] WantedBy=default.target

我们需要在[Service]段落里加一行环境变量。使用systemctl edit命令来修改，它会在/etc/systemd/system/ollama.service.d/目录下创建一个覆盖配置文件，这种方式不会影响原始服务文件，后续升级 Ollama 也不容易冲突：

sudo systemctl edit ollama.service

在打开的编辑器中输入：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存退出后，重新加载 systemd 配置并重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

注意：如果你之前是用 Docker 方式部署的 Ollama，则需要通过环境变量传给容器，命令大概是docker run -d --name ollama -e OLLAMA_HOST=0.0.0.0:11434 -p 11434:11434 ollama/ollama。本文重点讲 bare metal 方式，Docker 部署暂不展开。

3.2 验证监听状态是否正确

重启服务后，用ss命令检查端口监听情况：

sudo ss -tlnp | grep 11434

如果配置成功，输出里应该能看到类似这样的内容（注意 Local Address 这一列）：

LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("ollama",pid=5157,fd=3))

关键就看0.0.0.0:11434这一项，这说明 Ollama 已经监听在所有网络接口上了。如果你看到的仍然是127.0.0.1:11434，说明环境变量没有生效，很大概率是 systemd 覆盖文件没有正确加载。

3.3 防火墙设置：ufw 放行 11434 端口

接下来处理防火墙。先看一下 ufw 当前状态：

sudo ufw status

如果显示Status: inactive，说明防火墙没开，此时可以选择跳过这一步。但如果你希望保持防火墙开启并且只放行需要的端口，或者状态显示Status: active，那就需要加入放行规则：

sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp

192.168.1.0/24需要替换成你实际的局域网网段。查看自己机器 IP 和网段的方式：

ip addr show

找到你的网卡对应的 IPv4 地址，比如192.168.31.100/24，说明你的局域网网段就是192.168.31.0/24，换到 ufw 命令里就是192.168.31.0/24。

提示：为了安全，不建议直接sudo ufw allow 11434把端口对所有来源开放。如果这台机器有公网 IP，这意味着任何互联网上的人都能扫到你的推理服务，轻则被蹭算力，重则可能被恶意利用。限定来源网段是更稳妥的做法。

如果 ufw 是开启状态，放行之后可以再用sudo ufw status numbered检查规则：

Status: active To Action From -- ------ ---- 11434/tcp ALLOW 192.168.31.0/24 22/tcp ALLOW Anywhere

除了 ufw 之外，如果你的服务器还装了 firewalld，那么规则要加到 firewalld 里；如果用了云安全组（比如云服务器控制台里的安全组规则），还要去控制台放行 TCP 11434 端口。这个容易被忽略，本地防火墙全放开了却还是不通，最后发现是云安全组拦着。

3.4 获取本机局域网 IP，供客户端连接

配置完成后，你需要知道自己机器的局域网 IP。查看命令：

hostname -I

输出可能是192.168.31.100 172.17.0.1，其中第一个一般是局域网 IP（Docker 之类的虚拟网卡 IP 不用管）。记下这个 IP，后面其他设备连接时要用。

3.5 在另一台设备上验证是否通了

Linux / macOS 客户端

用 curl 验证 API 是否可访问：

curl http://192.168.31.100:11434/api/tags

正常返回类似{"models":[...]}的 JSON 就算通了。测试一次真实推理：

curl http://192.168.31.100:11434/api/generate -d '{"model":"qwen2.5:7b","prompt":"你好","stream":false}'

Windows 客户端

Windows 下如果装了 Ollama，可以直接在命令行指定 Ollama 的主机地址：

set OLLAMA_HOST=http://192.168.31.100:11434 ollama run qwen2.5:7b

如果 Windows 上没装 Ollama，也可以直接用浏览器或者简单的 API 测试工具（比如 Postman、Apifox）访问http://192.168.31.100:11434地址，能看到Ollama is running就说明服务正常。

代码调用测试

Python 端最简单的测试方式：

import requests response = requests.post( "http://192.168.31.100:11434/api/generate", json={"model": "qwen2.5:7b", "prompt": "你好", "stream": False} ) print(response.json()["response"])

这个测试通了，说明局域网共享配置全部完成，其他设备已经可以通过网络调用这台机器上的大模型服务了。

4. 常见问题与故障排查实录

4.1 配置了 OLLAMA_HOST 但 ss 还是显示 127.0.0.1

这个是我见过最多的情况，大多数人改完环境变量后没生效，原因几乎都是 systemd 服务没有重新加载。注意要执行两条命令：先systemctl daemon-reload让 systemd 重新读取服务配置，再systemctl restart ollama让进程真正以新环境变量启动。

如果已经执行了这两条命令还是不行，检查一下覆盖文件的位置：

sudo systemctl cat ollama

输出里应该能看到来自/etc/systemd/system/ollama.service.d/override.conf的环境变量。如果在输出里看不到OLLAMA_HOST，说明覆盖文件写错了位置或者写错了文件名。另外，确认覆盖文件里用的是Environment=而不是EnvironmentFile=，这两个作用完全不一样，我见过有人把EnvironmentFile=配了之后一直不生效，就是因为路径写错或者文件权限有问题。

还有一种情况：如果你是用非官方脚本的方式安装的 Ollama，systemd 服务文件里可能没有User=ollama这一行，进程是以 root 运行的。这在实际使用中问题不大，但如果覆盖文件里设置的环境变量包含路径，要注意路径的权限是否允许 ollama 用户读取。

4.2 防火墙已放行但仍然无法从其他设备访问

这种问题最简单的排查方式就是分层定位。先在 Ollama 服务器本机执行curl http://127.0.0.1:11434/api/tags，能通说明服务进程是健康的。然后用局域网内另一台设备 ping 一下服务器的 IP，能通说明二层网络没问题。之后再测 TCP 端口：

telnet 192.168.31.100 11434

如果 telnet 提示 Connection refused，说明服务没监听在正确地址或者进程根本没起来；如果提示 Connection timed out，多半是防火墙拦截或者网络隔离。还有一种可能是你在的其他设备跟服务器不在同一个网段，中间隔着三层设备且有访问控制策略，这种情况只能找网络管理员协调。

4.3 Windows 客户端连接时提示端口 445 错误

这个场景在搜索热词里出现过，很多人把 Ollama 共享和 Windows 的局域网共享（SMB 协议，走 445 端口）搞混了。如果你连的是 Ollama 的 11434 端口，报的却是 445 端口错误，说明你用的连接工具不是 Ollama 客户端，而是 Windows 的资源管理器或其他 SMB 相关工具，这种得去配置 Windows 的 SMB 共享，跟 Ollama 没关系。

Ollama 客户端连接时如果报错，大概率是 Connection refused 或者 timeout，不会涉及 445 端口。遇到 445 报错先确认自己用的工具对不对，这个方向错了会浪费大量时间排查。

4.4 模型下载慢或者卡在拉取阶段

不在同一个局域网内，而是需要通过公网拉模型的话，下载速度确实经常成为瓶颈。除了设置代理环境变量之外，也可以考虑从国内镜像站拉取模型，或者手动下载模型文件放到 Ollama 的模型目录里。具体模型文件放的位置默认在/usr/share/ollama/.ollama/models或者/root/.ollama/models，取决于服务以什么用户运行。

这里有个小技巧：复制模型文件到服务端前，先看一下ollama list里的模型名称和标签，粘过来的文件对应的 manifest 和 blob 目录必须完整，不能只拷贝一个文件。模型目录的结构比较复杂，建议在另一台机器上用ollama pull拉好之后，将整个.ollama/models目录打包压缩再传输，然后解压到目标机器对应的目录下，最后ollama list就能看到了。但要注意哈希值必须一致，如果拉取过程中断过，blob 目录里可能有残缺文件，建议重新 pull 一次确保完整性。

4.5 局域网访问正常但偶尔超时或响应慢

这个一般不是网络配置问题，而是推理服务本身负载过高。当多个客户端同时发起推理请求时，如果没有 GPU 或者显存有限，Ollama 会排队处理请求，此时每个请求的响应时间会显著变长，甚至看起来像是超时。

Ollama 默认的并发请求数量限制需要看具体版本，如果需求是多人同时调用，建议在服务端加一层负载考虑，比如同时跑多个实例，或者换更大的显存。也可以观察日志：

journalctl -u ollama -f

从日志里能看到每个请求的处理时间和错误信息，定位是排队等待还是推理本身慢。

4.6 在线求助时常见的排查命令总结

为了在和别人沟通或者自己排查时能快速提供有效信息，我整理了一张常用命令对照表：

这套命令走一遍，90% 以上的“局域网连不上 Ollama”问题都能定位出来。

5. 进阶配置与安全加固建议

5.1 给服务设置访问密钥

配置好局域网共享后，凡是能连到你这个网段的设备都能直接调用服务，在可信内网环境里这或许不是大问题，但如果公司网络里有多个部门、人比较多，最好还是加一层访问控制。Ollama 本身没有原生 API 密钥机制，但可以用反向代理（比如 Nginx 或 Caddy）在前面做认证。Nginx 加 basic auth 是最快的方案，配置一个用户名密码，所有请求必须带认证头才能转发到 Ollama。

用 Nginx 反向代理时，需要注意代理转发时要把Host、Authorization、Content-Type等头正确传给后端，同时配置client_max_body_size防止大请求被拦截。另外 WebSocket 支持也要开启，某些客户端流式请求会用到：

location / { proxy_pass http://127.0.0.1:11434; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }

5.2 绑定固定 IP 与开机自启检查

DHCP 模式下服务器的 IP 可能会变化，导致客户端配置的地址失效。建议在路由器上设置 DHCP 静态绑定，或者在 Ubuntu 上用 netplan 配置静态 IP。这样客户端就可以用固定 IP 访问，不用每次重启后到处问 IP 是多少。

开机自启方面，确认一下：

sudo systemctl enable ollama

执行后系统启动时会自动拉起 Ollama 服务，不用手动登录。把这一步做了，服务器重启之后整个服务全家桶就都恢复了。

5.3 基于调用场景的参数调优

不同使用场景下，Ollama 的配置参数差异很大。比如同时连接数多，可以在环境变量里调整OLLAMA_NUM_PARALLEL；模型加载策略也可以配置OLLAMA_MAX_LOADED_MODELS，控制最多同时保持几个模型在内存中。这个值设置得太大而内存不够时，会导致部分模型被强制卸载，重新调用时又要重新加载，延迟反而变大。

生产环境建议先小规模测试，观察内存、显存占用情况再逐步上调。非流式请求和流式请求的负载特征不同，前者是整体生成完再返回，后者是边生成边边返回，显存占用和内存带宽要求不同，测试时最好都覆盖一下。

5.4 暴露到公网的额外风险说明

如果你真的需要让外网访问这个推理服务（比如出差时要用），不要直接把 11434 端口映射到公网。强烈建议至少做这些事：使用反向代理加 HTTPS、在代理层加 API 密钥认证、限制单 IP 的请求频率、对端口的访问来源做好审计。开放式的大模型服务如果被恶意刷量，算力消耗和费用会很可观。在自己真正理解风险之前，保持服务只在局域网内共享是最稳妥的。

6. 实操总结与经验心得

分享几个我实际操作中积累的小经验，可能帮大家少走弯路。

第一，改配置后一定先daemon-reload再restart，这两条命令缺一不可。很多人只执行了restart就以为配置生效了，实际上 systemd 里对 service 配置做了缓存，不 reload 重启后用的还是旧配置。这个顺序问题我踩过不止一次。

第二，防火墙规则尽量精确。只对需要的网段放行端口，不要图省事直接ufw allow 11434。内网里知道你机器 IP 的人可能比想象的多，端口开放范围越小越不容易被无关人员探测到。

第三，测试的时候别只看 API 通不通。命令行 curl 通了只代表 HTTP 层没问题，真正跑一次模型推理、看一下输出速度和响应内容，才能确认模型加载正常、显存或者内存分配没有隐性问题。

第四，局域网共享其实是 Ollama 部署的第一小步。配置好之后，你可以在自己的笔记本上直接连公司工作站上的大模型跑代码、做验证，体验和本地跑几乎没有区别。后续如果还想把服务暴露到更广范围，在这个基础之上再做反向代理、负载均衡或者加认证，都是一个方向逐步演进。

我在实际使用中发现，Ollama 的 systemd 日志信息量很大，遇到问题不要慌，先看日志：

journalctl -u ollama -n 30

日志里通常直接说明了启动失败的原因、模型加载的详细信息，还有端口冲突之类的蛛丝马迹。大部分问题看完日志就能定位，比到处猜来得快得多。

最后再分享一个细节：Ollama 的模型默认存放在服务运行用户的家目录下，如果你用sudo修过一些系统配置，小心不要顺手把模型目录的权限也改乱了。保持模型目录归属给运行用户即可，改乱了可能会导致模型加载失败，到时候又得从头排查一遍。