N8n Simple Connector Test

简单连接器测试

概述

一个设计用于对MCP（模型上下文协议）连接器功能进行最简单测试的最小化n8n工作流。此工作流使用一个单一的GET网络钩子端点，该端点会立即返回响应，非常适合快速验证连接性。

目的

这个工作流程的作用是：

1. 快速健康检查验证n8n MCP连接性的最快方法
2. 基本集成测试验证Webhook路由和响应处理
3. 起始模板构建更复杂工作流的基础
4. 调试工具将连接问题与复杂的工作流程逻辑分离开来

工作流程结构

节点

1. Webhook 触发器

- 类型： n8n-nodes-base.webhook - 方法：GET（无需请求体） - 路径： /simple-test - 响应模式： onReceived （立即回复） - 类型版本：2

1. 设置节点（返回响应）

- 类型： n8n-nodes-base.set - 目的：以格式化的方式返回成功响应及状态信息 - 输出： - status“成功” - message“MCP连接器工作正常！” - timestampISO-8601格式的当前时间 - connector_type“n8n-mcp” - 类型版本：3.4

工作流程逻辑

GET /simple-test → Return Response

这是最简单的n8n工作流——一个触发器立即返回格式化数据。

使用方法

安装

1. 进口 workflow.json 导入到您的n8n实例中
2. 激活工作流（切换“激活”开关）
3. 记下n8n提供的webhook URL

测试

Webhook URL 格式：

https://your-n8n-instance.com/webhook/simple-test

浏览器测试： 只需在您的浏览器中打开该网址：

https://your-n8n-instance.com/webhook/simple-test

cURL 测试：

curl https://your-n8n-instance.com/webhook/simple-test

预期响应：

{
  "status": "success",
  "message": "MCP connector is working!",
  "timestamp": "2025-10-12T12:45:00.000Z",
  "connector_type": "n8n-mcp"
}

从Claude桌面端进行测试

在Claude Desktop中使用n8n MCP连接器：

// Simple fetch test
const response = await fetch('https://your-n8n-instance.com/webhook/simple-test');
const data = await response.json();
console.log(data);

或者问问克劳德：

"Can you test my n8n simple connector at https://your-n8n-instance.com/webhook/simple-test?"

配置

工作流设置

• 执行顺序v1（顺序）
• 保存错误执行记录是的
• 保存成功执行（的任务/操作）是的
• 保存手动执行记录不
• 跟踪进度不
• 状态默认未激活（导入后激活）

Webhook 配置

路径： simple-test\ HTTP方法GET（最容易测试）\ 响应模式: onReceived （即时响应，无需等待）\ 认证无（如需添加，请自行添加）

响应数据格式

状态字段

• 类型字符串
• 价值“success”翻译成中文是“成功”
• 目的表示连接成功

消息字段

• 类型字符串
• 价值“MCP连接器工作正常！”
• 目的可读的人类确认

时间戳字段

• 类型字符串
• 表达: ={{ $now.toISO() }}
• 目的证明实时执行

连接器类型字段

• 类型字符串
• 价值“n8n-mcp”
• 目的确定集成类型

用例

1. 初始设置验证

• 在Claude Desktop中配置n8n MCP后的首次测试
• 验证Webhook路由是否正常工作
• 确认n8n实例可访问

2. 解决连接问题

• 确定问题是出在n8n本身还是工作流复杂性上
• 测试网络连接
• 验证身份验证设置

3. 监控与健康检查

• 用作运行时间监控终端
• 纳入自动化测试套件中
• 创建简单的状态页面

4. 学习与发展

• 了解n8n webhook的基本结构
• 基于新Webhook的工作流模板
• 使用 n8n 表达式进行练习

此工作流程的优势

简洁

• 仅2个节点（最小复杂度）
• 无外部依赖
• 无需凭证
• 无需配置

速度

• 即时响应（无异步处理）
• 快速执行（通常\<100毫秒）
• 没有数据库查询或API调用

可靠性

• 没有什么会损坏或出故障
• 无需担心速率限制
• 没有超时问题

可调试性

• 易于理解和修改
• 明确的执行路径
• 易于故障排除

扩展工作流

添加查询参数

修改webhook以接受参数：

{
  "parameters": {
    "path": "simple-test",
    "httpMethod": "GET",
    "responseMode": "onReceived",
    "options": {
      "rawBody": false
    }
  }
}

使用以下方式访问： ?name=value

添加POST支持

改为接受JSON数据：

{
  "parameters": {
    "path": "simple-test",
    "httpMethod": "POST",
    "responseMode": "onReceived"
  }
}

添加身份验证

在头部要求API密钥：

{
  "parameters": {
    "authentication": "headerAuth",
    "headerAuth": {
      "name": "X-API-Key",
      "value": "={{ $credentials.apiKey }}"
    }
  }
}

