嘿，我是N8N大学的主编。
在社区里潜水时，我发现大家在调用 n8n API 时，最常卡住的地方就是认证环节。很多人对着 Generic Auth (通用认证) 这个选项发愁，参数填了一堆，却总是返回 401 Unauthorized。
如果你也因为搞不定 API 认证而想放弃自动化，那这篇文章就是为你准备的。别再死磕那个“通用”的黑盒了，今天笔者手把手教你用 自定义头（Custom Header） 的方式，硬核搞定 n8n API 认证。
为什么“通用认证”总是让你头疼？
在开始实操前，我们得先明白问题出在哪。
n8n 的 Generic Auth Credentials 设计初衷是为了兼容各种复杂的认证协议，比如 OAuth1、Digest Auth 等。但对于 n8n 自身的 API 来说，它通常只需要一个简单的 Authorization Header。
当你试图用“通用认证”去匹配一个简单的 Bearer Token 时，往往因为参数映射不对，或者加密算法选错，导致请求被拒绝。这就是典型的“杀鸡用牛刀”，反而把自己绕晕了。
核心实操：自定义 Header 认证法
其实，调用 n8n API 最稳健、最直白的方法，不是用内置的认证节点，而是手动在 HTTP 请求节点中注入 Header。这种方法兼容性极强，无论你的 n8n 是本地跑的还是云端部署的，都能通。
第一步：获取你的 API Key
首先，你需要一把“钥匙”。
- 登录你的 n8n 实例。
- 点击左下角的 User Menu (头像) -> Settings。
- 在 API 选项卡下，点击 Add API Key。
- 给它起个名字（比如 “My-App-API”），然后复制生成的 Key。注意，这个 Key 只显示一次，务必保存好。
第二步：构建 HTTP Request 节点
现在，我们来搭建工作流的核心。假设我们要获取当前工作流的列表（GET /workflows）。
- 在工作流中添加一个 HTTP Request 节点。
- Authentication 选择 None（是的，选 None，我们手动处理）。
- Method 选择 GET。
- URL 填写你的 n8n API 地址。格式通常是：
http://localhost:5678/rest/v1/workflows（如果是云端，请替换为你的域名）。
第三步：手动注入 Header（关键步骤）
这是最容易出错的地方，请仔细核对：
- 在 HTTP Request 节点中，找到 Options -> Headers。
- 点击 Add Header。
- 在 Name 栏输入：
n8n-api-key（注意大小写，建议全小写以避免服务器大小写敏感问题）。 - 在 Value 栏输入：你刚才复制的 API Key。
注意： n8n 的 API 认证不遵循标准的 Authorization: Bearer xxx 格式，而是使用自定义的 n8n-api-key。这是新手最容易踩的坑。
第四步：测试与验证
点击 Execute Node。如果配置正确，你应该能在下方的 Output 中看到 JSON 格式的工作流列表。如果返回 401，请回头检查 Key 是否复制完整，或者 Header 名称是否拼写正确。
避坑指南：实战中容易报错的细节
笔者在实操中遇到过两个典型问题，分享给大家：
- 端口问题： 如果你使用了反向代理（如 Nginx）或 Docker 映射，确保 URL 中的端口（默认 5678）是外部可访问的。如果工作流在 Docker 容器内，千万不要用
localhost，应该用宿主机 IP 或容器网络名。 - HTTPS 强制跳转： 如果你的 n8n 配置了 HTTPS，但 URL 里写的是
http，有些环境会自动跳转导致 Header 丢失。建议直接在 URL 中写死https://。
进阶玩法：通过 API Token 认证
除了 API Key，n8n 还支持通过 User Session Token 认证。这种方法适合临时调试。
你需要先通过登录接口获取 Token：
- 使用 HTTP Request 节点。
- URL:
http://localhost:5678/rest/v1/login。 - Method: POST。
- Body:
{"username": "你的用户名", "password": "你的密码"}。 - 执行后，从返回的 JSON 中提取
data.token。
拿到这个 Token 后，添加到后续 HTTP 节点的 Header 中：
- Name:
Authorization - Value:
Bearer {{你的Token}}
虽然这种方法可行，但为了安全和稳定性，N8N大学 更推荐使用 API Key。
FAQ 常见问题解答
1. 为什么我用 Generic Auth 里的 Header Auth 却报错？
Generic Auth 中的 Header Auth 有时会因为 n8n 版本更新导致参数传递异常。而且 n8n API 的认证头是 n8n-api-key，这是一个自定义头，很多通用认证模块默认只支持标准的 Authorization 头。直接在 HTTP Request 节点里手动写 Header 是最稳妥的。
2. API Key 泄露了怎么办？
立即去 n8n 设置里的 API 页面，删除那个 API Key，然后重新生成一个新的。千万不要把 Key 直接硬编码在公开的工作流代码里，务必使用 n8n 的 Credentials（凭证）系统或环境变量。
3. 调用 API 时提示 “404 Not Found” 怎么解决？
检查你的 URL 路径是否正确。n8n 的 REST API 前缀通常是 /rest/v1/。例如，获取工作流列表不是 /workflows，而是 /rest/v1/workflows。漏掉这个前缀是 404 的主要原因。
总结与资源
搞定 n8n API 认证，核心在于绕过复杂的通用认证模块，直接使用 HTTP Request 节点并手动添加 n8n-api-key 头。这种方法简单、直接、容错率高。
如果你在实操过程中遇到其他奇怪的报错，欢迎在 N8N大学 社区发帖，记得带上你的节点截图和报错日志，我们一起避坑。
