ollama和codex怎么排查，常见坑和正确做法一次讲清

很多人本地 Ollama 已经能聊，一接到 Codex 类编程客户端就报错、卡住或答非所问；也有人反过来，Codex 能跑但本地模型根本没被调用。这篇给一套从下往上的排查顺序：先确认 Ollama 服务与模型真的可用，再核对接入格式与模型名，最后看上下文和性能这类隐性坑。每一步都说明判断标准和什么情况下不适用。

本地 Ollama 能正常聊天，接上 Codex 类编程客户端却报错、卡住或者答非所问，是很常见的一组故障；也有人反过来，客户端明明能跑，但本地模型根本没被调用，实际走的是云端。两种现象看着像一个问题，排查路径完全不同。

这篇给一套从下往上的顺序：先确认 Ollama 服务和模型真的可用，再核对接入格式和模型名，最后看上下文、超时、并发这类隐性坑。每一步都写清判断标准，以及什么情况下不用继续修。下面默认你用的是 OpenAI 兼容的接法，如果不是，以客户端文档为准但顺序不变。

先分层：把故障拆成服务层、模型层、接入层

排查最怕一上来就改客户端配置。三层是依赖关系：服务不通，模型肯定跑不了；模型跑不起来，接入配得再对也没用。所以顺序只能从下往上，跳层查基本是白忙。

注意一个容易混的点：本机通、容器不通，和完全不启动，是两类问题。前者多半是监听地址或端口映射，后者是进程和模型加载。先分清占哪一类，再动手。

服务和模型的硬性检查项

别只看客户端界面的红色提示，那个提示往往是转述，会丢掉原始报错。直接用命令行调一次接口，看返回体里的报错原文，通常能一句话指出是连不上、模型不存在还是参数不合法。

1. 确认监听地址检查服务是否只监听在本机回环地址。如果客户端在容器里或另一台机器，需要放开监听地址，改完重启服务，再从客户端所在机器测一次端口，而不是在本机测。
2. 做一次连通性测试从客户端那一侧发一个最小的请求，看到返回就说明链路通了；超时或连接被拒，问题在服务层，先别碰客户端配置。
3. 列出本地模型不要凭记忆写模型名，先把本地已有的模型列一遍，再照抄进配置。名字差一个标签，请求要么报错，要么悄悄跑到你没想到的那个模型上。
4. 单模型跑通一次对话用要接的那个模型单独发一次对话请求，能稳定回答再往下走。模型本身跑不起来，接入层怎么调都没意义。

接入配置里最常见的几个坑

服务通了、模型也跑得起来，剩下的问题九成在接入配置。这类坑的特点是：配置写错不报错，只是行为不对，所以要用小任务去验证，而不是靠肉眼读配置。

• 接口地址要不要带版本路径，各家客户端默认拼法不同，照抄教程最容易在这里错位
• stream 开关两侧默认值可能不一致，表现是卡住不出字，或者一次性吐完
• 鉴权字段：本地服务通常不校验，但客户端可能强制要求填，填了假值反而被拦
• 上下文长度按本地机器实际能力设，设得比模型能吃下的还大，表现就是截断或直接报错
• 超时时间要覆盖本地推理的耗时，小机器上默认值往往太短，跑到一半就断

改完配置别急着跑真实任务，先用一个小任务验一次，确认请求确实落在本地，而不是被客户端悄悄转给了云端。很多「本地不生效」的疑惑，最后都出在这一步。

任务本身对上下文和指令遵循要求高时，本地模型表现差不是配置问题。判断标准很简单：同一个提示词，缩小到单文件、短上下文再跑一次，如果结果明显变好，那就是任务超出了模型能力，不是接入有错。

什么情况下不该继续修，直接换路子

排查要有止损线。有些现象看起来像配置毛病，其实是硬件或架构不够，继续修只会消耗时间。下面几条判断标准可以用来叫停。

还有一种常见误判：把长上下文任务跑在量化过度的小模型上，然后反复怀疑接口地址。判断方法是换一个确定能跑通的短请求，如果短请求正常、长请求必挂，问题在上下文长度或显存，不在接入层。

如果你选模型、定档位时拿不准，去站内模型资料库核对当前各家模型的上下文长度和部署要求，再结合自己机器的显存做取舍，别凭印象拍板。