7.1 网络配置与远程访问
7.1 网络配置与远程访问
本节摘要：Ollama 默认只听本机回环地址，想让它被局域网或另一台机器使用，需要动三个环境变量：
OLLAMA_HOST决定监听在哪、OLLAMA_ORIGINS决定谁能在浏览器里调它、代理变量决定它自己怎么出网拉模型。本节给出三种典型拓扑的配置写法、跨域与反向代理的实务做法，以及各操作系统的生效位置。
默认行为与三个关键变量
装好后服务只绑定 127.0.0.1:11434，局域网扫描不到它——这是刻意为之的保守默认。开放给他人前，先认识三个变量：
OLLAMA_HOST：监听地址与端口。0.0.0.0:11434对所有网卡开放；:8000换端口。OLLAMA_ORIGINS：允许的 CORS 来源。浏览器网页要直连 Ollama 时必须把页面域名加进来。HTTPS_PROXY/NO_PROXY：服务自身出网（拉模型、查更新）走的代理。
# Linux 临时实验：全网卡监听 OLLAMA_HOST=0.0.0.0 ollama serve # systemd 持久化（生产写法） sudo systemctl edit ollama # 写入： # [Service] # Environment="OLLAMA_HOST=0.0.0.0:11434" sudo systemctl restart ollama
macOS 桌面版改配置的地方是 launchctl setenv OLLAMA_HOST 0.0.0.0 后重启应用；Windows 则在系统环境变量里加 OLLAMA_HOST 再退出托盘图标重开服务。验证监听是否生效：
ss -tlnp | grep 11434 # Linux 查监听地址 curl http://<内网IP>:11434/ # 从另一台机器探活
客户端怎么连过来
三种客户端各有写法。CLI 用 OLLAMA_HOST 指向远端，本机命令全部代理过去；SDK 在构造时传 host；浏览器端受 CORS 约束，需要服务端放行来源：
# 1) CLI 远程 OLLAMA_HOST=192.168.1.20:11434 ollama run qwen2.5:7b "hi" # 2) 浏览器页面直连（比如自建的前端） OLLAMA_ORIGINS="http://chat.internal.example,http://localhost:5173" ollama serve
// 3) SDK 远程 import { Ollama } from "ollama"; const ollama = new Ollama({ host: "http://192.168.1.20:11434" });
注意一个高频故障：域名带端口或协议不符的来源写法（缺 http://、混用尾斜杠）都会让放行失效，排查时直接看浏览器控制台的 CORS 报错信息。
反向代理：生产拓扑的标准件
直接暴露 11434 没有任何认证（下一节细谈），团队共用的正路是前面架一层 Nginx：加基础认证、限速、统一日志，顺便解决 HTTPS：
server { listen 443 ssl; server_name llm.example.com; ssl_certificate /etc/nginx/certs/llm.pem; ssl_certificate_key /etc/nginx/certs/llm.key; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; # 流式响应必须关缓冲，否则打字机效果会卡成整段吐出 proxy_buffering off; proxy_read_timeout 3600s; # 长生成不断线 } }
# 自签证书 + 基础认证的一揽子工具 htpasswd -c /etc/nginx/.htpasswd alice sudo nginx -t && sudo systemctl reload nginx # 客户端走域名 curl -u alice:*** https://llm.example.com/api/tags
公网访问强烈建议再加一层 WireGuard 或 SSH 隧道，让 443 也只对内网网段开放——模型服务暴露在公网等于把一张不限量的 GPU 算力券挂在门口：
# 最简隧道：把远端服务映射到本机 ssh -N -L 11434:127.0.0.1:11434 user@gpu-box # 之后本机的 localhost:11434 即远端服务，无需任何其他改动
出网方向：让服务自己能拉模型
内网机器常遇到拉模型失败，原因几乎都是服务进程没有代理可用。systemd 环境下代理变量同样写在 override 里；Docker 环境则在 docker run 时 -e HTTPS_PROXY=...。企业环境把 NO_PROXY 设为内部镜像源域名，可以让拉取走内网 registry 而其余流量走代理。
排障清单按序执行：本机 curl localhost:11434 → 服务端 ss -tlnp 看绑定 → 客户端到服务的 curl <ip>:11434 → 防火墙（ufw status / 安全组）→ 跨域报错查 OLLAMA_ORIGINS。五步之内必能定位。
远程场景还有两个易漏项。一是 keep_alive 与带宽的交互：移动端通过蜂窝网络访问家里的服务，生成是流式的没问题，但若每问一句都触发重新加载（远程调用方忘了带 keep_alive），等待会被拉长到分钟级，给这类客户端固定传 "keep_alive": "1h" 是廉价保险。二是日志与证书续期：自签证书有过期日，反向代理层挂个定时任务用 acme.sh 之类的工具自动续签，比每次过期后救火体面得多。
网络通了、访问有了边界，下一节把安全性展开讲透：模型即数据的泄露风险、提示词注入、以及如何给 API 层加闸门。