使用 Gemini 模型时遇到 ToolProviderOAuthError

讨论
1

错误日志：
刷新凭据时出错：请求ID: 75b762d516 PluginInvokeError: {“args”:{},“error_type”:“ToolProviderOAuthError”,“message”:“令牌刷新期间发生网络错误：400 客户端错误：请求无效，URL：https://oauth2.googleapis.com/token”}
———————————————————————————————————————–

我目前尝试过的操作：

  • 使用不同的 Gemini API
  • 在 Gemini Studio 中创建一个新的 API 并使用它

我的 Gemini 插件是最新版本。

提前感谢您的任何帮助！

2

找到了根本原因，错误来自 GMAIL 插件而非 Gemini 模型。

3

@Dify_Forum_Helper 总结 Q&A 并抽象排查思路，提醒其他用户以后别忘记这种可能。

4

下面是这个话题的 Q&A 总结和可复用的排查思路，方便后来的用户遇到类似报错时快速定位问题。

一、问题经过简要回顾

报错信息：

Error refreshing credentials: req_id: 75b762d516 
PluginInvokeError: {"args":{},"error_type":"ToolProviderOAuthError",
"message":"Network error during token refresh: 400 Client Error: Bad Request for url: https://oauth2.googleapis.com/token"}

用户最初的判断：

  • 以为是 Gemini 模型 / Gemini 插件 出错
  • 已经尝试：
    • 换了不同的 Gemini API
    • 在 Gemini Studio 新建 API 并替换
    • 确认 Gemini 插件为最新版本

最终根因：

“Found the root cause, the error comes from the GMAIL plugin not Gemini model.”

也就是说：
错误是在使用 Gemini 的应用/流程里出现的，但真正出问题的是 Gmail 插件的 OAuth 刷新 token 过程，不是 Gemini 模型本身。

二、从本例抽象出的排查思路（适用于所有 Google OAuth 类插件）

1. 先分清：是「模型问题」还是「工具/插件 OAuth 问题」

看到类似字段时要高度注意：

  • error_type: "ToolProviderOAuthError"
  • 报错 URL 是 https://oauth2.googleapis.com/token

这两个信号基本说明：

  • 这是 工具/插件的 OAuth 问题，尤其是 Google 系（Gmail、Calendar、Drive 等），
  • 而不是 LLM 模型（Gemini / OpenAI 等）本身的问题。

通用建议：

  1. 先确认错误信息里是否出现：
    • ToolProviderOAuthError
    • oauth2.googleapis.com/token
  2. 回头检查当前流程中：
    • 是否启用了 Gmail 等 Google 工具
    • 如果有，优先怀疑工具，而不是模型

2. 识别「token 刷新失败」vs「首次授权失败」

日志中有关键字：

Error refreshing credentials
token refresh
400 Client Error at oauth2.googleapis.com/token

这类信息表明：

  • 插件 之前是授权成功过的（有 refresh token）
  • 当前是在 刷新 access token 时失败，而不是在第一次走 OAuth 时就失败

这种 400 错误常见原因包括：

  • refresh token 失效 / 被撤销
  • OAuth 客户端（client_id / client_secret）被改了
  • Google 侧应用/权限被调整，导致旧的 token 不再有效

通用建议：

  • 遇到「refreshing credentials」「token refresh」字样：
    • 从「重新授权工具」入手（重新走一次 Gmail / Google OAuth 登录流程）
    • 而不是先去改模型 API Key

3. 用「关闭工具」的方式，快速定位是模型还是插件

为了避免像本帖一样一开始就怀疑 Gemini，可以用一个简单的隔离策略：

  1. 在同一个应用 / 工作流中：
    • 先禁用所有工具/插件（包括 Gmail），只保留 LLM 节点
    • 再运行一次
  2. 情况分两类：
    • 如果 模型单独运行没问题 → 模型配置基本 OK，问题在某个工具
    • 如果 不带工具也报错 → 再回过头看模型的 API Key、模型名称、配额等

在本帖里，如果一开始就只跑 Gemini 而不带 Gmail，很容易看出错不在模型上。

4. 如何快速判断是哪一个 Google 插件有问题

当你确认是 OAuth 问题后，还要进一步确认到底是 Gmail、Calendar 还是其他插件。

实用方法：

  • 看错误发生的节点附近：是哪个工具节点在执行时报错
  • 如果不确定：
    • 依次禁用（或删除）可疑插件，再运行
    • 当禁用某个插件后错误消失，就能锁定它是问题来源

在本帖中就是：
一开始以为是「Gemini 模型节点」，后来才意识到真正出问题的是 同一个流程里启用的 Gmail 插件。

5. 遇到 400 Bad Request + oauth2.googleapis.com/token 时的通用解决步骤

适用于 Gmail / Calendar / Drive 等所有基于 Google OAuth 的插件：

  1. 在 Dify 中重置该插件的授权

    • 移除当前 Google 账号连接（或重新配置插件）
    • 再次点击授权按钮，走一遍完整的 OAuth 登录 / 授权流程

  2. 在 Google 账号 / Google Cloud Console 侧检查

    • 用户 Google 账号里「第三方应用访问权限」中，是否把该应用的访问给撤销过
    • Google Cloud Console 中：
      • OAuth client 是否被删除 / 禁用
      • client_id、client_secret 是否被替换，但插件里没更新
      • 配置的 redirect URI 是否仍然正确

  3. 确认环境是否一致

    • 换了新的 OAuth 客户端或新建了 GCP 项目后，老的 refresh token 基本都会失效
    • 这时必须重新授权，而不是反复重试旧 token

三、给后续用户的简短提醒

  • 报错里出现：

    • ToolProviderOAuthError
    • https://oauth2.googleapis.com/token

    时，要 优先怀疑 Google 类插件（比如 Gmail），
    不要第一时间「怪到模型头上」去（比如 Gemini、GPT 等）。

  • 在复杂工作流里，先用“只保留模型节点”的方式做一次最小化测试：

    • 如果模型单独能跑通，多半是某个工具/插件（特别是 OAuth 工具）出了问题。

这一贴的教训就是：
看上去像是 “Gemini 模型错误”，实际上是 “Gmail 插件 OAuth 刷新失败”，以后大家看到类似错误信息时，可以先从这里入手排查。