Troubleshoot Dify’s LAN connection to Ollama on Windows
A Juejin author reports troubleshooting Dify 1.17.1 and Ollama 0.40.15 across two Windows machines, finding that Docker’s default docker0 subnet collided with the LAN address range and prevented containers from reaching Ollama. The author also found that the Dify Ollama plugin did not send a reasoning-control parameter, leaving Qwen3.5 4B in its default thinking mode and producing slow, short responses. The guide provides Docker network configuration changes, verification commands, and a forwarding proxy that injects think:false or reasoning_effort:none.
The report offers a practical, layered diagnosis for a self-hosted Dify deployment: network reachability and response speed can have separate causes that otherwise produce misleading timeout and latency symptoms.
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 等 │ │
│ └─────────────────────────┘ │
│ ▲ 这一层外面看不见 │
└───────────────────────────────┘