1. 装完 ollama 先别急着拉模型，这两件事没做等于白装

很多人拿到 ollama 的第一反应就是赶紧跑个ollama run试试效果，结果模型是能跑起来，但用不了几天就发现 C 盘红了、局域网里其他设备连不上、想换个模型存储位置又不知道怎么迁。我见过太多人装完 ollama 之后直接开跑，等到磁盘告急或者想远程调用的时候才回头折腾，那时候模型文件已经堆了几十 GB，迁移成本直接翻倍。

这篇内容就是围绕"装完 ollama 之后，先确认什么、先设置什么"来展开的。核心就两件事：第一，确认你的安装到底装到哪了、版本对不对、服务有没有正常起来；第二，在拉第一个模型之前，把OLLAMA_MODELS和OLLAMA_HOST这两个环境变量配好。这两件事看起来简单，但顺序错了、配错了，后面全是坑。

适合谁看？如果你是第一次在 Windows、macOS 或者 Linux 上装 ollama，或者你已经装了但从来没动过环境变量，那这篇就是写给你的。如果你已经在用 ollama 部署私有模型、接 FastAPI、接 Dify、接 Cherry Studio 这类工具，但一直用的是默认配置，那更应该看看，因为默认配置在生产场景下基本不够用。

我自己的习惯是：任何工具装完，先花十分钟把"它装在哪、数据存哪、服务怎么暴露"这三个问题搞清楚，再开始干活。ollama 也不例外。下面按实际操作顺序，把确认和设置这两件事拆开讲透。

2. 安装完成后的第一轮确认：版本、路径、服务状态

2.1 用三条命令确认 ollama 真的装好了

装完 ollama 之后，不要凭感觉认为"安装包跑完了就是装好了"。我习惯用三条命令做交叉确认：

ollama --version ollama list ollama ps

ollama --version确认的是客户端二进制能不能正常调用，以及版本号是多少。版本号这件事比很多人想的要重要，因为 ollama 的迭代速度很快，不同版本对模型格式、API 参数、环境变量的支持程度不一样。比如早期版本对OLLAMA_HOST的绑定行为和新版本就有差异，如果你照着旧教程配，可能怎么都不生效。

ollama list确认的是模型存储目录能不能被正确读取。刚装完的时候这个列表应该是空的，但关键是它不能报错。如果这条命令直接报"could not connect to ollama server"或者路径相关的错误，说明服务没起来或者存储路径有问题。

ollama ps确认的是当前有没有模型在运行。刚装完肯定是空的，但这条命令能跑通，说明服务端和客户端之间的通信是正常的。

提示：如果你在 Windows 上用的是安装包版本，装完之后 ollama 会默认注册为后台服务并开机自启。这时候ollama ps能通不代表服务配置没问题，还要看后面 2.3 节的服务状态确认。

2.2 找到模型到底存在哪个目录

这是最多人忽略的一步。ollama 默认把模型存在用户目录下，不同系统路径不一样：

为什么要先确认这个？因为一个 7B 的模型量化后大概 4GB 左右，13B 的接近 8GB，70B 的能到 40GB 以上。你要是准备跑几个模型对比效果，C 盘或者系统盘很快就会被吃满。Windows 用户尤其要注意，很多人 C 盘只分了 100GB，装两个模型就开始报警。

确认方法很简单，先拉一个小模型测试：

ollama pull qwen2.5:0.5b

拉完之后去看上面表格里对应的目录，确认文件确实出现在那里。这一步的目的是建立"我知道我的模型存在哪"的确定感，而不是等到磁盘满了才去找。

2.3 确认服务监听在哪个地址和端口

ollama 默认监听127.0.0.1:11434。这个默认值意味着只有本机能访问，局域网里其他设备、Docker 容器、虚拟机都连不上。如果你只是本机玩玩，这个默认值没问题；但只要你打算做下面任何一件事，就必须改：

