1. 判断需要接入网络的 Dify 容器
新版 Dify 的模型供应商校验和模型调用经常由插件运行环境发起，因此重点不是只让 api 容器能访问模型接口，而是要让以下容器能访问模型 API 所在网络：
plugin_daemon：必须加入，模型供应商凭据校验通常由它发起。api：建议加入，控制台、管理接口和部分后端逻辑会用到。worker：建议加入，异步任务、工作流、数据处理等可能触发模型调用。
通常不需要加入：
webdbredissandboxapi_websocketworker_beat
2. 确认模型 API 所在 Docker 网络
先查看本机已有 Docker 网络： docker network ls
例如模型 API 所在网络是： sub2api-deploy_sub2api-network
如果该网络不存在，需要先启动模型 API 对应的 Docker Compose 项目，或手动创建网络： docker network create sub2api-deploy_sub2api-network
如果该网络由另一个 Compose 项目创建，推荐优先让对应项目自己创建，不要重复创建同名网络。
3. 修改 Dify 的 Compose 模板
Dify 的 docker-compose.yaml 通常是自动生成文件，文件头可能包含类似提示： WARNING: This file is auto-generated by generate_docker_compose Do not modify this file directly. Instead, update the .env.example or docker-compose-template.yaml and regenerate this file.
因此不要直接修改 docker-compose.yaml，应修改： docker-compose-template.yaml
在文件底部的 networks: 下增加外部网络定义： networks: ssrf_proxy_network: driver: bridge internal: true milvus: driver: bridge opensearch-net: driver: bridge internal: true sub2api-network: external: true name: sub2api-deploy_sub2api-network
说明：
sub2api-network是 Dify Compose 文件内部使用的网络别名。name: sub2api-deploy_sub2api-network指向 Docker 里已经存在的真实网络。external: true表示这个网络由外部项目管理，Dify 不负责创建它。- 只在底部定义网络还不够，必须继续把该网络追加到需要访问模型 API 的服务上。
4. 给关键 Dify 服务挂载该网络
在 api 服务下保留原网络，并追加 sub2api-network： services: api: networks: - ssrf_proxy_network - default - sub2api-network
在 worker 服务下保留原网络，并追加 sub2api-network： services: worker: networks: - ssrf_proxy_network - default - sub2api-network
在 plugin_daemon 服务下保留原网络，并追加 sub2api-network： services: plugin_daemon: networks: - ssrf_proxy_network - default - sub2api-network
注意：不要把原来的 default 或 ssrf_proxy_network 删除。否则可能导致 Dify 内部服务互相访问失败，例如 api 无法访问 plugin_daemon。
如果你使用 docker-compose.override.yaml 追加网络，要特别小心 Compose 对列表字段的合并行为。某些写法可能会替换原服务的 networks 列表，而不是在原列表后追加。最终一定要以 docker compose config 的输出为准，确认 default、ssrf_proxy_network 和 sub2api-network 同时存在。
5. 重新生成 docker-compose.yaml
进入 Dify 的 docker 目录： cd /data/dify/docker
确认生成脚本存在： ls -l generate_docker_compose docker-compose-template.yaml docker-compose.yaml
如果脚本没有执行权限： chmod +x generate_docker_compose
重新生成 docker-compose.yaml： ./generate_docker_compose
生成后检查最终文件是否包含网络配置： grep -n "sub2api-network|sub2api-deploy_sub2api-network" docker-compose.yaml
如果 docker-compose.yaml 里没有出现 sub2api-network，说明模板没有改对位置，或生成脚本没有成功执行。
6. 检查 Compose 最终渲染结果
用 Compose 的 config 命令确认最终生效配置： docker compose -p docker -f docker-compose.yaml config | grep -A20 -E "api:|worker:|plugin_daemon:|sub2api-network"
三个服务的 networks 中都应能看到 sub2api-network。
如果只看到： networks: default: null ssrf_proxy_network: null
说明当前生效的 docker-compose.yaml 还没有包含新网络配置。
7. 重建关键容器
修改网络配置后，不能只执行 restart。Docker 容器的网络配置是在容器创建时写入的，普通重启不会新增网络。
错误方式： docker compose restart
或： docker restart docker-plugin_daemon-1
正确方式是重新创建相关容器： docker compose -p docker -f docker-compose.yaml up -d --force-recreate api worker plugin_daemon
其中 -p docker 用于指定 Compose 项目名。若你的容器名是： docker-api-1 docker-worker-1 docker-plugin_daemon-1
通常项目名就是 docker。
8. 验证容器是否已加入模型网络
分别检查三个容器的网络： docker inspect docker-plugin_daemon-1 --format '{{range k,v := .NetworkSettings.Networks}}{{k}}{{"\n"}}{{end}}' docker inspect docker-api-1 --format '{{range k,v := .NetworkSettings.Networks}}{{k}}{{"\n"}}{{end}}' docker inspect docker-worker-1 --format '{{range k,v := .NetworkSettings.Networks}}{{$k}}{{"\n"}}{{end}}'
期望看到类似： docker_default docker_ssrf_proxy_network sub2api-deploy_sub2api-network
如果没有 sub2api-deploy_sub2api-network，说明容器没有被重新创建，或当前 Compose 文件仍未包含该网络。
9. 在容器内测试模型 API 连通性
假设模型 API 容器在 sub2api-deploy_sub2api-network 网络中的服务名是 sub2api，端口是 3000，可以测试： docker exec -it docker-plugin_daemon-1 sh
进入容器后执行： curl http://sub2api:3000/v1/models
如果模型 API 是 OpenAI 兼容接口，Dify 中填写的 Base URL 通常类似： http://sub2api:3000/v1
不要在容器里使用宿主机浏览器能访问的 localhost。在 Dify 容器内部，localhost 指的是 Dify 容器自己，不是模型 API 容器。
10. 临时方案：手动连接网络
如果只是临时验证，也可以不改 Compose，直接把运行中的容器接入网络： docker network connect sub2api-deploy_sub2api-network docker-plugin_daemon-1 docker network connect sub2api-deploy_sub2api-network docker-api-1 docker network connect sub2api-deploy_sub2api-network docker-worker-1
这种方式普通 docker restart 后仍然保留，但容器被删除重建后会丢失。因此长期建议写入 docker-compose-template.yaml 并重新生成 docker-compose.yaml。
11. 常见问题
改了模板但没有生效
检查是否执行了： ./generate_docker_compose
并确认最终 docker-compose.yaml 包含： grep -n "sub2api-network|sub2api-deploy_sub2api-network" docker-compose.yaml
执行 restart 后没有新网络
这是正常现象。网络配置变更需要重建容器： docker compose -p docker -f docker-compose.yaml up -d --force-recreate api worker plugin_daemon
只在底部添加 networks 但服务里没加
这不会让容器自动加入网络。底部 networks: 只是声明网络，真正决定容器是否加入网络的是每个服务自己的 networks 配置。
至少要确认这三个服务都包含 sub2api-network： api worker plugin_daemon
使用 override 后原网络丢失
如果用 docker-compose.override.yaml，要检查最终渲染结果。只要 api 或 plugin_daemon 丢了 default / ssrf_proxy_network，Dify 内部调用就可能断开。
检查命令： docker compose -p docker -f docker-compose.yaml config | grep -A20 -E "api:|worker:|plugin_daemon:"
Dify 报 Failed to request plugin daemon
这通常说明 api 访问 plugin_daemon 失败。检查 plugin_daemon 是否仍保留 Dify 原网络： docker_default docker_ssrf_proxy_network
不要只让 plugin_daemon 加入模型网络而移除 Dify 原网络。
Dify 添加模型时报 Connection error
新版 Dify 的模型校验常由 plugin_daemon 发起，优先进入 plugin_daemon 容器测试到模型 API 的连通性： docker exec -it docker-plugin_daemon-1 sh curl http://模型服务名:端口/v1/models
如果这里不通，Dify 页面里添加模型也会失败。
12. 推荐最终流程
完整流程如下： 确认模型 API 所在 Docker 网络 -> 修改 docker-compose-template.yaml -> 给 api、worker、plugin_daemon 追加外部网络 -> 执行 ./generate_docker_compose -> 检查 docker-compose.yaml 和 docker compose config -> docker compose up -d --force-recreate api worker plugin_daemon -> docker inspect 验证网络 -> docker exec 进入 plugin_daemon 测试模型 API -> 在 Dify 页面配置模型 Base URL