Dify连接局域网Ollama排障指南
AI 总结
一篇掘金文章记录了作者在两台 Windows 机器上部署 Dify 1.17.1 与 Ollama 0.40.15 的排障过程：Docker 默认 docker0 网段与局域网地址冲突，导致容器无法连接 Ollama；Dify Ollama 插件未发送推理控制参数，又让 Qwen3.5 4B 默认进入思考模式，表现为响应慢且正文短。文章给出了 Docker 网络配置、验证命令，以及注入 think:false 或 reasoning_effort:none 的转发代理方案。
深度见解
这份实测指南区分了“能否连通”和“响应快慢”两个独立层面，可帮助自托管用户避免被连接超时或延迟症状引向错误方向。
Dify 连局域网 Ollama 的两个坑：docker0 网段撞车，和请求里少掉的那个参数
场景：两台 Windows 机器，A 机跑 Ollama 0.40.15（Qwen3.5 4B），B 机用 Docker Desktop 自部署 Dify 1.17.1。 目标：让 B 机上的 Dify 真正跑通 A 机上的模型，并且不要让用户等两分钟(B是一台古董，见上篇文章）。 过程中出现过十几种报错，但真正值得写下来的只有两个根因。一个属于"通不通"，一个属于"快不快"，它们完全在不同的层。
0. 先看清拓扑：你以为的两层，其实是三层
很多人（包括我）第一反应是"Dify 在 B 机，Ollama 在 A 机，两个 IP 一通不就行了"。实际不是：
局域网 172.17.16.0/24
A 机 172.17.16.52 B 机 172.17.16.46
┌──────────────────────┐ ┌───────────────────────────────┐
│ Ollama 0.0.0.0:11434│◄────┐ │ Docker Desktop（WSL2 虚拟机） │
│ │ │ │ ┌─────────────────────────┐ │
└──────────────────────┘ │ │ │ Dify 的 15 个容器 │ │
└────┼──┤ 内部虚拟地址 172.18.x 等 │ │
│ └─────────────────────────┘ │
│ ▲ 这一层外面看不见 │
└───────────────────────────────┘