让 Ollama 只用本地能力：关闭云功能后还要检查哪些连接

先画出实际的数据路径 一个聊天界面可能同时连接本地模型、远程检索服务和在线文件解析工具。模型在电脑上运行，只能说明推理链路的一部分。因此建议从用户输入出发，列出前端、Ollama、工具与存储分别连接哪里，再确定哪些连接必须保留，哪些应关闭。 Ollama 提供的本地模式开关 官方 FAQ 支持在 ~/.ollama/server.json 中设置 disable_ollama_cloud，也支持环境变量 OLLAMA_NO_CLOUD=1。变更后需要重启服务，日志中可核对云功能已关闭的状态。文档说明，这会同时失去 Ollama 云模型与 web search 能力。 不要只检查设置文件已经写入。环境变量要进入真正运行服务的进程；桌面应用、终端启动和系统服务的配置途径可能不同。验收应包含重启后的状态，以及应用是否还能完成预期的本地任务。 按实际启动方式让配置生效 如果使用配置文件，在 ~/.ollama/server.json 的现有 JSON 对象中加入 "disable_ollama_cloud": true，保留其他设置并检查 JSON 仍合法。这里的路径属于实际运行服务的用户；容器或专用服务账号不一定读取你当前登录账号的目录。 如果使用环境变量，先确认服务由谁启动。macOS 桌面应用可按官方方式执行 launchctl setenv OLLAMA_NO_CLOUD "1"，然后退出并重新启动应用；手动启动的进程可在设置变量后重新运行 ollama serve。Linux 的 systemd 服务则需要把变量放进服务配置并重载、重启，不能仅在另一个终端 export 后认为服务已经改变。 重启后在日志中寻找 Ollama cloud disabled: true，再测试一个已下载的本地模型。开关写入、服务读取与本地任务可运行，是三个分别检查的结果；如果端口冲突导致新服务没有启动，应先解决启动失败，不要把旧进程的输出当成新配置的验证。 区分推理、下载和外部工具 本地模式不代表模型权重已经存在。首次准备模型仍需按部署方案取得所需文件，之后再验证离线环境中的实际调用。本文也建议对应用中的搜索、网页读取、远程知识库和文件上传做一次清点；这些连接可能由其他组件发出，并不受 Ollama 的云功能开关管理。 可以准备一条只需本地模型的问题，再准备一条原本依赖联网工具的问题。前者应继续完成，后者应明确表示缺少外部能力。若后者仍访问了网络，应检查具体发起请求的组件，而不是立即判定 Ollama 开关失效。 离线验收要测实际应用 先关闭应用不需要的联网功能，在隔离测试中限制外部网络，再通过平时使用的前端提交一条本地任务。观察模型回答之外，附件解析、历史保存和页面资源是否仍然正常。接着调用一个明确依赖外网的工具，确认它报告能力不可用，没有悄悄切换到另一项远程服务。 如果只测试终端对话，最多验证了这条调用路径；不能据此推断网页前端、浏览器扩展或后端自动任务都离线。记录失败发生在哪个组件，比反复切换 Ollama 的同一个开关更能解决问题。这里的断网测试是部署验收方法，不是要求日常使用始终断网。 服务入口也属于部署边界 FAQ 说明默认服务绑定本机回环地址，OLLAMA_HOST 可以调整监听位置。把地址改成面向局域网以后，使用者范围就发生变化。编辑建议是同时记录调用方与网络入口，并通过部署层控制访问，而不是只关注模型是否联网。 完成后的记录 保留运行方式、配置位置、重启确认、模型清单和外部组件清单。升级或替换聊天前端后复查一次，因为整个系统的连接行为可能随组件改变。这份记录用于说明实际连接边界；涉及特定组织要求时，还需按自己的完整部署进行验收。

本篇涉及的工具1

Ollama

关闭自身云能力并核对本地推理路径

适合场景

希望明确本地推理边界、控制应用外部连接的团队。

需要留意

其他前端、工具与下载链路需要分别检查。

了解项目 访问官网