内容来源：https://blog.n8n.io/n8n-tunnel-service-discontinued/

内容总结：

n8n宣布正式停用其内置的隧道服务及相关的--tunnel选项。该服务原为方便本地开发而设，可用于将本地运行的n8n实例临时暴露至公网，以接收来自GitHub、Stripe、Slack等第三方服务的Webhook。然而，由于该服务长期存在运维稳定性与安全隐患，且已在n8n v2版本中被移除，仅作为v1版本的遗留功能提供支持。随着维护成本持续增加，团队决定全面终止此项服务。

对于依赖此功能进行本地Webhook测试的用户，n8n建议转向专业的第三方隧道服务，例如Cloudflare Tunnel（提供无需账户的快速隧道）、ngrok（含免费层级）或开源方案localtunnel。这些服务均能将公网流量安全转发至本地端口，满足开发测试需求。

n8n同时提醒，无论采用何种隧道方案，都应视本地Webhook终端为生产环境入口，采取验证签名、使用密钥、最小化暴露时间等安全措施，以保障开发过程的安全性。

中文翻译：

我们将停止提供 n8n 隧道服务及相关 --tunnel 选项。本文旨在说明此次调整的原因、对您的影响，以及如何为本地 Webhook 开发配置安全的替代方案。

内容提要

• n8n 隧道服务已停用并将正式终止。
• 若需本地 Webhook 测试的公开 URL，请使用第三方隧道服务（如 Cloudflare Tunnel 或 ngrok）。
• 无论采用何种隧道服务，请将本地 Webhook 端点视同生产环境入口：验证签名、使用密钥并尽量缩短暴露时间。

关于 n8n 隧道服务
n8n 隧道服务曾为本地运行的 n8n 实例提供便捷的互联网公开访问方案，主要用于开发期间接收第三方服务（如 GitHub、Stripe、Slack 等）发送的 Webhook。

终止服务的原因
该服务最初为便利本地开发而推出。由于频繁出现运维问题及安全隐患，我们已在 n8n v2 版本中移除此功能，仅作为遗留方案兼容 n8n v1。随着时间推移，若要保持我们期望的可靠性标准，后续运维维护成本将持续攀升。
基于上述运维考量，我们决定终止该服务。未来建议使用专业的第三方隧道服务进行本地 Webhook 开发。

您需要关注的变化

• 若您曾依赖 n8n 隧道服务，需切换至替代方案。
• 在 v1 版本中使用 --tunnel 参数启动时将提示超时错误，后续补丁更新会加入更明确的说明。
• 稳定版与测试版渠道不受影响。

本地 Webhook 测试推荐方案
要为本地运行的 n8n 实例接收 Webhook，需通过隧道服务将本地实例暴露至公网。以下为部分可选方案：

• Cloudflare Tunnel —— 免费方案支持快速隧道，无需注册账户
• ngrok —— 提供免费层级，需注册账户
• localtunnel —— 开源替代方案
  这些服务均可将公网流量转发至本地 n8n 端口，便于开发期间接收第三方 Webhook。具体配置请参阅各服务商的官方文档。

n8n 内部开发工具基于 cloudflared 实现，相关细节请查阅文档。请注意此为内部开发工具，可能随时调整。

重要提示：无论选用何种隧道服务，请始终将本地 Webhook 端点视作生产环境入口——严格验证签名、使用密钥保护，并尽可能缩短服务暴露时间。

英文来源：

We are discontinuing the n8n Tunnel Service and the related --tunnel option. This post explains why, what changes for you, and how to set up secure alternatives for local webhook development.
TL;DR

• The n8n Tunnel Service has been disabled and is being discontinued.
• If you need a public URL for local webhook testing, use a third-party tunneling service such as Cloudflare Tunnel or ngrok.
• Regardless of the tunnel provider, treat your local webhook endpoint like a production entry point: verify signatures, use secrets, and minimize exposure.
  What was the n8n Tunnel Service?
  The n8n Tunnel Service provided a simple way to expose a locally running n8n instance to the public internet for development and testing. This was commonly used to receive webhooks from third-party services (for example GitHub, Stripe, Slack, and many others) when developing workflows locally.
  Why we are discontinuing it
  The n8n Tunnel Service was originally introduced as a convenience for local development. As a source of operational frequent issues and security concerns it has already been removed in n8n v2, and the service effectively remained as legacy support for n8n v1. Over time it has become increasingly difficult to operate and maintain at the level of reliability we want to provide without further investment.
  For these operational reasons, we can no longer support the service. Going forward, we recommend using a dedicated third-party tunneling provider for local webhook development.
  What changes for you
• If you previously relied on the n8n tunnel, you will need to switch to an alternative.
• The
  --tunnel
  option will timeout with an error when starting v1 with the flag. We will add a more informative notice in an upcoming patch update for v1. - For stable and beta release channels, nothing changes.
  Recommended alternatives for local webhook testing
  To receive webhooks on a locally running n8n instance, you need a tunneling service that exposes your local instance to the public internet. There are several free and paid options available:
• Cloudflare Tunnel — free, no account required for quick tunnels
• ngrok — free tier available, requires sign-up
• localtunnel — open-source alternative
  Each of these services can forward public traffic to your local n8n port, allowing third-party services to deliver webhooks during development. Refer to the respective provider's documentation for setup instructions specific to your environment.
  n8n provides development tooling used internally based on cloudflared
  . Refer to the documentation for details. Note that this might change at any time as it’s development tooling.
  Regardless of which tunneling provider you use, treat your local webhook endpoint like a production entry point: verify signatures, use secrets, and minimize exposure time.