• 用另一台电脑或手机调用这台机器的 ollama
• 在 Docker 里跑 Dify、Open WebUI 这类工具去连宿主机的 ollama
• 用 FastAPI 写个中间层对外提供服务
• 在 WSL 里调用 Windows 宿主机上的 ollama

确认当前监听状态，Linux 和 macOS 上用：

ss -tlnp | grep 11434

或者：

lsof -i :11434

Windows 上用：

netstat -ano | findstr 11434

如果看到的是127.0.0.1:11434，说明只绑了本地回环。如果看到0.0.0.0:11434或者[::]:11434，说明已经对外开放了。这个区别直接决定了你的 ollama 能不能被其他设备访问。

注意：把 ollama 暴露到0.0.0.0之前，先想清楚网络环境。如果是家里内网、公司内网，问题不大；如果是云服务器有公网 IP，那就要考虑访问控制的问题，别裸奔。

3. OLLAMA_MODELS：不改这个变量，你的 C 盘迟早要炸

3.1 为什么模型存储路径必须提前改

OLLAMA_MODELS这个环境变量控制的就是模型文件的存放位置。为什么强调"提前"？因为 ollama 不会自动帮你迁移已经下载的模型。你装完之后拉了一堆模型，默认全在 C 盘用户目录下，等你发现 C 盘满了再去改环境变量，新模型会存到新路径，但老模型还留在原地，你得手动搬。

手动搬也不是不行，但有几个坑：一是模型目录里有 blobs 和 manifests 两层结构，直接复制容易漏文件；二是如果 ollama 服务正在运行，文件被占用，复制会失败；三是搬完之后权限可能不对，Linux 上尤其明显。所以最省事的做法就是装完 ollama、拉第一个模型之前，就把OLLAMA_MODELS设好。

我自己的习惯是把模型统一放在数据盘，比如 Windows 上放D:\ollama\models，Linux 上放/data/ollama/models。这样系统盘重装、用户目录清理都不影响模型文件，换机器的时候直接把目录拷过去，配好环境变量就能用。

3.2 Windows 上设置 OLLAMA_MODELS 的完整步骤

Windows 有两种设置方式，一种是图形界面的系统环境变量，一种是命令行。图形界面更直观，适合不熟悉命令行的朋友。

图形界面步骤：

1. 按Win + R，输入sysdm.cpl，回车
2. 切换到"高级"选项卡，点击"环境变量"
3. 在"系统变量"区域点击"新建"
4. 变量名填OLLAMA_MODELS，变量值填你的目标路径，比如D:\ollama\models
5. 确定保存，然后重启 ollama 服务（重要，不重启不生效）

命令行方式（管理员权限的 PowerShell）：

[System.Environment]::SetEnvironmentVariable('OLLAMA_MODELS', 'D:\ollama\models', 'Machine')

设置完之后，一定要重启 ollama。Windows 上 ollama 是作为服务跑的，重启方法：

Restart-Service ollama

或者直接在任务栏右下角找到 ollama 图标，退出再重新启动。

验证是否生效：

ollama pull qwen2.5:0.5b

拉完之后去D:\ollama\models看，如果文件出现在那里，说明配置成功。如果还在 C 盘，说明环境变量没生效，检查是不是设成了"用户变量"而不是"系统变量"，或者服务没重启。

3.3 Linux 上改模型路径的两种场景

Linux 上要分两种情况，因为 ollama 可能以服务方式运行，也可能以用户进程方式运行。

如果是 systemd 服务方式（用官方安装脚本装的通常是这种），环境变量要写在 service 文件里：

sudo systemctl edit ollama.service

这会打开一个 override 文件，在里面加：

[Service] Environment="OLLAMA_MODELS=/data/ollama/models"

保存后重载并重启：

sudo systemctl daemon-reload sudo systemctl restart ollama

如果是手动启动的（比如直接跑ollama serve），那就在 shell 的配置文件里加：

