局域网里另一台电脑的 continue 插件连不上 ollama日志报错指向http://127.0.0.1:11434。这类内网部署问题十有八九不是模型没装好而是 apiBase 找错了门。排查时我让 Codex 去读 continue 的配置而 Codex 的模型通道这次走 TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 Key。Codex 有了模型通道之后再让它把 continue 配置里的apiBase和 ollama 实际的监听地址放在一起比对问题出在哪一层就非常清楚。1. 先复现问题continue 访问不到 ollama先把报错分清楚1.1 一个 127.0.0.1各自代表自己continue 是装在 IDE 里的插件它运行在你当前这台开发机上ollama 是模型服务运行在另一台内网主机上。两者之间的对话靠 HTTP 请求完成continue 发起请求时依靠配置里的apiBase决定“去找谁”。当apiBase写成http://127.0.0.1:11434时continue 实际连接的是它自己这台电脑的回环地址而不是 ollama 所在的主机。也就是说请求根本不会离开当前机器。反过来如果 ollama 启动时只监听了127.0.0.1:11434那么即使 continue 配置里填了正确的内网 IP操作系统也会直接拒绝这个连接因为服务端只给本机留了门。所以这个场景里会看到两类典型报错connect ECONNREFUSED 127.0.0.1:11434continue 试图连本机 11434 端口但本机没有服务在监听。timeoutcontinue 已经连到了正确 IP但服务端没有监听0.0.0.0或者中间有防火墙拦截。这两类报错对应的修复动作完全不一样。前者要改 continue 的apiBase后者要改 ollama 的OLLAMA_HOST监听地址。1.2 动手前先做的三项确认在让 Codex 介入之前先在终端里做三个基础检查把问题缩小到具体层面。先在 ollama 主机上确认服务真的在跑ollama -v。然后请求一下 ollama 的 apicurl http://127.0.0.1:11434/api/version能返回类似{version:0.5.7}的 JSON说明服务端本机访问是通的。再从 continue 所在机器执行ping 192.168.1.100替换成实际部署 ollama 的主机 IP确认网络层可达。这三个确认做完基本就能判断是“网络不通”还是“端口不通”还是“continue 配错了地址”。后续 Codex 的排查也围绕这三个结果展开。1.3 这次排查其实不用动模型文件原文里从下载 ollama、迁移模型文件夹到编写 modelfile那部分工作量和出错概率都很高。但本次只增加局域网访问迁移好的模型、已经跑通的ollama list结果都不需要重新处理。要动的只有两个地方ollama 服务的监听地址和 continue 的apiBase。换句话说这次改动和模型本身无关纯粹是两个配置文件之间的地址握手。搞清楚这一点排查时就不会去重新下载模型或者调整已存在的模型参数。2. 让 Codex 跑起来TaoToken 只做模型通道2.1 把 TaoToken 配成 Codex 的模型供应商Codex 需要一个可用的模型后端才能帮我们读文件、做分析。这里用 TaoToken 作为统一 API 通道。先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建一个 API Key然后编辑~/.codex/config.toml加入以下配置# ~/.codex/config.toml model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api api_key YOUR_API_KEY注意三点base_url一定是https://taotoken.net/api末尾不要加/v1也不要带任何 query 参数模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列表为准不同模型 ID 不要凭记忆猜api_key使用从官网创建的 Key先填占位符YOUR_API_KEY再替换成真实值。保存后可以执行codex exec 简单回一句 hello验证 Codex 能正常对话。如果这一步报 401说明 Key 有问题如果报 404说明模型 ID 或路径填错了。把授权问题在这一步解决干净后面查 continue 配置时才不会混入无关变量。2.2 Codex 在这里的边界只读配置不替你改环境让 Codex 去读 continue 的配置文件、让 Codex 对比 netstat 的输出这些都是允许的。但它不能直接修改 ollama 主机的环境变量也不应该在另一台机器上远程执行export OLLAMA_HOST0.0.0.0。正确的分工方式是Codex 读取~/.continue/config.json里的models数组提取出provider为ollama的那一项把apiBase的值展示出来同时在对话里贴入 ollama 主机上netstat的监听结果让 Codex 判断这两个地址是否一致并要求它输出修正后的配置片段。最终改哪个文件、用哪个 IP由你根据 Codex 的结论在本地完成。2.3 内网完全隔离时的替代做法如果你的内网机器完全没有外网出口Codex 是连不上 TaoToken 的但这不影响整个排查思路。你可以在能联网的开发机上打开~/.continue/config.json把配置内容复制给 Codex同时把 ollama 主机上netstat -tlnp | grep 11434的输出也贴进去Codex 一样能给出结论然后把修正后的配置拿到内网机器上填。这样既绕开网络限制也保住了“让 Codex 帮助比对配置”的核心目的。3. 让 Codex 查 continue 的 apiBase配置与监听地址要一致3.1 先找到 continue 的配置文件continue 在 IntelliJ IDEA 或 PyCharm 里安装后配置文件一般在用户目录下的~/.continue/config.json部分新版也支持config.yaml。打开后找到models数组里面会有一个条目的provider是ollama类似下面这样{ model: AUTODETECT, title: Ollama (Remote), completionOptions: {}, apiBase: http://127.0.0.1:11434, provider: ollama }那个apiBase就是 continue 访问模型的入口。它有两个常见错误IP 写成127.0.0.1或者写成另一台不相干机器的地址。让 Codex 读这个文件时最好指定字段不要问“帮我看看 continue 配置哪里有问题”这种模糊问题而是直接要求“把 models 中 provider 为 ollama 的 apiBase 取值找出来”。如果 Codex 因为权限或路径问题读不到这个文件直接把 JSON 内容复制粘贴给它结论一样准确。3.2 给 Codex 的提示词和它的输出在 Codex 终端里可以这样提问读取 ~/.continue/config.json找到 models 数组中 provider 为 ollama 的条目取出 apiBase 的值。下面这段 netstat 输出来自运行 ollama 的主机 0.0.0.0:11434 请判断continue 在本机使用当前配置时请求会发送到哪里如果配置与上述监听地址不一致给出修正后的完整 JSON 片段。Codex 通常会返回类似下面的修正结果{ model: AUTODETECT, title: Ollama (Remote), completionOptions: {}, apiBase: http://192.168.1.100:11434, provider: ollama }注意这里的关键判断apiBase里的 IP 是 ollama 所在主机的内网地址它不应该等于 continue 所在机器的127.0.0.1也不必和当前终端所在机器一致。Codex 在分析时很擅长抓这种“局部正确、整体矛盾”的问题因为它会把配置文件和监听输出当成两个独立输入来对照。3.3 别忘了服务端防火墙的 11434即便apiBase和OLLAMA_HOST都改对了continue 仍可能卡在timeout。最常见的原因是 ollama 主机防火墙没有放行 11434 端口。Linux 上如果使用 ufw可以临时执行sudo ufw allow 11434/tcpWindows 上则用下面这条命令以管理员身份打开命令提示符执行netsh advfirewall firewall add rule nameollama dirin actionallow protocolTCP localport11434这句的作用是让局域网内其他机器能访问 ollama 的端口只影响入站连接不影响 outbound。出于安全考虑放行范围限定在内网网段更稳妥这里给出的是快速验证用写法生产环境再按内网网段收紧。4. 动手改 OLLAMA_HOST 和 continue 的 apiBase4.1 ollama 主机把监听地址放开到 0.0.0.0ollama 默认监听127.0.0.1:11434这只对本机有效。要让局域网其他机器访问需要把监听地址改为0.0.0.0也就是对主机的所有网卡开放。Windows 上打开系统环境变量新建一个OLLAMA_HOST值设为0.0.0.0保存后完全退出 ollama托盘图标右键退出确保进程结束再重新启动。Linux 上可以在当前终端这样启动export OLLAMA_HOST0.0.0.0 ollama serve也可以把EnvironmentOLLAMA_HOST0.0.0.0写进 systemd service 文件这样重启后依然生效。改完以后用下面的命令确认监听地址已经变成0.0.0.0Linux 执行netstat -tlnp | grep 11434Windows 执行netstat -ano | findstr 11434。看到0.0.0.0:11434而不是127.0.0.1:11434就说明监听层已经放开。需要注意OLLAMA_HOST只影响 ollama 服务端在 continue 所在机器上设置这个变量没有任何作用。continue 永远靠自己的apiBase找服务端。4.2 continue 的 apiBase 指向 ollama 主机 IP回到 continue 的config.json将apiBase改为 ollama 部署主机的内网 IP端口保持 11434。修改后的片段就是第 3.2 节里 Codex 给出的那一段IP 换成你自己的实际地址。保存文件后重启 IDE 或者至少重启 continue 插件让配置重新加载。在 continue 所在机器上先做一个请求测试curl http://192.168.1.100:11434/api/version能返回 ollama 版本 JSON说明 continue 要走的这条路已经通到了服务端。如果这一步失败问题就在监听地址或防火墙先不要反复重启 continue。注意OLLAMA_HOST0.0.0.0只是让 ollama 对所有本机网卡开放并没有把端口直接暴露到公网。在不可信网络环境里仍然要配合防火墙限制访问来源避免内网其他设备随意调用模型服务。5. 验证一轮continue 能对话后再回控制台对账5.1 在 continue 面板里发一次真实对话配置改完打开 continue 面板新建一个 session发一句原文里出现过的请求请它写一个快速排序算法。如果模型能正常流式返回说明这一条链路已经完全跑通continue →apiBase→ ollama 主机监听地址 → 模型加载。如果仍然转圈看 continue 日志里的新报错。现在只剩下两种可能ECONNREFUSED说明地址或端口仍然不对重点检查apiBase是否被 IDE 缓存覆盖timeout说明地址能到但系统防火墙没有真正放行。用第 3.3 节的方式再核对一遍。5.2 回控制台看这次 Codex 调用记录排查过程中每一次和 Codex 对话走的都是 TaoToken 通道这些调用会在控制台留下用量记录。跑通之后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 可以核对本次排查实际消耗了多少额度也能顺便确认模型 ID 和计费是否正常。如果发现 Key 本身不可用或者想在浏览器里先验证这把 Key 的真伪可以打开 TaoToken 模型对话 发一条测试消息。接下来如果打算让 Codex 长期参与这类内网配置排查可以看看 Coding Plan 是否符合使用预期需要重新生成密钥则到 控制台 API Keys 页面操作。配置和联动都确认没问题后回到 continue 面板继续用内网模型局域网访问这条链路就完整了。