Dify 工作流 API 返回 401 Unauthorized 错误通常是因为请求头中的 API Key 无效或格式不正确。最推荐的处理方向是核对 API Key 类型是否为“应用 API 密钥”，并确认 Authorization 请求头格式符合 Bearer Token 规范。

命令速用版

使用 curl 命令可以快速验证 API 密钥和请求头格式是否正确，以下命令模板可直接替换关键参数后执行。

curl -X POST 'https://api.dify.ai/v1/workflows/run' \
-H 'Authorization: Bearer YOUR_APP_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"inputs": {}, "response_mode": "blocking"}'

将 YOUR_APP_API_KEY 替换为实际密钥，若返回 200 状态码则认证通过，若仍返回 401 则需检查密钥有效性。

为什么会这样

401 Unauthorized 状态码明确表示服务器无法验证客户端提供的身份凭证。在 Dify 系统中，这通常是因为 API 网关拦截了请求并发现 Authorization 头缺失、格式错误或密钥不在白名单内。

Dify 采用标准的 HTTP Bearer Token 认证机制，请求头必须包含 Authorization 字段，且值必须以 Bearer 开头后跟空格和密钥。如果密钥类型混淆，例如使用了控制台管理密钥而非应用运行密钥，网关会拒绝请求并返回 401。

分步处理

按照以下顺序排查配置，每一步完成后立即重试请求以定位问题。

步骤 1：核对 API Key 类型

登录 Dify 应用管理后台，进入具体应用概览页，找到 API 访问信息区域。确认复制的是“应用 API 密钥”（App API Key），而不是账号设置里的控制台密钥。应用密钥通常以 app- 开头，控制台密钥用于管理应用列表。

步骤 2：检查请求头格式

检查代码中的 HTTP 请求头配置，确保键名为 Authorization，键值格式为 Bearer 空格 密钥。注意 Bearer 首字母大写，且与密钥之间必须有一个空格，多余的空格或缺失空格都会导致验证失败。

步骤 3：确认环境配置

如果是自部署版本，检查服务端环境变量 DIFY_API_KEY 或相关认证配置是否被修改。云端版本无需此步骤，但需确认账号未欠费或应用未被禁用。修改配置后需重启服务或重新加载配置才能生效。

怎么验证是否生效

发送请求后观察 HTTP 响应状态码，若从 401 变为 200 或 201，说明认证问题已解决。同时检查响应体中是否包含 workflow_run_id 字段，该字段存在代表工作流已成功启动。

查看服务端日志也是有效验证手段，自部署用户可查看 docker logs 中 api 服务的输出，确认不再有 Authentication failed 相关报错信息。

常见坑

复制密钥时容易带入前后空格，建议在代码中使用 trim 函数处理密钥字符串。部分 HTTP 客户端库会自动管理 Header，需确认没有重复设置 Authorization 字段导致冲突。

自部署环境下，如果反向代理（如 Nginx）配置不当，可能会丢弃包含 Authorization 的请求头。需检查 proxy_pass 配置中是否包含 proxy_set_header Authorization $http_authorization 指令。

常见问题

在哪里可以找到 Dify 的应用 API 密钥？

在应用概览页面的 API 访问信息卡片中，点击复制按钮即可获取。不要进入账号设置或个人中心寻找，那里的密钥权限不同。

请求头 Authorization 的格式具体是什么？

格式必须是 Bearer 后跟一个空格再跟密钥字符串，区分大小写且不能缺少空格。例如 Authorization: Bearer app-123456。

自部署版本出现 401 错误需要检查什么？

优先检查反向代理是否透传了 Authorization 头，其次确认服务端环境变量是否重置过导致密钥失效。

参考来源

Dify 官方文档，API 参考指南，https://docs.dify.ai/