前言：为什么你需要搞定 Cookie？

兄弟们，我是 N8N大学 的主编。最近在社群里，发现很多人被同一个问题卡住：明明接口跑通了，怎么一到登录后的接口就疯狂报错？

其实，这背后往往是 Cookie 在作祟。在 Web 自动化中，Cookie 就是你的“通行证”。没有它，服务器就不认识你，把你当成陌生人拒之门外。

今天，笔者就带大家硬核拆解一下，如何在 n8n 的 HTTP Request 节点中，像浏览器一样优雅地获取、存储并发送 Cookie。

核心概念：Cookie 管理的两种模式

在 n8n 中处理 Cookie，本质上是在处理 HTTP 请求头中的 Set-Cookie 和 Cookie 字段。我们要搞清楚 n8n 的两种处理模式：

1. 手动模式（Manual）： 也就是我们常说的“硬编码”。你手动从响应头里提取 Cookie，存入变量，下次请求时手动带入。这是最灵活但最累的方式。
2. Session 模式（Session）： n8n 自动帮你管理。只要你在同一个“会话”里，它会自动保存并发送 Cookie，就像你用同一个浏览器窗口操作一样。

搞懂这两点，你就解决了 80% 的困惑。

实操一：手动模式（硬核提取与注入）

这种模式适合单次请求，或者 Cookie 需要经过特殊处理（比如加密）的场景。

步骤 1：获取 Cookie

假设你发送了一个登录请求。在 HTTP Request 节点的响应中，我们需要去抓取响应头（Response Headers）。

关键参数：Headers -> Set-Cookie。

你可以使用 Set 节点或者 Function 节点来提取它。例如，如果返回的 Set-Cookie 是一个数组，你可能需要取第一个元素，或者用表达式截取特定的字符串。

步骤 2：存储 Cookie

提取出来的 Cookie 字符串，通常保存在 Set 节点的 Workflow Data 中。假设我们存为 myAuthCookie。

注意：有些 Cookie 带有 HttpOnly 属性，这意味着 JS 无法读取，但在 n8n 的 HTTP 节点层面，只要响应头里有，我们就能拿到。

步骤 3：发送 Cookie

这是最关键的一步。在后续需要验证身份的 HTTP Request 节点中：

1. 点击 Options（选项）。
2. 找到 Headers -> Custom Headers（自定义请求头）。
3. 添加一个 Header：
   • Key: Cookie
   • Value: {{ $json.myAuthCookie }} (引用你存储的变量)

这样，你就手动完成了一次 Cookie 的接力。

实操二：Session 模式（模拟浏览器的自动管理）

如果你需要连续请求多个接口（比如：先登录 -> 获取用户信息 -> 修改设置），手动模式太繁琐，且容易丢失中间产生的新 Cookie。这时，请直接使用 Session Mode。

操作步骤：

在 HTTP Request 节点的 Authentication 设置中：

1. 将 Authentication 类型改为 Generic Credential Type。
2. 在下方的下拉菜单中选择 Cookie。
3. 或者，更简单的方法是：直接在 Options -> Session -> Create New Session。

当你开启 Session 后，n8n 会创建一个临时的“浏览器环境”。你在该 Session 下发起的所有请求，n8n 都会自动处理 Set-Cookie 响应，并在下一个请求中自动带上。

笔者建议：只要涉及登录态的连续操作，无脑选 Session，能省下一半的配置时间。

避坑指南：实战中常见的 3 个坑

虽然 n8n 很强大，但在处理 Cookie 时，有些细节不注意会让你排查半天。

1. SameSite 和 Secure 属性

现在的浏览器和服务器对 Cookie 安全性要求很高。如果你遇到“Cookie 未设置”的情况，检查一下目标服务器返回的 Set-Cookie 是否强制了 Secure（仅 HTTPS）或 SameSite=Strict。如果你的 n8n 请求是 HTTP，或者跨域环境受限，这些 Cookie 可能会被浏览器策略丢弃。

2. Cookie 的生命周期 (Max-Age/Expires)

有些 Cookie 是会话级的（浏览器关了就失效），有些是持久化的。如果你的流程跑得很慢，或者中间有长时间的等待，记得检查 Cookie 是否过期。在 Session 模式下，如果 Session 维持时间过长，中间的 Cookie 可能会刷新，导致后续请求失效。

3. 响应头里的多个 Set-Cookie

一个响应里可能包含多个 Set-Cookie 字段（比如一个是 SessionID，一个是 CSFR Token）。HTTP Request 节点默认可能只处理第一个，或者把它们揉成一个字符串。在手动模式下，你可能需要编写简单的 JS 代码来遍历响应头，提取所有需要的 Cookie 并拼接成标准的 Cookie: name1=value1; name2=value2 格式。

FAQ 常见问题

Q1: 为什么我明明设置了 Cookie，服务器还是返回 401/403？

最可能的原因是 Cookie 格式不对。标准的 HTTP Cookie 头应该是 Cookie: key=value; key2=value2。如果你直接把整个 Set-Cookie 的响应头内容塞进去，通常会报错。请务必只保留 key=value 部分，去掉 Path、HttpOnly 等属性。

Q2: n8n 的 Session 模式能跨 Workflow 使用吗？

不能。Session 是绑定在当前 HTTP Request 节点的执行上下文中的。如果你想跨 Workflow 共享 Cookie，你需要把 Cookie 提取出来，存入 Redis、数据库或者全局变量中，然后在另一个 Workflow 里手动注入。

Q3: 如何调试我的 Cookie 是否发送成功？

在 HTTP Request 节点的 Options 里，开启 Full Response。这样你不仅能看返回的 Body，还能看到请求发送的 Headers 和服务器返回的 Headers。仔细对比 Request Headers 里有没有你的 Cookie，就能立刻定位问题。

总结与资源

搞定 Cookie，本质上就是处理好 HTTP 头中的 Set-Cookie 和 Cookie。记住 N8N大学 的口诀：

• 单次请求，手动提取，Header 注入。
• 连续操作，开启 Session，自动管理。

Cookie 是 Web 自动化最难缠的“拦路虎”，但只要你掌握了上述技巧，它就会变成你最忠诚的“通行证”。如果觉得本文对你有帮助，欢迎来 N8N大学 官网（n8ndx.com）交流更多硬核玩法！