大家好，我是 N8N大学 的主编。最近在社区里看到不少朋友分享自己搭建的 n8n 实例，跑得飞快，功能也很强大。

但说实话，我有点替大家捏把汗。因为很多人在部署完 n8n 之后，直接把 http://localhost:5678 或者公网 IP 一挂，就开始跑业务了，却忽略了最关键的一步——安全配置。

这就像你买了一辆法拉利，却忘了锁车门。n8n 处理的数据往往涉及 API Key、数据库密码、用户隐私信息，一旦配置不当，后果不堪设想。

今天，笔者就来给大家扒一扒 n8n 安全配置中，最容易被忽略的 5 个关键设置。这些设置不一定是最复杂的，但往往是最容易被遗忘的“隐形漏洞”。

1. 访问控制：告别“裸奔”的公网暴露

很多新手为了图省事，安装 n8n 时直接使用默认配置。这意味着只要有人知道你的 IP 地址，就能直接访问你的 n8n 面板。

笔者见过最离谱的案例是，有人把 n8n 的 5678 端口直接映射到公网，没有任何密码保护。这等于把自家保险箱的密码贴在了大门上。

怎么解决？

如果你必须公网访问，必须开启基础的认证机制。在 n8n 的环境变量中，你需要配置 N8N_BASIC_AUTH_ACTIVE 为 true，并设置用户名和密码。

1. 找到你的 n8n 启动配置文件（如果是 Docker，就是 docker-compose.yml）。
2. 添加以下环境变量：

N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=你的用户名
N8N_BASIC_AUTH_PASSWORD=你的强密码

设置完后，重启 n8n。现在，任何访问你 IP 的人都会先看到一个登录弹窗。这是最基础的防线，也是最容易被忽略的。

2. 端口与协议：别把 HTTP 当 HTTPS 用

在本地开发时，使用 HTTP 协议是没问题的。但一旦涉及公网访问，HTTP 协议就是裸奔。你在 n8n 面板中输入的任何 Token、密码，都会以明文形式在网络上传输，极易被中间人劫持。

很多 n8n 用户虽然做了反向代理（比如 Nginx），但配置错了 n8n 的内部协议，导致 n8n 以为自己还在跑 HTTP，从而生成错误的重定向链接。

关键设置：

当你通过 Nginx 等反向代理配置了 SSL 证书（HTTPS）后，务必在 n8n 的环境变量中告诉它：

WEBHOOK_URL=https://你的域名/webhook
GENERIC_TIMEZONE=Asia/Shanghai

特别是 WEBHOOK_URL，如果你不显式指定，n8n 生成的 Webhook 地址可能依然是 http 开头，这会导致很多外部服务（如微信回调、Stripe Webhook）拒绝请求。

3. 数据加密：给你的 Workflow 上把锁

n8n 默认会将工作流数据（Workflow Data）存储在 SQLite 或 PostgreSQL 中。虽然数据库本身是文件存储，但敏感字段（如 API Key）在数据库中是否加密，决定了你的数据泄露后损失有多大。

默认情况下，n8n 会加密部分凭据，但如果你在安装时没有配置加密密钥（Encryption Key），那么每次重启 n8n 后，这个密钥可能会重置，导致之前保存的凭据无法解密，甚至在极端情况下，数据以明文存储。

避坑指南：

在部署时，务必手动设置一个固定的加密密钥。

N8N_ENCRYPTION_KEY=这里填一个长且随机的字符串

你可以随便找个在线密码生成器生成一串字符。有了这个密钥，即使你的数据库文件被盗，黑客没有这个密钥也无法解密其中的凭据信息。

4. Webhook 保护：防止恶意刷接口

n8n 的 Webhook 节点非常强大，它允许外部系统触发你的工作流。但这也意味着，如果你的 Webhook 地址泄露，任何人都可以无限次触发你的工作流。

这不仅涉及安全问题，还可能导致你的业务逻辑被恶意利用，甚至产生大量的 API 调用费用（比如触发了 HTTP Request 节点调用付费 API）。

如何加固？

n8n 允许你为 Webhook 设置一个路径前缀（Path Prefix）。默认是 /webhook，但这太容易被猜到了。

在环境变量中修改：

WEBHOOK_PREFIX=/w/

或者更复杂一点，比如 /webhook/v1/secret/。虽然这不能完全替代认证，但增加了猜测的难度。

进阶做法： 在 Webhook 节点前加一个“IF”节点，校验请求中的特定 Header 或 Query 参数（比如一个只有你知道的 Token）。虽然这需要在工作流里手动配置，但安全性大大提升。

5. 日志与调试：别把敏感信息暴露在日志里

调试 n8n 工作流时，我们习惯查看 Execution Log（执行日志）来排错。但是，n8n 默认会记录请求和响应的详细内容。

想象一下，你正在调试一个登录接口，请求体里包含用户名和密码。如果你开启了“详细日志”或者在调试节点中打印了整个 JSON 对象，这些敏感信息就会永久记录在 n8n 的日志文件中。

关键设置：

在生产环境中，建议调整日志级别，避免记录过多敏感数据。

如果你使用的是 Docker 部署，可以在环境变量中设置：

N8N_LOG_LEVEL=warn

默认通常是 info，将其调整为 warn 或 error，可以减少日志体积，同时避免敏感数据无意间被记录。

另外，切记在分享工作流截图或导出 JSON 给他人时，使用 @n8n/n8n-nodes-base 的“凭据”功能，不要直接把 API Key 写在节点参数里，否则导出的 JSON 文件中会直接包含明文 Key。

FAQ 常见问题解答

Q1: 我用了 Nginx 反向代理，还需要配置 n8n 的 HTTPS 吗？
A: 不需要配置 n8n 内部运行 HTTPS，但你必须在 Nginx 中配置 SSL，并且在 n8n 环境变量中设置 WEBHOOK_URL 为 https 开头的地址。Nginx 负责对外提供 HTTPS，n8n 内部保持 HTTP 通信即可。

Q2: 我的 n8n 只在内网使用，还需要这些安全配置吗？
A: 需要！内网并不等于绝对安全。如果内网中有其他不可信的设备或人员，或者你的内网被渗透，缺乏保护的 n8n 依然是个巨大的漏洞。基础的认证和加密密钥配置是必须的。

Q3: 忘记了加密密钥怎么办？
A: 很遗憾，如果丢失了加密密钥，之前加密存储的凭据将无法解密，你必须重新在工作流中配置所有 API 连接。所以，请务必安全保管你的密钥。

总结与资源

安全从来不是一劳永逸的，而是一个持续的过程。对于 n8n 用户来说，开启基础认证、配置 HTTPS、设置加密密钥 是最核心的“保命三件套”。

不要等到数据泄露或服务器被入侵才开始后悔。花 10 分钟检查一下这 5 个设置，能帮你规避掉 90% 的常见风险。

如果你在配置过程中遇到任何报错，欢迎访问 N8N大学 查阅更多实战教程，或者在社区留言，笔者会第一时间为大家解答。

我是 N8N大学 的主编，致力于让自动化更安全、更高效。下期见。