别再把 Ollama 端口直接扔到公网了，赶紧用这个方法自测接口是否泄露

最近在帮几个朋友优化本地大模型部署时发现一个很普遍的误区：很多人为了方便在外部调用，直接把 Ollama 的 11434 端口映射到了公网，而且完全没有配置任何鉴权机制。这种操作本质上就是让自己的显存成了“公共资源”，任何知道你 IP 的人都能随意调用你的 API。

为了验证这个风险，我最近测试了一个叫 Ollama Scout 的扫描工具。这个工具的逻辑很简单，它通过扫描开放端口来确认目标是否运行了 Ollama。最让我警惕的是，一旦接口泄露，攻击者不需要复杂的权限，只需要请求 /api/tags 这个端点，就能瞬间拿到你服务器上加载的所有模型列表。这意味着你的硬件配置、运行的模型版本对外界完全透明，而且对方可以直接发送推理请求，迅速榨干你的显存资源，导致你自己的服务响应变慢甚至直接 OOM（内存溢出）。

如果你现在也把 Ollama 部署在云服务器上，建议立刻按照以下三个步骤进行一次安全自测。

第一步是基础的端口连通性检查。你不需要安装任何复杂工具，直接在外部网络环境下，打开终端执行一条简单的 curl 命令：curl http://<你的公网IP>:11434。如果终端直接返回了 Ollama is running 这句话，那么恭喜你，你的接口现在处于完全“裸奔”状态，全世界的扫描器都能在几秒钟内发现你。

第二步是使用像 Ollama Scout 这样的专业扫描工具进行深度验证。这类工具不仅检查端口是否开放，还会尝试调用 API 接口来确认服务状态。如果你在扫描结果中看到了自己的模型列表，说明你的 API 缺乏必要的身份验证，任何第三方应用都可以通过你的 IP 地址直接调用你的 Llama 3 或 Qwen 模型，而你对此毫无感知。

最后，针对发现的泄露问题，我建议采取两套加固方案。

方案一是对大多数人最友好的 Nginx 反向代理法。不要让 Ollama 直接面对公网，而是在前面挡一层 Nginx。在 Nginx 配置中加入 auth_basic 简单鉴权，给 API 加上用户名和密码。这样即使端口被扫描到，对方在没有账号密码的情况下也无法发起 /api/generate 等请求。

方案二是从网络层进行隔离。检查你的环境变量设置，如果你不需要全网访问，尽量不要将 OLLAMA_HOST 设置为 0.0.0.0，而是将其绑定到具体的内网 IP。如果必须公网访问，请务必在云服务器的安全组（Security Group）中配置白名单，仅允许你自己的固定 IP 访问 11434 端口，而不是对 0.0.0.0/0 全开放。

总结来说，部署大模型时，性能优化固然重要，但安全防护应该是第一优先级。一个简单的端口泄露，可能会让你的服务器变成别人的免费算力池。