写在前面：那个让我怀疑人生的下午

笔者作为 N8N大学 的主编，今天不想跟你扯什么“HTTP 协议的原理”，也不想背诵 RFC 文档。咱们就聊点实在的：你在用 n8n 跑自动化流程时，HTTP Request 节点是不是经常给你整点“惊喜”？

就在昨天，为了对接一个第三方 API，我硬生生在 HTTP Request 节点上耗了一下午。明明在 Postman 里跑得飞快，一到 n8n 里就报 400、500，甚至直接超时。那种“代码没写错，但就是不通”的挫败感，我太懂了。

今天，我就把这几个我花了一下午才搞明白的“坑”挖出来，用大白话讲给你听。避过这些坑，至少能帮你省下两罐咖啡的时间。

坑一：参数传了，但没完全传——Query String 与 Body 的爱恨情仇

这是新手最容易栽的第一个跟头。很多 API 文档写得模棱两可，只说“需要传参”，却没说清楚是放在 URL 里还是请求体里。

在 n8n 的 HTTP Request 节点中，如果你在 Query Parameters 里填了参数，n8n 会自动帮你拼接到 URL 后面（比如 ?key=value）。但如果你在 Body 里也填了同名参数，或者 API 要求的是 JSON 格式的 Body，你就必须选对 Body Content Type。

笔者的踩坑现场： 我当时在 Query Parameters 里填了 id=123，但 API 返回 400 Bad Request。折腾半天发现，这个 API 要求的是 JSON 格式的 Body，而不是 URL 参数。

避坑指南：

• 先看 API 文档，确认参数是 Query Param 还是 Body。
• 如果是 Body，务必在 Options 里选择正确的 Content-Type（通常是 application/json）。
• 如果你的参数是嵌套对象，记得把 Body 切换到 JSON 模式，直接贴 JSON 字符串，别用 Form-Data 模式硬凑。

坑二：认证方式选错——Header 里的 Authorization 噩梦

API 认证是另一个重灾区。n8n 支持很多认证方式，比如 Basic Auth、Header Auth、OAuth2 等。但有时候，API 的要求很“奇葩”。

有的 API 要求 Authorization: Bearer ，有的要求 api-key: ，还有的甚至要求把 Token 放在 URL 参数里。如果你在 n8n 的 Authentication 下拉框里选了默认的 None，却忘了在 Headers 里手动添加，报错 401 Unauthorized 是必然的。

笔者的踩坑现场： 某个 API 文档说“使用 Bearer Token”，我选了 n8n 的 Generic Credential Type，结果死活不通。最后发现，我应该直接用 Header Auth，并在 Header Name 里填 Authorization，Value 填 Bearer {{你的Token}}。

避坑指南：

• 如果 Authentication 下拉框里没有现成的选项，直接选 Generic Credential Type 或 Header Auth。
• 手动添加 Header 时，注意大小写。有些 API 对 Authorization 和 authorization 敏感。
• 如果 Token 需要动态获取（如 OAuth2），善用 n8n 的 Credentials 功能，不要把 Token 硬编码在节点里，否则过期了你又得回来改。

坑三：JSON 解析失败——那个该死的“非法字符”

这是一个非常隐蔽的坑。当你收到 API 返回的数据，n8n 提示 JSON Parse Error 或者 Unexpected token 时，通常不是你写错了代码，而是返回的数据本身有问题。

有些老旧的 API（或者被污染的数据）会返回非标准的 JSON，比如单引号包裹的字符串，或者包含非法的转义字符。n8n 的 HTTP Request 节点默认使用严格的 JSON 解析器，一旦遇到这种情况，整个流程就会卡死。

笔者的踩坑现场： 我在拉取某论坛数据时，返回的 JSON 里包含了一个未转义的换行符。n8n 直接报错，我甚至怀疑是网络断了。后来在 Log 里看到 Raw Data 才发现端倪。

避坑指南：

• 如果怀疑数据格式有问题，在 HTTP Request 节点的 Options 中，勾选 Full Response。这样你可以看到原始的 Header 和 Body。
• 如果必须处理脏数据，可以在 HTTP 节点后接一个 Set 节点或 Function 节点，使用 JSON.parse() 配合 try-catch 手动处理，或者先用字符串替换函数清洗数据。
• 记住：n8n 不会自动帮你“修复”不合法的 JSON，它只会报错。源头数据清洗很重要。

  坑四：SSL/TLS 证书验证——本地开发的拦路虎

  当你开发本地 API 或者使用自签名证书的测试环境时，HTTP Request 节点会抛出 SELF_SIGNED_CERT_IN_CHAIN 或 UNABLE_TO_VERIFY_LEAF_SIGNATURE 错误。这是因为 n8n 默认开启了严格的 SSL 验证。

  为了安全，这个机制不能关，但在测试环境，我们确实需要暂时绕过它。

  笔者的踩坑现场： 笔者在本地用 Docker 起了个 HTTPS 服务做测试，n8n死活连不上。重启容器、检查防火墙，折腾一小时，最后发现是证书问题。

  避坑指南：

  • 在 HTTP Request 节点的 Options 里，找到 Reject Unauthorized，将其设置为 Off（或 false）。
  • 警告： 这个选项仅用于测试环境！生产环境中务必开启 SSL 验证，否则有中间人攻击风险。
  • 如果是自己的服务，最好的解决办法是把 CA 证书导入到 n8n 运行的系统信任库中，而不是简单粗暴地关闭验证。

  FAQ：关于 HTTP Request 节点的常见疑问

  Q1: 为什么我在 Postman 里能跑通，n8n 里却报错？
  A: 最常见的原因是 Credentials（认证信息）没配对，或者 Content-Type 设置不一致。Postman 很多时候会自动推断，但 n8n 需要你明确指定。检查 Header 和 Body 的格式是否完全一致。

  Q2: HTTP Request 节点支持断点续传或大文件上传吗？
  A: n8n 的 HTTP Request 节点主要处理中小型数据流。对于超大文件（如视频、大型压缩包），建议使用流式上传或分块上传策略，但这需要更复杂的配置（通常涉及自定义代码节点）。如果文件不大，直接作为二进制数据上传即可。

  Q3: 如何处理 API 的限流（Rate Limit）？
  A: 这是一个高级话题。如果 API 限制每秒请求次数，你直接跑循环调用 HTTP Request 节点会被封 IP。你需要使用 Wait 节点在每次请求之间插入延迟，或者使用 Split Out 节点控制并发数。N8N大学 之后会专门写一篇关于限流的文章。

  总结与资源

  HTTP Request 节点是 n8n 里最强大但也最“玄学”的节点。它就像一把瑞士军刀，用好了无所不能，用不好就容易割到手。

  记住今天的几个核心点：参数位置要对、认证方式要准、数据格式要净、SSL 验证要懂。下次再遇到报错，别急着删节点，先对照这几个坑检查一遍。

  如果你在 n8n 的使用中遇到了其他棘手的报错，欢迎在 N8N大学 的社区留言，笔者会挑选典型案例进行深度拆解。