Ollama默认安全吗？显卡被白嫖的真相与自查指南

默认监听：安全，但只是一层纸

很多人以为装了 Ollama 就等于把显卡挂到了公网上，其实不然。Ollama 默认只绑定在回环地址（127.0.0.1），这个地址的请求不会真正进入网线，同一局域网的其他设备、互联网上的扫描器都看不到这个端口。换句话说，默认配置下，你的模型服务是关在私人房间里的。

但这层保护不是密码，而是一条设置。它只听一个地址，改掉这句话，房间的门就开了。

回环地址（127.0.0.1） 是 IPv4 地址空间中专门划定的一段（127.0.0.0/8）用于本机通信的地址，其中 127.0.0.1 最为常用，别名 localhost。发往该地址的数据包不会经过任何物理网卡，而是由操作系统内核在本地直接回送，因此局域网中的其他设备与互联网上的扫描器都无法触及。与之对应的是 0.0.0.0，它是一个通配地址，在服务端监听场景中表示「绑定本机所有网络接口」——包括有线网卡、无线网卡、虚拟网卡（如 Docker 的 bridge 接口）乃至 VPN 虚拟接口。二者语义截然不同：127.0.0.1 是「只和自己说话」，0.0.0.0 是「对每条网线都敞开」。理解这一区别是判断 Ollama 是否暴露的关键。

暴露的源头：一句环境变量

为了让另一台设备也能用上模型，很多人会修改环境变量，把监听地址设为 0.0.0.0。这串零不代表某一个地址，它的意思是：有线网卡、无线网卡、虚拟机网卡，全部监听。这一句一改，端口就从“只有本机”变成“同一网络里谁都能连”。如果这台机器还有公网地址，那就是整个互联网都能连。

更少人注意到的是，官方 Docker 镜像里这句话是已经写好的。你在服务器上照着文档敲一条 Docker 命令，容器内部默认就是全零监听，不需要你动任何配置。

也就是说，暴露往往不是因为你胆子大，而是因为你照抄了一条看起来最正常的安装命令。而 Ollama 的本地接口没有身份验证层。官方文档的原话是，本地 API 不需要认证。没有账号，没有密钥，没有白名单。能不能用，只取决于一件事：能不能连到这个端口。

问题的位置要说准——不是软件危险，是监听地址这句设置把它从私人房间挪到了走廊上。

白嫖长什么样：一次普通的网页请求

有人在扫描结果里挑中你的地址，往你的端口上发一条请求，让某个模型回答一句话。请求里不带任何凭证，因为本来也不需要。你的机器收到请求，把模型从硬盘读进显存，开始计算，算完把结果从网线送回去。对方一分钱没付，你的显卡忙了几秒钟。

让成本更难看的是，模型算完不会马上退出显存，默认还要留五分钟等下一个请求。这五分钟里，后续请求都不用重新加载模型，可以直接开算。于是一个接一个的请求，就能把这五分钟一直续下去。当你打开 ollama ps 看到那张表——模型名、占多大、跑在显卡还是内存里、还有多久——被白嫖时，表里会多出你根本没在用的模型。

同一个端口能做的事也不只是生成文字。列出你装了哪些模型、下载新模型塞满硬盘、删掉你的模型，都是这台机器上同一个接口的不同地址。所以更准确的说法不是显卡被偷走了，而是这台机器上那个不收钱的推理服务被别人当成了免费额度。

规模与路径：从公网扫描到 DNS 重绑定

公开扫描数据说明这不是个例。据安全公司 Sensys 的观测，2025 年用高置信度方法找到约一万零六百台对公网开放的实例，其中一千五百台会对普通提问直接给出回答；另一份跨度更长的观察在 293 天里累计出现过 17.5 万台，分布在 130 个国家。两个数字口径不同不能相加，但指向同一件事：这些机器里很大一部分就在家庭宽带和普通云主机上。

「我没有公网地址，也没开端口转发，应该没事吧？」同一台路由器下的设备可以直接连到这个端口。一旦监听所有网卡，同一个 WiFi 里的电脑、电视、被入侵过的机器，都不需要任何技巧。还有一条更绕的路：你只是打开了一个网站。浏览器本来不许一个网站的脚本去连你本机上的服务，绕开它的手法叫 DNS 重绑定——攻击者控制一个域名，先解析到自己的服务器让页面正常加载，再把同一个域名改成指向你的本机。浏览器按域名判断是否同源，域名没变，于是放行，请求实际落在了你电脑里的服务上。

据相关研究记录，Ollama 曾修复过一个此类漏洞，但后续研究指出同类问题仍在，且触发条件更日常：只要绑定地址不是回环，它就会跳过对请求主机名的校验。一次典型事件出在一个叫 NemoCloud 的部署工具上——它为了让沙箱容器能连到宿主主机，主动把 Ollama 绑到了全零地址，安装时屏幕上写的是「正在使用本机的 Ollama」，实际监听的却是所有网卡。一个网页被访问，就能改掉模型定义里的对话模板，让之后每次对话都悄悄夹带攻击者写的一句指令。

所以「我只在本机用」要成立，得同时满足两件事：真的只绑在回环地址上，以及版本没有已知的绕过。少一样都不算。

DNS 重绑定（DNS Rebinding） 是一种绕过浏览器同源策略（Same-Origin Policy）的攻击手法。浏览器的同源策略以「协议 + 域名 + 端口」为判断依据，而非实际的 IP 地址，攻击者正是利用这一弱点。典型流程是：攻击者控制一个域名，将其 TTL（生存时间）设得极短；用户访问恶意页面时，该域名先解析到攻击者自己的服务器，页面正常加载；随后域名记录被切换为指向用户本机（如 127.0.0.1）；由于域名未变，浏览器仍认为请求同源，于是放行，脚本的请求实际落在了用户本机运行的服务上。防御的关键在于服务端校验请求的 Host 头，拒绝非预期的域名——这也是文中提到 Ollama 在绑定非回环地址时跳过主机名校验所带来风险的根源。

三步自查与三层修复

自查只要两步。 第一步，看它到底在听谁：Linux 上用 ss 命令过滤那个端口，看前面的地址是本机回环还是那串零；Mac 上换成 lsof 加端口号，看的是同一件事。第二步，从另一台设备访问这个端口——连得上就是真的暴露了，连不上才叫只有本机。

修复分三个层次。 最省事的，是把绑定改回本机回环，或在桌面版设置里关掉向网络暴露。如果确实需要别的设备用，就别把机器直接裸在网上，前面放一个要口令的反向代理，或者干脆用 VPN、SSH 隧道把端口带过去。如果你用 Docker，记住容器里那句环境变量不是默认的回环，跑之前先把它改掉，端口映射也只映射到本机回环。

说到底，真正被白嫖的不是显卡本身，是那个没有门、又开在公共走廊上的接口。把门关上，或者至少别开在走廊上。

反向代理 是部署在客户端与后端服务之间的中间层，所有外部请求先到达代理，再由代理转发给本机服务。它在这里的价值在于补上 Ollama 缺失的认证与访问控制：常见做法是用 Nginx 或 Caddy 配置 HTTP Basic Auth 或基于 Token 的鉴权，并只将代理端口对外暴露，Ollama 本身继续绑定在 127.0.0.1。SSH 隧道 则借助 SSH 协议的端口转发能力，把远端机器的端口映射到本地，无需开放任何额外端口，适合临时或点对点使用；VPN 则把设备纳入同一虚拟私有网络，使访问仅对已认证成员可见。三者共同点是把「谁能连到端口」这一唯一防线，换成「先通过身份验证才能连到端口」。