Ollama API 排错最好按网络、接口、模型和响应格式逐层进行。“网页能聊天，脚本却失败”不一定是模型坏了，可能只是地址、编码或流式输出处理不同。本文面向 Windows 原生 Ollama，给出一个最小非流式请求，再说明常见错误怎么缩小范围，不要求关闭防火墙或重装全部环境。
一、先确认服务和模型
启动 Ollama，新开 PowerShell 检查本机服务与已下载模型。
ollama list
Test-NetConnection -ComputerName 127.0.0.1 -Port 11434
Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/tags'
端口通只能说明连接成立。tags 接口有响应，才进一步说明 API 路径可达。检查返回的模型名称，完整标签要与请求一致，别把不存在的简称当成已下载模型。
二、发送一个最小中文请求
把模型名改成实际列表中的值。这里使用 UTF-8 字节发送 JSON，并关闭流式输出，便于先验证请求与解析。
$payload = @{
model = 'qwen2.5:3b'
prompt = '请只回复：连接正常'
stream = $false
} | ConvertTo-Json
$result = Invoke-RestMethod -Method Post -Uri 'http://127.0.0.1:11434/api/generate' -ContentType 'application/json; charset=utf-8' -Body ([Text.Encoding]::UTF8.GetBytes($payload)) -TimeoutSec 180
$result.response
能返回文字，就先保存这份成功请求。之后再增加文件、JSON schema 或批处理，不要一开始把所有复杂逻辑叠上去。
三、区分接口外层与模型正文
Generate API 返回对象中，response 是生成文本。即使你要求模型输出 JSON，response 本身通常仍是一个字符串，需要再解析一次。
第一层：HTTP返回的JSON对象
第二层：其中response字段的字符串
第三步：只有当这个字符串确实是JSON时，再按JSON解析
不要把 HTTP 状态 200 直接当业务成功。检查 done、返回结构和必要字段；也不要把模型写的一句“成功”当作脚本已经执行了动作。
四、流式输出为何不能当单个 JSON 读
默认流式响应可能包含多条逐行 JSON，而不是一个完整对象。初学者先设置 stream 为 false；确实需要流式显示时，按接口格式逐行解析，分别处理空行、错误和结束标志。
把整段多行响应直接交给一次 json.loads，可能报“额外数据”；把一条尚未接收完整的 JSON 提前解析，也会失败。这个问题与中文编码不同，不能靠随便换编码解决。
五、容器与超时问题
容器里的 localhost 指向容器自身，不是 Windows 宿主机。两个容器可用共同网络中的服务名；容器访问宿主机则按 Docker 的网络方式配置，不要为了方便把无认证接口直接暴露公网。
首次请求还可能包含模型加载。先用短输入和足够的测试超时核查，记录墙钟时间、加载时间和输出长度。持续超时则检查资源、输入规模与服务日志，不要只把等待时间无限加大。
六、常见问题与排错
404 一定是模型没下载吗？
不一定。先核对 URL 是否为正确接口，再看错误正文是否说明模型不存在。错误码与错误内容要一起读。
浏览器可用，PowerShell 中文乱码？
检查请求 Content-Type、发送字节与终端显示编码。先用上面的最小 UTF-8 请求确认，不同时改模型和业务逻辑。
能不能失败就一直重试？
只对适合重试的临时故障设置次数与等待，保留失败记录。错误模型名和错误 JSON 不会因重试自动修好。
接口依据见 Ollama Generate API。有了稳定请求，再做本地批量摘要或批量文本分类。