场景导入：你的 n8n 可能正在“裸奔”
很多新手在部署完 n8n 后，往往只关注如何连接 API、构建工作流，却忽略了一个致命问题：安全性。笔者见过太多案例，用户在公网直接暴露 n8n 的默认端口（5678），且从未修改过默认凭据。
这无异于将公司的数据大门敞开。一旦被恶意扫描到，攻击者不仅能够窃取你的 API Key、数据库密码，甚至能通过 n8n 的执行命令节点控制你的服务器。作为 N8N大学 的首席主编，我必须提醒你：在自动化之前，先筑好安全防线。
准备工作：安全配置的硬性条件
在开始之前，请确保你已经具备以下条件：
- 服务器权限：拥有 n8n 部署环境的终端访问权限（SSH）。
- 反向代理工具：推荐使用 Nginx 或 Caddy（本文以 Nginx 为例）。
- 域名与 SSL 证书：一个已解析到服务器的域名，以及对应的 HTTPS 证书（Let's Encrypt 免费证书即可）。
核心实操：从访问控制到数据加密
我们将分三个层级进行加固：网络访问层、应用层认证、以及数据传输层。
第一步：强制 HTTPS 与反向代理配置
永远不要在公网使用 HTTP 协议传输 n8n 流量。n8n 的默认配置并不直接支持 HTTPS，因此我们需要通过 Nginx 进行反向代理。
在 Nginx 配置文件中（通常位于 /etc/nginx/conf.d/n8n.conf），你需要配置 80 端口跳转到 443，并配置 SSL 证书路径。关键在于设置 proxy_pass 指向本地的 n8n 端口。
注意：n8n 默认监听 5678 端口。请确保你的反向代理配置中包含 Host 头部的重写，否则 n8n 可能会报错 404。
server {
listen 443 ssl;
server_name your-domain.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# 关键：指向 n8n 的 5678 端口
proxy_pass http://localhost:5678;
}
}
第二步：配置 Basic Auth（基础认证）
虽然 n8n 自带登录系统，但在进入 n8n 面板之前，再加一层 Nginx 的 Basic Auth，可以有效防止暴力破解扫描。这相当于在大门外再加一道栅栏。
首先，生成密码文件（推荐使用 OpenSSL 工具，避免明文存储）：
echo "admin:$(openssl passwd -crypt 你的强密码)" >> /etc/nginx/.htpasswd
然后在 Nginx 的 location 块中加入以下指令：
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
重启 Nginx 后，访问你的域名时，浏览器会先弹窗要求输入用户名和密码。这一步能过滤掉绝大多数自动化扫描脚本。
第三步：环境变量加密与凭据管理
n8n 的核心安全隐患往往在于工作流中硬编码的 API Key 或数据库密码。N8N大学 强烈建议使用 n8n 的“凭据（Credentials）”功能，并结合环境变量进行加密。
在 Docker 或 PM2 启动 n8n 时，不要将密码直接写在启动命令中，而是通过 .env 文件引用，并设置加密密钥。
关键参数设置：
- N8N_ENCRYPTION_KEY：这是 n8n 用于加密数据库中凭据的密钥。如果丢失此密钥，所有已保存的凭据将无法解密。
- EXECUTIONS_PROCESS：建议设置为
main（默认），如果涉及高并发或敏感数据处理，需注意隔离策略。
在 Docker Compose 中的配置示例：
environment:
- N8N_ENCRYPTION_KEY=my_super_secret_key_change_this_2024
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=your_secure_password
完成配置后，即便有人拿到了你的数据库备份，没有 N8N_ENCRYPTION_KEY，他们也无法还原你的 API 密钥。
避坑指南：实战中容易忽略的细节
在为数百个用户进行 n8n 安全审计时，笔者发现以下两个错误最为常见：
- Webhook 暴露风险：n8n 的 Webhook 节点通常生成一个包含随机 ID 的 URL。如果你的 n8n 在公网开放，Webhook URL 就是公开的。攻击者可以向此 URL 发送垃圾数据，消耗你的服务器资源。建议在 Nginx 中对
/webhook路径添加 IP 白名单限制，或在 n8n 中开启 Webhook 的“仅接受特定来源”校验（如果版本支持）。 - 数据库未加密：默认情况下，n8n 使用 SQLite。如果你将 SQLite 文件放在 Web 可访问目录（如
/var/www/html下），任何人都可以直接下载该文件。请确保数据库文件位于非 Web 根目录，且权限设置为仅 n8n 进程可读写。
FAQ 问答
Q1: 我只在内网使用 n8n，还需要配置 HTTPS 吗？
A: 即使在内网，也建议配置 HTTPS。局域网内的嗅探攻击并不罕见，且现代浏览器（如 Chrome）对非 HTTPS 的 HTTP 网站限制越来越多。使用自签名证书即可满足内网安全需求。
Q2: n8n 的版本更新会不会影响我的安全配置？
A: 会的。尤其是涉及环境变量变更的版本（如 1.0+ 版本对凭据系统的改进）。在升级前，务必在测试环境中验证你的 Docker Compose 配置或环境变量是否依然有效。N8N大学 建议订阅我们的更新日志以获取最新资讯。
Q3: 如果忘记了 N8N_ENCRYPTION_KEY 怎么办？
A: 非常遗憾，这个密钥是无法找回的。如果丢失，你将无法解密数据库中存储的所有凭据（API Key、密码等），只能重新手动配置所有连接。因此，请务必将此密钥保存在安全的密码管理器中。
总结与资源
n8n 的安全配置并非一劳永逸，而是一个持续的过程。从网络层的反向代理与 HTTPS，到应用层的双重认证，再到数据层的环境变量加密，每一层都至关重要。作为 N8N大学 的学员，掌握这些进阶实战技巧，才能在享受自动化便利的同时，确保数据资产的安全。
如果你想了解更多关于 n8n 的硬核教程，欢迎访问 N8N大学 (n8ndx.com)，这里有更多实战案例等待你的探索。
