Dify 用 Docker 部署Ollama 跑在宿主机这套本地知识库环境最磨人的就是 host.docker.internal 报错。教程常让人在 .env 里填 192.168.x.x结果容器访问宿主机一直超时。与其反复试 IP不如把报错丢给 Codex 拆解要让 Codex 有模型可用我给它接一个 TaoToken 通道官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册后创建一把 API Key 即可。1. 先复盘 Dify 连 Ollama 为什么会栽在 host.docker.internal1.1 容器和宿主机是两套网络本地跑 Dify 时容器里的 Dify 后端看到的网络和你电脑上ipconfig看到的网络不是同一个。Docker 会给每个容器分配独立的网络命名空间容器内的localhost指向容器自己不是你的 Windows 或 Mac。OLLAMA_API_BASE_URL 这个变量决定了 Dify 后端去请求哪个地址来调用 Ollama 的/api/chat和/api/embed接口。如果你在.env里写OLLAMA_API_BASE_URLhttp://192.168.1.10:11434等于告诉容器里的进程去访问你无线网卡上的那个地址。这个地址在宿主机上确实存在但容器能不能访问到取决于 Docker 的网络模式。Docker Desktop for Windows 默认用 WSL2 或 Hyper-V 虚拟化容器跑在轻量虚拟机里虚拟机网段和物理网卡网段不是一回事跨网段访问经常时通时断。1.2 局域网 IP 时灵时不灵的真实原因当电脑休眠唤醒、切换 Wi-Fi、或者 Docker Desktop 重启之后宿主机的局域网 IP 可能变化虚拟交换机路由表也可能重建。你在.env里写死的 192.168.x.x 一旦失配Dify 就需要重启容器并重新读取变量才能恢复。而host.docker.internal是 Docker Desktop 提供的特殊域名由 Docker 引擎自动解析到宿主机不随路由器 DHCP 分配变化所以它比手写 IP 稳定得多。如果是在纯 Linux 服务器上跑 Docker没有host.docker.internal这个域名通常要改用172.17.0.1这个 docker0 网桥的默认网关地址或者在docker run和docker compose里显式添加extra_hosts。这些判断正好是 Codex 擅长的事把它丢给 Codex 去分析比自己在百科里翻 Docker 网络文档要快。2. 给 Codex 接通 TaoToken拿 Key 与 config.toml 落点2.1 去官网拿 API Key打开 TaoToken注册账号后进入控制台的 API Keys 页面创建一把 Key先复制下来后面填到 Codex 的环境变量里。这把 Key 在你的终端里以YOUR_API_KEY占位符形式出现不要写进任何会提交到 Git 的文件。TaoToken 在这里的角色是一个统一 API 通道负责把 Codex 需要的模型推理请求转发到对应模型服务。Dify 和 Ollama 之间的流量仍然只存在于你的电脑内部TaoToken 不接触也不存储你的 Dify 对话数据、知识库文件或本地文档。它解决的是 Codex 这个分析助手有没有模型可用的问题不是把 Dify 的请求发到公网。2.2 修改 Codex 配置文件Codex CLI 读取~/.codex/config.toml在这个文件里增加一个模型供应商。打开终端执行mkdir -p ~/.codex codex ~/.codex/config.toml然后把下面这部分追加进去。注意 Base URL 是https://taotoken.net/api末尾不要加/v1也别把 UTM 参数带进来。model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat这里的model_provider字段会把 Codex 默认的模型通道切到 TaoToken。具体模型名称不要照抄网上任何示例以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场里当时列表显示的 ID 为准。如果你用的是 Codex 的桌面端或 IDE 插件通常在设置里填 Provider Base URL 的地方填https://taotoken.net/apiAPI Key 填YOUR_API_KEY模型 ID 从模型广场复制。2.3 确认 Codex 已经能用在终端设置环境变量export TAOTOKEN_API_KEYYOUR_API_KEYWindows PowerShell 用户用$env:TAOTOKEN_API_KEYYOUR_API_KEY然后跑一个最直接的验证codex exec 用一句话说明 host.docker.internal 和 127.0.0.1 的区别如果 Codex 正常返回解释说明模型通道已经打通。接下来就可以把 Dify 连 Ollama 的报错现场拿给它分析了。3. 把 host.docker.internal 报错整理成 Codex 能读的现场信息3.1 先收齐四份现场材料Codex 排障的前提是拿到准确输入。在发给 Codex 之前先准备好以下内容每一样都有明确用途Dify 项目根目录下docker/.env文件重点看CUSTOM_MODEL_ENABLED和OLLAMA_API_BASE_URL两行有没有写对docker-compose.yml里 api 服务和 worker 服务的网络配置确认它们没有绑定在某个固定容器网络上终端执行docker ps的输出确认 Dify 的容器都在运行终端执行docker inspect dify-api -f {{.HostConfig.NetworkMode}}看容器用了 bridge 还是 host 网络顺便把操作系统信息、Docker Desktop 用的还是 WSL2 后端也告诉 Codex。准备好之后把这几份内容的文本直接粘贴给 Codex。不要让 Codex 代跑命令去连 Docker daemon你只要在本地终端执行上面的命令然后把输出贴回对话里就行。3.2 给 Codex 一个结构化的排障提示提示词可以参考这样写把关键信息、当前配置、想让它判断的方向都说清楚当前环境Windows 11 Docker Desktop WSL2 Ollama 跑在宿主机监听 11434 端口。 Dify 通过 Docker 部署位于 dify 项目的 docker 目录。 .env 中目前配置 CUSTOM_MODEL_ENABLEDtrue OLLAMA_API_BASE_URLhttp://192.168.1.10:11434 在 Dify 的 设置 - 模型供应商 - Ollama 里测试连接报连接失败。 这是 .env 全文、docker-compose.yml 相关片段、docker ps 输出 [粘贴内容] 请帮我判断 1. 这个报错更可能是容器网络模式的问题还是 WSL2 NAT 导致访问不到宿主机 2. OLLAMA_API_BASE_URL 到底应该写什么 3. 是否需要检查 Ollama 自己的监听地址。Codex 拿到这些信息后通常会从两个方向给结论一是让你把 URL 改成http://host.docker.internal:11434二是让你去检查 Ollama 的OLLAMA_HOST是否绑定在0.0.0.0上否则host.docker.internal解析成功也会被拒绝连接。3.3 Codex 判断逻辑里容易忽略的一点很多人以为host.docker.internal是万能药改了就能通。Codex 如果看到 Ollama 默认安装在 Windows 上通常会提醒你Ollama 服务默认只监听127.0.0.1意思是只有本机程序能访问Docker 容器里的 Dify 即使解析到宿主机地址也会收到拒绝连接。这时候要在 Windows 的环境变量里加一个OLLAMA_HOST0.0.0.0重启 Ollama再回到 Dify 测试。这个判断比单纯换 IP 更贴合报错本质。4. 按 Codex 的结论改 OLLAMA_API_BASE_URL 并重启容器4.1 正确的 .env 两行配置在 Dify 项目的docker/.env文件末尾最终应该看到这两行CUSTOM_MODEL_ENABLEDtrue OLLAMA_API_BASE_URLhttp://host.docker.internal:11434注意是http://host.docker.internal:11434不是host.docker.internal:11434。有些教程把http://省了Dify 读取后拼接请求时也可能能自动处理但保险起见按带协议头的格式写。如果你在 Linux 服务器上部署Codex 可能会建议改成http://172.17.0.1:11434或使用extra_hosts映射。4.2 为什么必须 down/up 而不是 restart.env变量是在执行docker compose up时被读取进容器环境变量的docker compose restart只重启进程不会重新读取.env。改了配置后必须做一次完整的重建cd dify/docker docker compose down docker compose up -ddown会停止并移除容器up -d重新创建容器并读取新的变量。执行完之后等十几秒让后端服务完成启动再打开 Dify 界面去测试模型连接。4.3 回到 Dify 设置里做二次验证打开 Dify 界面进入「设置」-「模型供应商」找到 Ollama 供应商。如果之前已经添加过直接点模型名称旁边的设置图标重新填入模型 ID比如deepseek-r1:8b再点测试。如果测试成功说明 Dify 到 Ollama 那条链路已经通。如果还失败把新的报错原文贴回给 Codex让它继续缩小范围。通常下一步是看docker logs dify-api --tail 50输出这段日志也只有你自己终端能拿到贴回对话给 Codex 看即可。5. 排障之外的注意事项Embedding 模型与端口监听5.1 OLLAMA_HOST 没放开导致的连接拒绝很多人在 Dify 里配好 Ollama 后Dify 报错不是超时而是 connection refused。这时候问题不在 Dify也不在.env里的域名而在 Ollama 服务本身。Ollama 在 Windows 上安装后默认只监听本机回环地址127.0.0.1这就等于说只有宿主机自己可以访问Docker 容器里的进程一律拒绝。解决方式是给宿主机添加一个系统环境变量OLLAMA_HOST0.0.0.0添加后必须完全退出 Ollama 再重新打开因为 Ollama 只在启动时读取这个变量。重新运行ollama list确认服务在线再回 Dify 点测试。这一步和host.docker.internal的域名解析是两件独立的事前者是路由能不能到后者是到了之后 Ollama 给不给你开门。5.2 Embedding 模型别用对话模型凑合原文里那个案例还有一个值得注意的坑知识库召回效果差不一定是 Dify 配置问题而是 Embedding 模型选错。deepseek-r1是对话模型它的职责是生成回复不是把文本转成向量。拿来当 Embedding 用语义相似度算不准知识库匹配结果自然飘。本地部署推荐单独从 Ollama 拉一个专业的 Embedding 模型ollama pull bge-m3拉取完成后在 Dify 的设置-模型供应商-Ollama 里新增一个类型为 Embedding 的模型模型 ID 填bge-m3。同一个 OLLAMA_API_BASE_URL 就能同时服务对话模型和 Embedding 模型不用额外配置。Codex 在这一步也可以帮你对比bge-m3、nomic-embed-text对中文知识库的适配差异。6. 跑通之后控制台对账与后续用法配置保存后先用同一把 Key 证明整条链路没有隐患。打开 TaoToken 模型对话 发一条测试消息确认你复制到 Codex 里的模型 ID 没有填错。如果你打算长期用 Codex 做项目级排障可以在 Coding Plan 里看套餐是否覆盖你的调用量。Key 的管理统一在 控制台 API Keys 页面用完可以随时吊销重建。如果你之后想让 Claude Code 也走同样的通道环境变量的对照写法可以参考 TaoToken 接入文档。现在再遇到 Dify 连 Ollama 报错步骤就清晰了先让 Codex 读一遍.env和 docker 网络信息再按它的结论改OLLAMA_API_BASE_URL最后docker compose down/up重建。不用再换第三个 192.168 开头的 IP 碰运气直接一次性把容器网络和 Ollama 监听地址一起查明白。