【技术底稿 23】Ollama + Docker + Ubuntu 部署踩坑实录：网络通了，参数还在调

下午5点到晚上10点半，5个半小时。代码一行没改，全是环境、配置、默认参数的坑。
网络隔离、防火墙、Ollama默认监听127.0.0.1、Linux vs Windows差异——每一个都踩了一遍。
目前网络已通，向量模型的上下文问题还在调。

前置条件

• 操作系统：Ubuntu 桌面版

• Ollama版本：v0.20.4

• Docker环境：本地容器化部署

• 显卡：NVIDIA MX150（当前纯CPU运行）

• 核心模型：nomic-embed-text（上下文上限2048）

一、前言

今天从下午5点折腾到晚上10点半，看似是业务代码报错，实则是一场被网络隔离、防火墙、Ollama默认参数、跨系统差异联手“背刺”的连环事故。

所有问题的共性是：代码本身无任何Bug，全是环境、中间件默认配置、系统兼容性的隐性坑。

这篇把今天踩的坑按排查顺序完整复盘，以后遇到类似问题直接对照定位，再也不用靠玄学试错。

二、网络 & Docker容器类坑（已解决）

2.1 Docker容器网络隔离坑

现象：宿主机本地、Windows客户端访问服务完全正常，Docker容器内部访问宿主机端口/服务直接超时。

根因：Docker容器使用独立的虚拟网络，与宿主机网络天然隔离，不能直接通过localhost访问宿主机服务。

结论：排查容器内服务调用，优先确认是否用对了宿主机真实IP，而非localhost。

2.2 防火墙端口放行坑

现象：外部网络、宿主机本地都能正常连接，唯独Docker容器访问直接报Connect timed out。

根因：Ubuntu ufw防火墙默认拦截外部/跨网段端口请求，即使服务本身监听了0.0.0.0，没放行端口也会被拦截。

解决：

bash

ufw allow 11434

2.3 Ollama跨网络访问坑

现象：宿主机本地调用Ollama正常，Docker容器/其他机器调用11434端口直接连接失败。

根因：Ollama默认仅监听127.0.0.1，仅允许宿主机本地访问。

解决：

bash

OLLAMA_HOST=0.0.0.0 ollama serve

三、Ollama部署坑

3.1 监听地址坑（已解决）

bash

OLLAMA_HOST=0.0.0.0 ollama serve

3.2 上下文上限坑（正在排查中）

现象：同一份代码、同一份分片文本，Windows上Ollama运行正常，Linux上直接阻塞、报500错误或1分钟超时。

错误日志：

text

{"error":"the input length exceeds the context length"}

根因：

• 向量模型nomic-embed-text原生上下文上限为2048

• Ollama Linux版默认num_ctx参数过高，模型不兼容直接阻塞

• Windows版有自动容错截断，Linux版校验严格

当前状态：正在调整分块大小和num_ctx参数，尝试手动对齐模型上限：

bash

OLLAMA_CONTEXT_LENGTH=2048 ollama serve

后续排查方向：确认LangChain4j调用时是否正确传递了num_ctx参数。

四、业务代码 & 分片逻辑坑

4.1 分片本身无问题

排查后确认：语义分片、标题/元数据/正文拆分逻辑完全合规，文本长度可控，排除业务代码与分片规则问题。

4.2 多业务耦合干扰坑

爬虫流程强耦合“图片FTP上传”，FTP端口未放行导致连锁报错，严重干扰排查方向。

优化方向：核心业务链路与非核心附件上传流程解耦，隔离异常影响范围。

五、硬件 & 系统环境坑

Linux vs Windows Ollama核心差异

核心结论：Linux环境下不能照搬Windows用法，隐性参数必须手动约束配置。

纯CPU推理性能坑

轻量向量模型在批量计算场景下，CPU资源消耗极高，低压笔记本CPU无法长时间承载，极易引发超时、服务假死。（当前显卡驱动未装，纯CPU运行）

六、核心结论

七、最后

今天折腾5个半小时，没有一行业务代码需要修改，全是环境和配置的隐性坑。

网络已通，向量模型的上下文问题还在调。这也提醒我们：工程化能力，不仅是写代码，更是在复杂环境中定位和解决问题的能力。

📚 系列导航：

【人生底稿 01】｜农村少年（1995–2005）

【技术底稿】01：37岁老码农，用4台机器搭了套个人DevOps平台

【产品底稿01】37 岁 Java 老码农，用 Java 搭了个 AI 写作助手，把自己 14 年技术文章全喂给了 AI！