在 n8n 的世界里，HTTP Request 节点就像是一把瑞士军刀。很多时候，我们以为 n8n 只能连接那些预置的、带绿色图标的节点，却忽略了它强大的通用性。

今天，N8N大学就来带大家做一件看似“硬核”实则非常实用的事：利用 HTTP Request 节点直接连接数据库 API（以 PostgreSQL 和 MySQL 为例），绕过繁琐的 ODBC/JDBC 驱动配置，实现跨网络的数据库操作。

这不仅仅是一份配置文档，更是笔者在实际项目中摸爬滚打总结出的“避坑指南”。如果你正苦于无法在内网环境直接部署 n8n，或者需要通过 RESTful API 管理云数据库，这篇指南就是为你准备的。

一、场景导入：为什么我们要用 HTTP 连数据库？

通常情况下，n8n 连接数据库会使用 Postgres 或 MySQL 节点。这在单机部署、且数据库与 n8n 在同一局域网（或直连）时非常顺畅。

但现实往往很骨感：

• 网络隔离：数据库位于公司内网，n8n 部署在公网云服务器，无法直接 TCP 连接。
• 安全限制：云数据库（如 AWS RDS、阿里云 RDS）禁止了 3306/5432 等端口的公网 IP 直连，只允许通过 HTTPS 访问其数据管理 API。
• 统一出口：为了统一管理认证和日志，运维团队要求所有请求必须走 API 网关。

  这时候，HTTP Request 节点就成了唯一的救星。只要你能通过 cURL 或 Postman 调通 API，n8n 就能复刻同样的逻辑。

  二、准备工作：硬性条件清单

  在开始之前，请确保你手头有以下资源（缺一不可）：

  1. 一个可用的 n8n 实例：无论是 Cloud 版、自托管 Docker 还是桌面版均可。
  2. 数据库 API 凭证：
     • 如果是 PostgreSQL（使用 REST API 方式，如 PostgREST）：需要数据库 URL、API Key 或 JWT Token。
     • 如果是 MySQL（使用云服务商提供的 REST API）：需要 Endpoint URL、Access Key ID 和 Secret。
     • 如果是 自建 API 服务（如 Node.js + Express 封装）：需要完整的接口文档（URL、Method、Header、Body 格式）。
  3. Postman 或 curl：用于在 n8n 配置前验证 API 是否正常连通。

  三、核心实操：三步搞定 API 连接

  笔者将以一个通用的场景为例：通过 HTTP 请求向数据库插入一条数据。我们将使用 PostgREST（一种将 PostgreSQL 转为 RESTful API 的流行方案）作为演示对象，逻辑同样适用于其他数据库 API。

  步骤 1：配置基础请求信息

  拖拽一个 HTTP Request 节点到画布，先填好“硬参数”：

  • Method: 选择 POST（如果你是查询数据，则选 GET）。
  • URL: 输入你的数据库 API 地址。例如 PostgREST 的典型格式是 http://localhost:3000/users（这里的 users 是你的表名）。
  • Authentication: 这是关键！根据 API 类型选择：
    • Generic Credential Type: 适用于 Bearer Token (JWT) 或 Basic Auth。
    • Header Auth: 适用于需要自定义 Header（如 x-api-key）的场景。

  笔者提示：如果 API 使用 JWT 认证，记得在 Header 中添加 Authorization: Bearer <你的Token>。你可以将 Token 保存在 n8n 的 Credentials 中，避免硬编码。

  步骤 2：构建请求体 (Body)

  对于 POST 请求，我们需要告诉数据库我们要插入什么数据。

  1. 切换到 Body 选项卡。
  2. 选择 JSON 格式（这是绝大多数现代 API 的标准）。
  3. 在输入框中编写 JSON 结构。假设我们要插入一个用户：

  {
    "name": "张三",
    "email": "zhangsan@example.com",
    "role": "admin"
  }

  在 n8n 中，你完全可以使用 表达式 动态生成数据。例如，从上游节点获取数据：

  {
    "name": "{{$json.name}}",
    "email": "{{$json.email}}",
    "role": "user"
  }

  步骤 3：处理响应与映射

  请求发出后，数据库通常会返回创建成功的数据对象（包含自增 ID 等）。

  1. 在 HTTP Request 节点的 Options 中，确保勾选 Full Response 或根据需要调整。
  2. 如果 API 返回的是数组（例如 [{...}]），n8n 默认可能只取第一个元素。你可以在节点设置的 Response 部分选择 Let HTTP Request node issue an error 来处理异常，或者在下个节点使用 {{$json[0]}} 提取数据。
  3. 建议在 HTTP Request 节点后连接一个 Set 节点，用于规范化输出数据，方便后续流程使用。

  四、避坑指南：实战中容易报错的细节

  在 N8N大学 的实战案例中，90% 的失败都源于以下几个细节，千万别忽视：

  1. Content-Type 头缺失导致的 415 错误

  很多数据库 API 严格要求请求头必须包含 Content-Type: application/json。

  解决方案：

  • 在 HTTP Request 节点的 Headers 选项卡中，手动添加一行：
  • Key: Content-Type
  • Value: application/json

  2. SSL/TLS 证书验证失败

  如果你的 API 使用了自签名证书（常见于内网测试环境），n8n 默认会拒绝连接，报错类似于 certificate has expired 或 SELF_SIGNED_CERT_IN_CHAIN。

  解决方案：

  在 HTTP Request 节点的 Options -> SSL Certificates 部分，勾选 Ignore SSL certificate validation（忽略 SSL 证书验证）。

  注意：生产环境请务必使用正规证书，仅在测试环境忽略验证。

  3. 数据格式不匹配

  数据库对数据类型非常敏感。例如，PostgreSQL 的 timestamp 字段不能直接接收字符串 "2023-10-01"，可能需要 ISO 8601 格式。

  解决方案：

  在构建 JSON Body 前，使用一个 Function 节点或 Set 节点对数据进行预处理。例如，使用 JavaScript 的 new Date().toISOString() 格式化时间。

  五、FAQ 问答

  Q1: 使用 HTTP Request 连接数据库会有性能问题吗？

  A: 相比原生的 TCP 连接（如原生 Postgres 节点），HTTP 协议确实会有额外的开销（握手、Header 解析）。但在低频或中频的数据同步场景下（如每分钟几百次请求），性能差异几乎可以忽略不计。如果是海量数据批量写入，建议使用原生节点或消息队列。

  Q2: 我的 API 需要复杂的 OAuth2 认证，n8n 支持吗？

  A: 完全支持。n8n 的 HTTP Request 节点内置了 OAuth2 认证流程。你只需在 Credentials 中配置 Client ID、Client Secret 和 Scope，n8n 会自动帮你获取和刷新 Token，无需手动处理。

  Q3: 这种方式能执行复杂的 SQL 查询吗？

  A: 这取决于你的 API 层。如果你使用的是类似 PostgREST 或 GraphQL 的工具，你可以通过 URL 参数（如 ?select=name,age&age=gt.18）执行复杂查询。如果你的 API 只是简单封装了 CRUD，那么复杂的 SQL 逻辑需要在后端数据库 API 中预先定义好。

  总结与资源

  通过 HTTP Request 节点连接数据库 API，打破了 n8n 与数据库之间的网络壁垒，让自动化流程的部署更加灵活。

  N8N大学 核心建议：

  • 先用 Postman 调通 API，再复制到 n8n。
  • 善用 Credentials 管理敏感信息。
  • 遇到 4xx/5xx 错误，先检查 Header 和 SSL 设置。

  如果你对特定数据库（如 MongoDB Atlas API 或 Redis Cloud API）的 HTTP 连接配置有疑问，欢迎在评论区留言，笔者将挑选高频问题在下期教程中详解。