回声请求数据

将接收到的数据返回：

{
  "assignments": {
    "assignments": [
      {
        "name": "received_data",
        "value": "={{ $json }}"
      }
    ]
  }
}

故障排除

“未找到工作流”错误

• 确保工作流程是 活跃 （用户界面中的切换按钮）
• 检查webhook路径是否与URL匹配
• 验证n8n实例的URL是否正确

未收到回复

• 检查网络/防火墙设置
• 验证n8n实例是否正在运行
• 使用curl进行测试以隔离浏览器问题
• 检查 n8n 日志中的错误

错误的响应格式

• 验证Set节点配置
• 检查表达式是否正确
• 在n8n用户界面中测试节点执行

超时错误

• 在这个简单的工作流程中不应发生
• 如果确实如此，请检查n8n服务器资源
• 验证数据库连接性

演出

响应时间

典型回复： 50-150毫秒

• 网络延迟：20-50毫秒
• n8n处理时间：20-50毫秒
• 总计：平均约100毫秒

吞吐量

能处理：

• 每秒100+个请求 在性能一般的硬件上
• 仅受n8n实例资源的限制
• 工作流程本身不存在瓶颈

资源使用情况

• 中央处理器可忽略不计（每次请求\<1%）
• 内存每次执行约5MB
• 存储最小化（仅执行日志）

安全考虑因素

当前安全状况

• ❌ 未认证
• ❌ 无速率限制
• ❌ 公共端点

建议投入生产

{
  "webhook": {
    "authentication": "headerAuth",
    "headerAuth": {
      "name": "Authorization",
      "value": "Bearer YOUR_SECRET_TOKEN"
    }
  }
}

速率限制

通过n8n或反向代理实现：

• 每分钟每个IP 100次请求
• 连续失败10次后封锁

HTTPS

在生产环境中始终使用HTTPS：

• 防止中间人攻击
• 敏感数据所需
• 更有利于搜索引擎优化和建立信任

监测

健康检查集成

在监控工具中使用此终端节点：

Uptime Robot（持续运行机器人）

• 类型：HTTP(s)
• URL: https://your-instance.com/webhook/simple-test（中文可译为：“网址：https://your-instance.com/webhook/simple-test”）
• 预期：响应状态码200 + 响应体中包含“success”

Pingdom：

• 类型：HTTP 检查
• 检查：“MCP 连接器工作正常！”
• 警报：状态！= 200

记录日志

在n8n中的监控器：

• 每小时执行次数
• 平均响应时间
• 错误率
• 地理分布

与其他测试工作流程的比较

技术规格

n8n 版本要求

• 最低1.0.0
• Webhook 节点类型版本2
• 设置节点版本类型 3.4
• 使用以下工具测试1.112.6

节点ID

• Webhook（网络钩子）： webhook-trigger
• 设置节点： response-node

连接架构/连接模式

{
  "Webhook": {
    "main": [
      [{
        "node": "Return Response",
        "type": "main",
        "index": 0
      }]
    ]
  }
}

HTTP 响应头

Content-Type: application/json
Status: 200 OK
X-n8n-Workflow-Id: [workflow-id]

相关工作流

• MCP手动触发测试 - 手动执行测试
• 线性松弛集成 - 高级集成示例

快速入门指南

5分钟设置

1. 导入工作流 - 复制 workflow.json 的内容
2. 激活工作流 - 在n8n UI中切换激活状态
3. 复制Webhook URL - 来自webhook节点设置
4. 在浏览器中测试 - 粘贴URL并按回车键
5. 验证响应 - 应该看到带有“success”键的JSON

首次测试检查清单

• \[ \] 工作流导入成功
• \[ \] 工作流处于活动状态（未暂停）
• \[ \] Webhook URL 已正确复制
• \[ \] 浏览器显示JSON响应
• \[ \] 响应中包含“成功”状态
• \[ \] 时间戳为当前时间

常见问题解答（FAQ）

问：为什么使用GET而不是POST？\ A: GET 请求更容易测试——只需在浏览器中粘贴 URL 即可。无需任何工具。

问：我需要激活工作流吗？\ A: 是的！非活动的工作流不会响应Webhooks。

问：我可以更改webhook的路径名称吗？\ A: 是的，在webhook节点中更改“path”参数。

问：为什么选择“onReceived”响应模式？\ A: 最快速响应——不等待下游节点。

问：这个在生产环境中安全吗？\ A: 不，为生产环境添加认证。

许可证

麻省理工学院（MIT）

作者

库尔特·安德森（@mapachekurt）

做出贡献

欢迎提交拉取请求！此工作流程应保持简洁，但对文档的改进总是备受欢迎。

支持

有问题吗？检查一下：

1. n8n 文档：https://docs.n8n.io
2. n8n 社区：https://community.n8n.io
3. 这个仓库的“Issues”标签页