大家好，我是 N8N大学 的主编。后台最近收到不少反馈，说在使用 HTTP Request 节点调用第三方 API（比如飞书、钉钉、或者某些 SaaS 平台）时，明明 Key 和 Secret 都填对了，却一直报 401 Unauthorized 错误。

这种报错最搞人心态，因为它是“权限不足”的通用提示。但问题往往不是你没有权限，而是 n8n 向 API 发送的“身份凭证”格式不对，或者压根没发过去。今天，笔者就带你从底层逻辑把 n8n 的认证机制彻底盘清楚。

问题复现：为什么 401 错误这么让人头疼？

在 n8n 中，当我们配置 HTTP Request 节点时，通常是在“认证”（Authentication）选项卡里设置凭证。如果你遇到了 401 错误，通常会看到以下几种情况：

• 请求头里缺少了 Authorization 字段。
• Token 过期了，或者刷新机制没配置好。
• Webhook 或 API 调用时，签名（Signature）算法不匹配。

笔者提示： 401 和 403 要区分开。401 是“我不认识你是谁”（认证失败），403 是“我认识你，但你没资格进这个门”（授权失败）。

原因分析：n8n 到底在背后做了什么？

很多新手以为填了 API Key 就完事了，其实 n8n 作为一个低代码工具，在发起 HTTP 请求时，需要根据你选择的认证类型，自动组装 HTTP Header。

最核心的逻辑是：**n8n 的凭证系统充当了“翻译官”**。它把你在界面上填的 ID 和 Secret，翻译成 API 平台能听懂的语言（比如 Bearer Token、Basic Auth 或者复杂的 HMAC 签名）。如果“翻译”过程出错，或者你选错了“方言”，API 服务器就会毫不留情地返回 401。

解决方案：三步搞定 401 认证难题

别急，我们从最简单的通用设置到复杂的自定义签名，一步步来排查。

第一步：检查“认证”类型是否选对

这是 N8N 大学最常强调的点。在 HTTP Request 节点的设置中，找到 Authentication 下拉菜单。不要无脑选“None”或者默认项。

• Generic Credential Type（通用凭证类型）： 适用于大多数简单的 API。如果你的 API 只需要 X-API-Key 或者 Authorization: Bearer xxx，选这个。
• HTTP Header Auth（HTTP 头认证）： 适用于需要自定义 Header 名称的场景（比如某些老式 API 用 AppKey 和 AppSecret）。
• OAuth2 / Basic Auth： 如果你的 API 文档明确要求这两种标准协议，请严格对应选择。

第二步：配置“通用凭证” (Generic Credentials)

这是最常用的配置方式。点击“Credential Data”展开设置，重点看这几个字段：

• Header Name（头部名称）： 默认通常是 Authorization。有些平台（如腾讯云）可能需要 X-TC-Key。
• Header Value（头部值）： 这里的格式至关重要。
  • 如果是 Bearer Token，格式为：Bearer 你的Token（注意中间有个空格）。
  • 如果是 Basic Auth，格式为：Basic Base64(Username:Password)。

如果你的 API 需要多个 Header（比如同时需要 Token 和 Timestamp），请使用 Header Auth 类型，或者在“通用凭证”中使用“自定义”选项（如果版本支持）。

第三步：处理“动态签名”与“预请求”逻辑

这是最容易导致 401 的硬骨头。很多国产平台（如飞书、钉钉、阿里云）的 API 并不是简单的 Key+Secret，而是需要基于时间戳和 Secret 进行 HMAC-SHA256 签名。

n8n 的标准凭证有时候无法直接处理这种复杂的签名逻辑。这时候，我们不能依赖“Credential”，而要手动在节点里解决：

1. 在 HTTP Request 节点前，加一个 Function 或 Set 节点。
2. 在 Function 节点中，使用 Node.js 代码生成签名。例如，拼接 timestamp + method + path + body，然后用 crypto 模块进行 HMAC 加密。
3. 将生成的签名字符串，通过 Set 节点注入到 HTTP Request 的 Headers 中。

举个例子，调用飞书 API 时，除了 Authorization: Bearer access_token，通常还需要校验 tenant_key。如果 n8n 的官方飞书凭证节点（如果有的话）无法满足你的特定需求，手动拼 Header 是最稳妥的方案。

避坑指南：实战中容易忽略的细节

配置对了但还是报 401？检查以下细节：

• Token 过期： 某些 API 的 Access Token 有效期只有 2 小时。如果你的流程是定时执行的，必须配置 OAuth2 的自动刷新机制，或者在流程开头先跑一次“获取新 Token”的逻辑。
• URL 拼写错误： 有时候 401 其实是 404 的“伪装”。检查 Base URL** 是否包含版本号（如 /v1/user），路径拼错会导致鉴权服务器找不到对应资源，返回 401。
• 环境变量污染： 如果你使用了环境变量来存 API Key，检查一下 n8n 容器重启后，环境变量是否丢失了。这在 Docker 部署中很常见。

FAQ 问答

Q1: 为什么我填了 Token 还是 401？

A: 最常见的原因是 格式错误。请检查 Header Value 是否包含了必要的前缀（如 "Bearer "）。另外，确保你的 Token 是 Access Token 而不是 API Key，两者通常不能混用。

Q2: n8n 支持自定义 HMAC 签名吗？

A: n8n 的内置凭证对标准 OAuth2 和 Basic Auth 支持很好。对于高度定制的 HMAC 签名（如 AWS 签名），建议使用 Code Node 手动生成签名参数，然后传递给 HTTP Request 节点。

Q3: 如何调试 n8n 的 HTTP 请求头？

A: 在 HTTP Request 节点执行后，点击运行结果中的节点，查看 "Input" 和 "Output" 数据。虽然 n8n 默认不直接显示发送的原始 Header，但你可以通过 json 格式查看发送的 payload。如果需要查看完整的请求细节，建议在 n8n 的 Docker 日志中查看 Debug 模式输出（需要开启调试日志）。

总结与资源

解决 n8n 的 401 错误，核心在于“翻译”：确保 n8n 的凭证配置能准确翻译成 API 所需的认证 Header。对于简单的 API，善用 Generic Credential Type；对于复杂的签名逻辑，不要犹豫，直接上 Code Node 手动处理。

如果你在配置飞书、钉钉或 AWS 的 API 时遇到具体困难，欢迎在 N8N大学 社区留言，笔者会挑选典型问题进行实战演示。