export OLLAMA_MODELS=/data/ollama/models

写到~/.bashrc或~/.zshrc里，然后source一下。

提示：Linux 上如果用 systemd 服务方式，改了 service 文件之后，原来默认路径/usr/share/ollama/.ollama/models里的模型不会自动迁移。要么重新拉，要么手动搬过去并改好权限（ollama 用户需要有读写权限）。

3.4 迁移已有模型的正确姿势

如果你已经拉了一堆模型才想起来要改路径，迁移步骤是这样的：

1. 先停掉 ollama 服务
2. 把整个 models 目录复制到新位置
3. 设置OLLAMA_MODELS指向新位置
4. 重启服务
5. 用ollama list确认模型列表还在
6. 确认无误后再删除旧目录

Linux 上复制的时候注意保留权限：

sudo cp -a /usr/share/ollama/.ollama/models /data/ollama/models sudo chown -R ollama:ollama /data/ollama/models

Windows 上直接复制文件夹就行，但要注意复制的时候 ollama 服务必须是停止状态，否则文件被占用会复制失败。

4. OLLAMA_HOST：不改这个变量，局域网里谁也连不上你

4.1 默认只绑 127.0.0.1 意味着什么

OLLAMA_HOST控制的是 ollama 服务监听的地址和端口。默认值是127.0.0.1:11434，这个地址是回环地址，只有本机自己能访问。

这意味着什么？举几个实际场景你就明白了：

• 你在台式机上装了 ollama，想用笔记本上的 Open WebUI 去连，连不上
• 你在 Windows 上装了 ollama，在 WSL 里跑 Dify，Dify 容器里配http://localhost:11434连不上
• 你用手机上的某个客户端想调用家里电脑的 ollama，连不上
• 你在云服务器上装了 ollama，想从本地调用，连不上

这些问题的根源都是同一个：ollama 只绑了回环地址。解决办法就是把OLLAMA_HOST改成0.0.0.0:11434，让它监听所有网络接口。

4.2 设置 OLLAMA_HOST 的正确写法

Windows 上同样是系统环境变量：

变量名：OLLAMA_HOST 变量值：0.0.0.0:11434

Linux systemd 服务方式：

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

手动启动方式：

export OLLAMA_HOST=0.0.0.0:11434

这里有个细节很多人会写错：值必须是0.0.0.0:11434这种带端口的格式，不能只写0.0.0.0。只写 IP 不写端口，ollama 可能不会按你预期的方式解析。另外端口号可以改，比如你想用11435，那就写0.0.0.0:11435，但改完之后所有调用方都要跟着改。

设置完重启服务，再用 2.3 节的方法确认监听地址变成了0.0.0.0:11434。

4.3 暴露到局域网之后必须考虑的事

把 ollama 暴露到0.0.0.0之后，同一网络里的任何设备都能访问你的 ollama API。这在家庭内网问题不大，但在公司网络或者云服务器上就要注意了。

ollama 本身没有内置的认证机制，谁都能调你的模型。如果你在云服务器上暴露了0.0.0.0:11434，又没有安全组或防火墙限制，那基本上等于把模型算力免费开放给所有人。我见过有人云服务器上的 ollama 被扫到，然后被用来跑各种任务，账单直接起飞。

几个实用的防护思路：

• 云服务器上只绑内网 IP，通过反向代理对外提供服务
• 用防火墙限制来源 IP，只允许特定网段访问
• 在 ollama 前面加一层带 API Key 校验的代理
• 家庭内网环境下，至少确保路由器没有做端口映射

注意：如果你只是本机使用，完全不需要改OLLAMA_HOST。不要为了"看起来更专业"而盲目暴露服务，安全边界越小越好。

4.4 改了 HOST 之后客户端怎么连

改了OLLAMA_HOST之后，调用方的配置也要跟着调整。几种常见场景：

本机调用还是用http://localhost:11434，因为0.0.0.0包含了回环地址，本机访问不受影响。

