Dify 接入自建模型老是连不上——是 base_url 写错还是模型名不匹配？

自建模型服务在本机能正常返回，填进 Dify 却报连接失败，通常不是单一原因。判断方向可以拆成四层：模型服务本身是否可达、Dify 容器内是否也能访问同一地址、base_url 写到了哪一层路径、模型标识与密钥是否等于服务端实际值。这四层会分别表现成连接被拒、路径 404、401 鉴权失败、模型未找到几类报错。先看报错关键字落在哪一层，再动手改配置，比反复改 base_url 更省时间。

连不上通常不是单一原因：自建服务本身不可达、Dify 容器到宿主机的网络路径不通、base_url 多写或少写了版本后缀、模型标识与密钥不是服务端实际值，这四类会分别表现成连接被拒、路径 404、401 和模型未找到。建议先在服务器上直接 curl 模型列表确认服务可用，再进容器重复同一请求，最后按报错关键字回查对应一层。地址与密钥以服务端实际返回和请求日志为准。

先在服务器上直接请求模型服务的模型列表

这一步只回答一个问题：模型服务本身能不能通、鉴权对不对。在跑模型服务的那台机器上执行，地址、端口、密钥按你的实际部署替换。

curl -s http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer YOUR_API_KEY"

如果这里就失败，Dify 那边不用看了，问题在模型服务本身或密钥。返回内容重点看两处：一是 HTTP 状态码，401 说明密钥不对或缺少 Bearer 前缀，404 说明模型列表路径不是 /v1/models，需要回看服务端实际路由；二是返回体里 data 数组每项的 id 字段，这个字符串就是后面要填进 Dify 的模型标识，不要凭记忆或界面显示名去填。有些推理框架把模型列表放在别的路径，或者需要带上 /api/v1，以服务端实际暴露的接口为准。

确认容器内也能访问同一地址

宿主机能通不代表 Dify 容器能通。Dify 通常以 docker compose 部署，api 和 worker 跑在容器里，容器有自己的网络命名空间，127.0.0.1 指向容器自身，不是宿主机。

Dify 接入自建模型老是连不上——是 base_url 写错还是模型名不匹配？

docker exec -it dify-api sh
curl -s http://host.docker.internal:8000/v1/models \
  -H "Authorization: Bearer YOUR_API_KEY"

三种地址写法要分清：容器内的 127.0.0.1 只对容器内部服务有效；宿主机的真实 IP（用 ip addr 或 ip route 查，常见是 172.x 网段网关）能在容器里访问到宿主机上监听的端口；如果模型服务和 Dify 在同一个 compose 网络里，可以直接用服务名加端口访问，例如 http://model-server:8000。host.docker.internal 在部分 Linux 环境需要额外加 extra_hosts 映射，不确定时优先用宿主机 IP 或服务名。若容器内 curl 报连接被拒或超时，先确认模型服务监听的是 0.0.0.0 而不是仅 127.0.0.1，再确认宿主防火墙是否放行该端口。

核对 base_url 该写到哪一层路径

路径拼接错误通常表现为 404。OpenAI 兼容接口有两种常见写法：一种是 base_url 写到版本层，例如 http://192.168.1.10:8000/v1，由客户端自己拼 /chat/completions；另一种是服务端不带版本前缀，base_url 只写到 http://192.168.1.10:8000。Dify 的兼容接入一般会自己补齐后续路径，所以把完整的 /v1/chat/completions 填进 base_url 反而容易拼出重复段导致 404。

确认方法是用请求日志看实际拼接路径。在模型服务侧开 access log，或在 Dify 侧执行 docker compose logs -f api，然后在 Dify 页面点一次测试连接或发一条对话。日志里会显示最终请求的完整 URL，把这段 URL 和 curl 能成功的那条比对：路径多了 /v1/v1、少了 /v1、带了尾斜杠，基本就是 base_url 层级写错。base_url 末尾建议不要带多余斜杠。

把模型标识与密钥填成服务端实际值

从模型服务侧读出模型标识的方式，就是第一步里 /v1/models 返回的 id 字段，或者服务启动日志里打印的已加载模型名。填写时注意逐个添加与批量导入的差别：逐个添加时每个条目都要填对模型标识，容易在多个相近名字之间选错；批量导入通常是 JSON 或 YAML 列表，字段名写错、缩进不对会导致整批不生效，建议先只留一个条目验证通过再补全。

401 和模型未找到要分清楚。401 是鉴权层问题，检查密钥是否完整、是否带了 Bearer 前缀、密钥是否属于这个服务；模型未找到通常是 404 或 400，返回体里会出现 model not found 或 invalid model 之类字样，这时 base_url 和密钥往往是对的，只是模型标识填成了别名、显示名或大小写不一致。两类报错的处理方向不同，不要混在一起改。

连不上时按报错分四步回查

下面这套顺序可以直接复用，从外到内逐层排除，遇到哪类报错就停在哪一步。

连接被拒或超时：检查模型服务是否监听 0.0.0.0、端口是否放行、容器到宿主机地址是否可达。验证命令：docker exec -it dify-api curl -v http://宿主机IP:8000/v1/models，看是否能建立 TCP 连接。
鉴权失败（401）：检查密钥值、Bearer 前缀、密钥是否属于该服务。验证命令：在服务器上 curl -s http://127.0.0.1:8000/v1/models -H "Authorization: Bearer YOUR_API_KEY"，同样的密钥在这里能否通过。
路径 404：检查 base_url 是否多写或少写版本后缀、末尾是否有重复段。验证命令：docker compose logs -f api 找到实际请求 URL，与 curl 成功的地址逐段比对。
模型未找到：检查模型标识是否等于 /v1/models 返回的 id、批量导入的字段名与缩进是否正确。验证命令：curl -s http://127.0.0.1:8000/v1/models -H "Authorization: Bearer YOUR_API_KEY"，逐个核对 id 与 Dify 里填写的条目。

四步走完后，绝大多数连不上的情况会落到某一层的地址写法或标识填写上。改动后建议保留一份能跑通的 curl 命令和对应日志，下次再换服务或迁移环境时可以直接对照，不必从头猜。