简介：本资源是一份面向企业IT人员、AI开发者及安全工程师的DeepSeek大模型内网部署实战指南，聚焦于Ollama平台下的多客户端集成与全链路安全加固。针对金融、医疗等高敏行业对数据不出内网、模型可控可用的核心诉求，系统覆盖硬件选型（RTX 3090+/64GB内存）、跨平台Ollama安装配置、DeepSeek-R1等模型的在线/离线加载、Lobe Chat/Web界面与Lmstudio等四类主流客户端集成方案，并深入展开网络隔离、访问控制、RAG知识库搭建、模型防越狱及持续监控等安全实践。资源为单文件PDF文档（2.52MB），内容结构完整，含前置条件、分步操作、故障排查与性能调优等12个实操模块，目录层级清晰，便于按需查阅。目前已有311人学习下载，可直接用于内网LLM快速落地、安全合规评估与团队技术复用。
1. 内外网 DeepSeek 部署不是“装个软件就跑”，而是内网 AI 基建的起点：Ollama 多客户端集成 + RAG + 安全加固闭环落地
你有没有试过在客户内网机房里，对着一台没连外网的服务器，手握 32B 的 DeepSeek 模型文件，却卡在「ollama run」报错connection refused上整整两天？这不是玄学，是典型内网 LLM 落地失焦——只盯着模型下载，却漏掉了 Ollama 服务监听、客户端寻址、RAG 向量库路径绑定、防火墙策略这四道真实关卡。这篇实战笔记，就是我用三台不同配置的内网服务器（RTX 4090 / A100 40G / 无 GPU 仅 CPU）反复验证后沉淀下来的闭环方案：它不讲大模型原理，不堆参数公式，只解决一件事——让 DeepSeek 在你指定的那台物理机器上，被你指定的客户端，以你指定的安全策略，稳定响应你指定的知识库查询。核心链路清晰到可拆解：Ollama 作为本地模型运行时（Runtime），必须暴露可被内网其他节点访问的服务端点；Lobe Chat 或 Cherry-Studio 这类客户端，本质是 HTTP 客户端，它们调用的是 Ollama 的/api/chat接口，而非直接加载.gguf文件；RAG 不是插件，而是独立服务进程（如 ChromaDB），需与 Ollama 同步部署、跨容器网络互通；而所有这些环节，一旦脱离公网，环境变量、代理、端口映射、文件权限这四个细节，就是翻车高发区。适合谁？不是刚学 Python 的新手，而是已经能ssh进服务器、会看journalctl -u ollama日志、知道iptables -L输出含义的内网运维或 AI 工程师。如果你正为金融级内网合规要求发愁，或被医疗数据不出域的硬性约束卡住，这篇笔记里的每一步命令、每个配置项、每个避坑点，都来自真实压测现场。
2. Ollama 是内网 LLM 的心脏：安装、监听地址绑定与离线模型注入的底层逻辑
Ollama 不是传统意义的“应用软件”，它是专为本地大模型设计的轻量级运行时（Runtime）。它的核心价值在于：把.gguf模型文件抽象成标准 API 服务，屏蔽 CUDA 版本、量化格式、上下文长度等硬件差异。这意味着你在 RTX 3090 上跑通的deepseek-r1:32b，换到 A100 上只需改一个环境变量，无需重训、无需转换格式。但这个抽象层也带来关键约束：Ollama 默认只监听127.0.0.1:11434，即仅限本机访问。在内网多机协作场景下，这等于把心脏锁在保险柜里——客户端再漂亮也摸不到脉搏。因此，Ollama 的配置本质是三件事：启动服务、暴露端口、绑定模型路径。下面分操作系统展开，重点讲清「为什么必须这样配」，而非「怎么点下一步」。
2.1 Windows 环境：服务模式启动与 PowerShell 环境变量持久化
Windows 下 Ollama 安装包默认以 Windows Service 方式注册，这是双刃剑：服务自动启停省心，但环境变量无法被服务进程继承。若你只在 PowerShell 里执行$env:OLLAMA_HOST="0.0.0.0:11434"，重启后失效，因为服务进程读取的是系统级环境变量，而非当前 Shell 会话。
# 步骤1：停止现有 Ollama 服务（避免端口冲突） Stop-Service ollama # 步骤2：设置系统级环境变量（永久生效） [Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:11434", "Machine") [Environment]::SetEnvironmentVariable("OLLAMA_NUM_THREAD", "8", "Machine") # 绑定CPU核心数 # 步骤3：重启服务，强制加载新变量 Start-Service ollama # 步骤4：验证监听地址（关键！） netstat -ano | findstr :11434 # 正确输出应包含 0.0.0.0:11434，而非 127.0.0.1:11434提示：
OLLAMA_NUM_THREAD设置为 CPU 物理核心数的 70%~80%（如 16 核设为 12），过高会导致线程争抢，反而降低吞吐。Windows 服务模式下，OLLAMA_MODELS环境变量需指向绝对路径（如D:\ollama\models），相对路径会被解析为服务工作目录（通常是C:\Windows\System32），导致模型找不到。
2.2 Linux/macOS 环境：一行命令背后的守护进程与 systemd 配置
Linux/macOS 的curl -fsSL https://ollama.com/install.sh | sh实际做了三件事：下载二进制、创建/usr/bin/ollama符号链接、注册systemd服务。但默认ollama.service配置未声明环境变量，需手动修改：
# 编辑 systemd 服务文件 sudo systemctl edit ollama # 在打开的编辑器中输入以下内容（覆盖默认配置） [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_NUM_THREAD=16" Environment="OLLAMA_MODELS=/data/ollama/models" # 强烈建议挂载独立磁盘分区 Restart=always RestartSec=10# 重载配置并重启服务 sudo systemctl daemon-reload sudo systemctl restart ollama sudo systemctl status ollama # 检查状态，确认 Active: active (running) # 验证端口监听（Linux） sudo ss -tuln | grep :11434 # macOS 替代命令 sudo lsof -iTCP:11434 -sTCP:LISTEN注意：
OLLAMA_MODELS指向/data/ollama/models是生产环境黄金实践。原因有三：一是避免/home或/root分区空间不足（模型单个可达 20GB+）；二是便于rsync增量同步到备份机；三是 SELinux/AppArmor 等安全模块对/data分区策略更宽松，减少权限报错。
2.3 离线模型注入：从.gguf文件到ollama list可见的完整链路
内网环境无法ollama pull，必须手动注入。但直接复制.gguf文件到models/目录无效——Ollama 要求模型必须通过Modelfile注册，且文件名需符合规范。以nomic-embed-text-v1.5.f16.gguf为例：
# 步骤1：创建模型目录（按 Ollama 规范命名） mkdir -p /data/ollama/models/nomic-embed-text-v1.5.f16 # 步骤2：将 .gguf 文件放入该目录 cp /path/to/nomic-embed-text-v1.5.f16.gguf /data/ollama/models/nomic-embed-text-v1.5.f16/ # 步骤3：编写 Modelfile（关键！必须在模型目录内执行） cd /data/ollama/models/nomic-embed-text-v1.5.f16 cat > Modelfile << 'EOF' FROM ./nomic-embed-text-v1.5.f16.gguf PARAMETER num_ctx 8192 PARAMETER stop "<|eot_id|>" EOF # 步骤4：构建模型（此时才真正生成 Ollama 内部索引） ollama create nomic-embed-text-v1.5.f16 -f ./Modelfile # 步骤5：验证（输出应包含 nomic-embed-text-v1.5.f16） ollama list逻辑说明：
Modelfile中FROM指令告诉 Ollama 加载哪个.gguf文件；PARAMETER指令覆盖模型默认参数（如num_ctx控制上下文长度，stop定义 EOS token）。若跳过Modelfile直接复制，Ollama 启动时会报model not found，因为它依赖内部 SQLite 数据库存储模型元数据，而ollama create才触发元数据写入。
2.4 网络穿透验证：用 curl 模拟客户端，绕过 GUI 黑匣子
所有客户端（Lmstudio/Lobe Chat）最终都调用 Ollama 的 REST API。在 GUI 连接失败时，用curl直接测试是最高效的排障手段：
# 测试 Ollama 服务是否存活（返回 {} 表示健康） curl -X GET http://192.168.1.100:11434/api/tags # 测试模型是否加载成功（替换 your-model-name 为实际模型名） curl -X POST http://192.168.1.100:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:32b", "messages": [{"role": "user", "content": "你好"}], "stream": false }' | jq '.message.content' # 关键参数说明： # - `http://192.168.1.100:11434`：必须是内网其他机器能 ping 通的 IP，非 127.0.0.1 # - `"stream": false`：禁用流式输出，便于调试；生产环境建议设为 true 提升体验 # - `jq '.message.content'`：解析 JSON 提取响应文本，避免日志刷屏血泪经验：若
curl返回Connection refused，90% 是OLLAMA_HOST未设为0.0.0.0或防火墙拦截；若返回Model not found，则是模型名拼写错误（区分大小写）或ollama create未执行成功；若返回空内容，检查stop参数是否与模型实际 EOS token 匹配（DeepSeek-R1 常用<|eot_id|>）。
3. 多客户端不是“哪个好看选哪个”，而是按内网角色分工：Lobe Chat 做 Web 门户，Cherry-Studio 做研发沙盒，Lmstudio 做模型调试台
客户端选择不是审美问题，而是内网角色分工问题。Lobe Chat 的 Web 架构天然适配内网统一入口，Cherry-Studio 的 Markdown 渲染和流式输出是研发人员调试 prompt 的刚需，而 Lmstudio 的模型参数实时调节面板，是验证量化精度损失的唯一可视化工具。三者不是互斥，而是互补。下面给出各客户端在内网环境下的最小可行配置（MVP），去掉所有花哨功能，只保留连接 Ollama 的核心路径。
3.1 Lobe Chat：Docker 部署的 Web 门户，必须加 HTTPS 和访问密码
Lobe Chat 是唯一推荐用于企业内网正式环境的客户端，因其 Web 架构支持集中认证、审计日志、URL 权限控制。但裸奔 HTTP 是安全红线，必须通过 Nginx 反向代理强制 HTTPS。
# 步骤1：创建 lobe-chat 部署目录 mkdir -p /opt/lobe-chat && cd /opt/lobe-chat # 步骤2：创建 .env 文件（关键安全配置） cat > .env << 'EOF' # 必须设置！否则任何人可访问你的 LLM ACCESS_CODE=your-super-secret-password-2024 # Ollama 地址必须是内网可解析的域名或 IP（不能是 localhost！） OLLAMA_BASE_URL=http://192.168.1.100:11434 # 指定默认模型（确保该模型已通过 ollama list 可见） OLLAMA_API_MODEL=deepseek-r1:32b # 启用 RAG 支持（需提前部署 ChromaDB） ENABLE_RAG=true RAG_VECTOR_DB_URL=http://192.168.1.101:8000 # ChromaDB 服务地址 EOF # 步骤3：启动（自动拉取镜像并运行） docker-compose up -d # 步骤4：验证容器状态 docker ps | grep lobe-chat # 应看到 lobe-chat-web 和 lobe-chat-api 两个容器均 running参数说明：
ACCESS_CODE是基础访问控制，但仅防君子；OLLAMA_BASE_URL若填http://localhost:11434，则容器内网络无法访问宿主机 Ollama（Docker 默认桥接网络隔离）；ENABLE_RAG=true会激活前端 RAG 上传按钮，但后端需单独部署 ChromaDB 并配置RAG_VECTOR_DB_URL。
3.2 Cherry-Studio：本地桌面客户端，专注研发调试的流式输出与 Markdown 渲染
Cherry-Studio 的核心价值在于：实时显示 token 生成过程、渲染 Markdown 表格/代码块、支持自定义 system prompt。这对调试 RAG 检索结果、验证模型指令遵循能力至关重要。
# Windows 安装后，首次启动需手动配置： # 1. 点击左下角齿轮图标 → Settings → Model Provider → Ollama # 2. Server URL 填写：http://192.168.1.100:11434 （必须是内网 IP） # 3. Model Name 填写：deepseek-r1:32b （必须与 ollama list 输出完全一致） # 4. Advanced Settings → Enable Streaming：✅（必开！看 token 逐字生成） # 5. Advanced Settings → Response Format：Markdown（必开！渲染表格） # Linux/macOS 启动后，在终端执行以下命令验证连接（替代 GUI） curl -X POST http://192.168.1.100:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:32b", "messages": [ {"role": "system", "content": "你是一个严谨的代码审查助手"}, {"role": "user", "content": "请分析以下 Python 代码的内存泄漏风险：def load_data(): return [i for i in range(1000000)]"} ], "stream": true }' | grep -E '"content":"|token_count'避坑点：Cherry-Studio 的
Model Name必须与ollama list输出的 NAME 列完全一致（含冒号和版本号），少一个字符都会报model not found；stream: true时，响应是 SSE 格式，grep过滤可快速确认 token 是否正常流动。
3.3 Lmstudio：模型调试台，用 GUI 实时调节 temperature/top_p 验证量化效果
Lmstudio 是唯一提供图形化参数调节面板的客户端，其价值在于：无需改代码，拖动滑块即可对比不同 temperature 下的输出稳定性。这对评估 4-bit 量化模型（如deepseek-r1-abliterated:32b）的精度损失极其高效。
# 启动 Lmstudio 后，关键配置步骤： # 1. Local Server → Connection → Server Address: http://192.168.1.100:11434 # 2. Model → Select Model → deepseek-r1-abliterated:32b # 3. Parameters → Temperature: 0.7（默认值，偏保守） # 4. Parameters → Top P: 0.9（平衡多样性与连贯性） # 5. Parameters → Max Tokens: 2048（避免长文本截断） # 执行对比测试（同一问题，不同 temperature）： # Q: "请用 Python 写一个快速排序算法，并解释时间复杂度" # T=0.1：输出严格遵循教科书，但缺乏示例 # T=0.9：输出包含自定义测试用例，但可能引入错误注释 # 结论：内网生产环境建议 T=0.3~0.5，平衡准确性与实用性注意：Lmstudio 的
Server Address必须填 Ollama 服务器的内网 IP，填localhost会导致连接超时（因 Lmstudio 运行在用户桌面，非 Docker 容器内）；其参数调节仅影响本次请求，不改变模型本身，是安全的沙盒环境。
4. RAG 不是“加个插件”，而是独立服务：ChromaDB 部署、向量嵌入与知识库热更新的三步闭环
RAG（Retrieval-Augmented Generation）在内网不是锦上添花的功能，而是解决「模型幻觉」和「知识过期」的核心机制。但很多教程把它讲成黑匣子——其实只有三步：1) 部署向量数据库（ChromaDB）；2) 用嵌入模型（如nomic-embed-text）将文档转为向量；3) 将向量存入 ChromaDB 并建立检索索引。下面给出生产级最小部署方案，所有组件均在内网运行，不依赖任何云服务。
4.1 ChromaDB 服务部署：Docker 单节点，禁用匿名访问
ChromaDB 默认启用匿名访问，这在内网是严重安全隐患。必须通过--chroma-db-settings-anonymous-telemetry=false禁用遥测，并用--chroma-db-settings-allow-anonymous-access=false强制认证。
# 创建 ChromaDB 部署目录 mkdir -p /opt/chroma-db && cd /opt/chroma-db # 启动 ChromaDB（单节点，数据持久化到 /data/chroma） docker run -d \ --name chroma-db \ -p 8000:8000 \ -v /data/chroma:/chroma/chroma_db \ -e CHROMA_DB_IMPL=duckdb+parquet \ -e CHROMA_SERVER_AUTH_CREDENTIALS_FILE=/chroma/auth/credentials.yaml \ -v $(pwd)/auth:/chroma/auth \ -e CHROMA_SERVER_AUTH_PROVIDER=chromadb.auth.basic_authn.BasicAuthClientProvider \ -e CHROMA_SERVER_AUTH_CREDENTIALS_PROVIDER=chromadb.auth.basic_authn.BasicAuthCredentialsProvider \ -e CHROMA_SERVER_AUTHN_ENABLED=true \ -e CHROMA_SERVER_AUTHZ_ENABLED=true \ -e CHROMA_SERVER_AUTHZ_PROVIDER=chromadb.auth.simple_authz.SimpleAuthzProvider \ -e CHROMA_SERVER_AUTHZ_CONFIG_FILE=/chroma/auth/permissions.yaml \ -v $(pwd)/auth:/chroma/auth \ --restart=always \ --network=host \ ghcr.io/chroma-core/chroma:latest # 创建认证文件（必须！） mkdir -p auth cat > auth/credentials.yaml << 'EOF' users: - username: "admin" password_hash: "$2b$12$..." # 用 bcrypt 工具生成 EOF cat > auth/permissions.yaml << 'EOF' roles: - name: "admin" permissions: - resource: "collection:*" action: "*" EOF逻辑说明：
--network=host让 ChromaDB 直接使用宿主机网络，避免 Docker 网络 NAT 延迟；CHROMA_SERVER_AUTHN_ENABLED=true启用认证；credentials.yaml中的password_hash需用bcrypt命令生成（htpasswd -B -n admin），明文密码不可接受。
4.2 文档向量化：用 Ollama 嵌入模型批量处理 PDF/DOCX
ChromaDB 本身不处理文档，需外部程序将文档切块并转为向量。Ollama 提供的nomic-embed-text模型是内网首选——无需 Python 环境，纯 HTTP 调用。
# 步骤1：安装 pdf2text（Linux）或 Poppler（macOS）提取 PDF 文本 # Ubuntu sudo apt install poppler-utils # 步骤2：编写向量化脚本（vectorize.sh） cat > vectorize.sh << 'EOF' #!/bin/bash # 从 PDF 提取文本并分块 pdf2txt.py -o /tmp/doc.txt "$1" # 按段落切块（每 500 字符为一块） awk 'BEGIN{RS="\n\n"; ORS="\n\n"} {if(length($0)>500) print substr($0,1,500); else print $0}' /tmp/doc.txt > /tmp/chunks.txt # 调用 Ollama 嵌入模型生成向量 while IFS= read -r chunk; do [[ -z "$chunk" ]] && continue response=$(curl -s -X POST http://192.168.1.100:11434/api/embeddings \ -H "Content-Type: application/json" \ -d "{\"model\": \"nomic-embed-text-v1.5.f16\", \"prompt\": \"$chunk\"}") # 提取向量（JSON 解析） vector=$(echo $response | jq -r '.embedding') # 存入 ChromaDB（简化版，实际用 Python client） echo "Chunk: $chunk | Vector: $vector" >> /tmp/vectors.log done < /tmp/chunks.txt EOF chmod +x vectorize.sh ./vectorize.sh /path/to/manual.pdf参数说明：
pdf2txt.py是pdfminer工具，比pdftotext更准确处理扫描版 PDF；RS="\n\n"设置 awk 记录分隔符为双换行，实现按段落切块；jq -r '.embedding'提取嵌入向量数组，后续需用 Python 调用 ChromaDB SDK 插入。
4.3 RAG 知识库热更新：用 Python 脚本实现增量索引与去重
手动插入向量效率低下，需 Python 脚本自动化。核心是chromadb.HttpClient连接内网 ChromaDB，并实现「文档哈希去重」和「增量更新」。
# rag_update.py import chromadb import hashlib from chromadb.utils import embedding_functions # 连接内网 ChromaDB（带认证） client = chromadb.HttpClient( host="192.168.1.101", port=8000, settings=chromadb.Settings( chroma_client_auth_provider="chromadb.auth.basic_authn.BasicAuthClientProvider", chroma_client_auth_credentials="admin:your-password" ) ) # 创建集合（collection） embedding_func = embedding_functions.OllamaEmbeddingFunction( url="http://192.168.1.100:11434/api/embeddings", model_name="nomic-embed-text-v1.5.f16" ) collection = client.create_collection( name="internal_knowledge", embedding_function=embedding_func, metadata={"hnsw:space": "cosine"} ) # 读取文档并计算哈希（避免重复索引） def get_doc_hash(filepath): with open(filepath, "rb") as f: return hashlib.md5(f.read()).hexdigest() # 增量更新逻辑 doc_hash = get_doc_hash("/path/to/manual.pdf") if doc_hash not in collection.get()["metadatas"]: # 读取文本并切块 with open("/tmp/chunks.txt", "r") as f: chunks = f.readlines() # 批量嵌入并添加 collection.add( documents=chunks, metadatas=[{"source": "manual.pdf", "hash": doc_hash} for _ in chunks], ids=[f"chunk_{i}_{doc_hash}" for i in range(len(chunks))] ) print(f"Added {len(chunks)} chunks from {filepath}") else: print("Document already indexed, skipping...")避坑点：
chromadb.HttpClient的host必须是 ChromaDB 服务的内网 IP（非localhost）；embedding_functions.OllamaEmbeddingFunction的url必须指向 Ollama 服务地址；collection.add()的ids必须全局唯一，用hash+chunk_index组合可保证。
5. 安全加固不是“加个密码”，而是七层纵深防御：从网络隔离到模型哈希校验的实操清单
内网不等于安全网。Ollama 默认无认证、ChromaDB 默认匿名访问、Lobe Chat 默认 HTTP 明文传输——这些设计在公网是便利，在内网就是漏洞。安全加固必须是七层纵深防御：网络层（防火墙）、传输层（HTTPS）、应用层（反向代理认证）、服务层（Ollama 访问控制）、模型层（哈希校验）、系统层（SELinux）、数据层（加密存储）。下面给出每层可立即落地的命令和配置，拒绝空泛原则。
5.1 网络层：iptables 规则锁定 Ollama 和 ChromaDB 端口
在 Ollama 服务器上，仅允许指定 IP 访问11434（Ollama）和8000（ChromaDB），其他所有端口默认 DROP。
# 清空现有规则（谨慎！先保存） sudo iptables-save > /root/iptables-backup-$(date +%F) # 允许本地回环 sudo iptables -A INPUT -i lo -j ACCEPT # 允许已建立连接 sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 仅允许内网管理网段（192.168.1.0/24）访问 Ollama 和 ChromaDB sudo iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 11434 -j ACCEPT sudo iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 8000 -j ACCEPT # 允许 SSH（假设管理端口为 22） sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT # 默认拒绝所有其他入站 sudo iptables -P INPUT DROP # 保存规则（Ubuntu/Debian） sudo iptables-save | sudo tee /etc/iptables/rules.v4 # CentOS/RHEL sudo service iptables save提示：
-s 192.168.1.0/24限定源 IP 段，比-s 192.168.1.100更灵活；--dport必须与OLLAMA_HOST绑定的端口一致；-P INPUT DROP是最后防线，务必在允许规则后执行。
5.2 传输层：Nginx 反向代理强制 HTTPS，终止 SSL 于边缘
Lobe Chat 和 ChromaDB 均不原生支持 HTTPS，必须用 Nginx 终止 SSL。证书用内网 CA 签发，避免浏览器警告。
# /etc/nginx/conf.d/lobe-chat.conf server { listen 443 ssl http2; server_name lobe.internal; # SSL 证书（由内网 CA 签发） ssl_certificate /etc/nginx/ssl/lobe.internal.crt; ssl_certificate_key /etc/nginx/ssl/lobe.internal.key; # 强制 HSTS add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; location / { proxy_pass http://127.0.0.1:3010; # Lobe Chat 容器端口 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } # /etc/nginx/conf.d/chroma.conf server { listen 443 ssl http2; server_name chroma.internal; ssl_certificate /etc/nginx/ssl/chroma.internal.crt; ssl_certificate_key /etc/nginx/ssl/chroma.internal.key; location / { proxy_pass http://192.168.1.101:8000; # ChromaDB 服务 IP proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意：
proxy_pass指向127.0.0.1:3010是因为 Lobe Chat 容器与 Nginx 同在一台宿主机；proxy_pass指向192.168.1.101:8000是因为 ChromaDB 部署在另一台服务器，需走内网路由。
5.3 应用层：Nginx Basic Auth 为 Ollama 添加第一道门禁
Ollama 本身无认证，必须用 Nginx 添加 Basic Auth。密码文件用htpasswd生成，密钥强度必须达标。
# 生成密码文件（-B 使用 bcrypt，-C 使用 SHA-256） sudo htpasswd -B -c /etc/nginx/.ollama-htpasswd admin # /etc/nginx/conf.d/ollama-auth.conf upstream ollama_backend { server 127.0.0.1:11434; } server { listen 8080; server_name ollama.internal; auth_basic "Ollama Restricted Access"; auth_basic_user_file /etc/nginx/.ollama-htpasswd; location / { proxy_pass http://ollama_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }避坑点：
htpasswd -B生成 bcrypt 密码，比默认 MD5 更安全；listen 8080避免与默认 HTTP 端口冲突；客户端连接 Ollama 时，URL 改为http://admin:password@ollama.internal:8080（不推荐明文密码，应配合 OAuth2）。
5.4 模型层：SHA256 哈希校验，杜绝模型文件被篡改
从可信源下载的.gguf文件，必须在导入前校验哈希。Ollama 不提供校验功能，需手动比对。
# 步骤1：获取官方哈希（假设官网提供） # 官网 SHA256: a1b2c3... (32 bytes) # 步骤2：计算本地文件哈希 sha256sum /data/ollama/models/deepseek-r1-abliterated:32b/deepseek-r1-abliterated.Q4_K_M.gguf # 步骤3：比对（脚本化） EXPECTED_HASH="a1b2c3..." ACTUAL_HASH=$(sha256sum /data/ollama/models/deepseek-r1-abliterated:32b/deepseek-r1-abliterated.Q4_K_M.gguf | cut -d' ' -f1) if [ "$EXPECTED_HASH" = "$ACTUAL_HASH" ]; then echo "✓ Model hash verified" ollama create deepseek-r1-abliterated:32b -f /data/ollama/models/deepseek-r1-abliterated:32b/Modelfile else echo "✗ Model hash mismatch! Delete and re-download." exit 1 fi逻辑说明：
cut -d' ' -f1提取sha256sum输出的第一列（哈希值）；EXPECTED_HASH应从模型发布页复制，而非第三方镜像站；若哈希不匹配，立即删除文件并重新下载，不可跳过。
6. 故障排查不是“百度一下”，而是按 OSI 模型逐层定位：从物理层连通性到应用层 token 生成的五步诊断法
当客户端报错Failed to connect to Ollama，新手常陷入“重装 Ollama”循环。老手则按 OSI 模型五层诊断：1) 物理层（网线/IP）→ 2) 网络层（ping/firewall）→ 3) 传输层（telnet/port）→ 4) 应用层（curl/API）→ 5) 数据链路层（token 流）。下面给出每层必查命令和预期输出，形成肌肉记忆。
6.1 物理层诊断：确认客户端与 Ollama 服务器在同一个二层网络
# 客户端执行（Windows） ping 192.168.1.100 # Linux/macOS ping -c 4 192.168.1.100 # 预期输出： # Reply from 192.168.1.100: bytes=32 time<1ms TTL=64 # 若超时，检查： # - 客户端和服务器是否在同一 VLAN（交换机配置） # - 服务器是否禁用了 ICMP（Windows 防火墙高级设置 → 入站规则 → 文件和打印机共享） # - IP 地址是否配置正确（`ipconfig` / `ifconfig <p> <a href="https://download.csdn.net/download/weixin_39682092/90404002" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>