局域网其他设备调用，要用http://<服务器IP>:11434，比如http://192.168.1.100:11434。

Docker 容器里调用宿主机，Linux 上用http://172.17.0.1:11434（Docker 默认网桥地址），或者用host.docker.internal（Docker Desktop 支持）。Windows 和 macOS 的 Docker Desktop 直接用http://host.docker.internal:11434就行。

WSL 里调用 Windows 宿主机的 ollama，用 Windows 宿主机的局域网 IP，或者 WSL2 里通过/etc/resolv.conf里的 nameserver 地址访问。

这些连接细节看起来琐碎，但实际部署的时候十有八九会卡在这里。提前把OLLAMA_HOST配好，后面接各种工具的时候能省大量排查时间。

5. 两个变量配好之后，怎么验证真的生效了

5.1 用 ollama list 和实际拉模型做双重验证

环境变量这种东西，设了不等于生效。我习惯用两步验证：

第一步，拉一个小模型，确认文件出现在新路径：

ollama pull qwen2.5:0.5b

然后去OLLAMA_MODELS指向的目录看，应该有blobs和manifests两个子目录，且里面有文件。

第二步，从另一台设备访问 API：

curl http://<服务器IP>:11434/api/tags

如果返回了模型列表的 JSON，说明OLLAMA_HOST生效了。如果连接被拒绝，说明要么环境变量没生效，要么防火墙拦了。

5.2 常见的不生效原因排查

配了环境变量但不生效，原因基本就那几个：

Windows 上还有一个容易忽略的点：如果你装的是新版 ollama，它可能同时存在"用户变量"和"系统变量"两套，服务读的是系统变量。设的时候一定要在"系统变量"区域新建，不要设在"用户变量"里。

Linux 上如果用 systemd，改完 service 文件后必须daemon-reload，否则改动不生效。这个步骤很多人会漏。

5.3 验证通过后的日常使用建议

两个变量配好、验证通过之后，日常使用就顺畅了。几个建议：

模型统一放数据盘，定期看看磁盘占用，别等到满了才处理。可以用du -sh看目录大小。

如果模型多了，用ollama list定期清理不用的，ollama rm <模型名>删掉。

局域网暴露的话，记一下服务器 IP，最好在路由器上设个静态 IP 或者 DHCP 保留，免得 IP 变了所有客户端配置都要改。

如果后面要接 Dify、Open WebUI、FastAPI 这些，提前把OLLAMA_HOST配好，接的时候直接用服务器 IP 就行，不用再回头折腾。

6. 我踩过的几个坑和给你的实操建议

第一个坑是 Windows 上设了用户变量而不是系统变量。当时怎么都不生效，排查了半天才发现 ollama 服务读的是系统变量。这个坑很隐蔽，因为图形界面里"用户变量"和"系统变量"两个区域长得差不多，很容易设错。

第二个坑是 Linux 上改了.bashrc但 ollama 是 systemd 服务。shell 里echo $OLLAMA_MODELS能看到值，但服务就是不用。后来才明白 systemd 服务有自己的环境变量体系，得改 service 文件。

第三个坑是迁移模型的时候没停服务，复制到一半报文件占用。后来学乖了，迁移前先systemctl stop ollama，复制完再启动。

第四个坑是把OLLAMA_HOST设成了0.0.0.0但没写端口，结果 ollama 用了默认端口但绑定行为不符合预期。后来改成0.0.0.0:11434就正常了。

给你的建议就一条：装完 ollama，先别拉模型，先把OLLAMA_MODELS和OLLAMA_HOST配好、验证通过，再开始用。这十分钟的投入，能省掉后面几个小时的迁移和排查。模型文件动辄几十 GB，路径这种事一开始就定好，后面就不用折腾了。

如果你已经在用了但还没配这两个变量，现在改也不晚。停服务、迁模型、设变量、重启、验证，按 3.4 节的步骤走一遍就行。