引言：你的 n8n 正在“裸奔”吗？

笔者在 N8N大学 社区里见过太多这样的场景：大家兴高采烈地在云服务器上跑起了 n8n，搭建了各种自动化工序，却忽略了最致命的环节——安全。

一旦你的 n8n 实例暴露在公网，且配置不当，这就相当于把你的数据库、API 密钥、客户数据直接挂在了互联网的十字路口。黑客通过简单的端口扫描和暴力破解，就能接管你的自动化流程。

这不是危言耸听。今天，作为你的技术学长，笔者将手把手带你从防火墙、网络层到应用层的凭证管理，为你的 n8n 云部署筑起一道坚固的防线。

第一步：网络层防御 —— 防火墙与端口管理

很多新手在部署 n8n 时，习惯性地开放所有端口，或者使用默认的 5678 端口且不做任何访问限制。这是非常危险的。

1. 精简入站规则

在你的云服务商（如 AWS、阿里云、腾讯云）控制台，或者服务器内部的防火墙（如 UFW、iptables）中，你只需要开放两个端口：

• 80 / 443：用于 Web 访问（如果你配置了反向代理）。
• SSH 端口：建议修改为非标准端口，且仅允许特定 IP 访问。

至于 n8n 默认的 5678 端口，**千万不要直接暴露在公网**。我们将在下一节通过反向代理将其隐藏。

2. 限制 SSH 访问（防爆破）

笔者见过太多服务器因为 SSH 弱口令被植入挖矿病毒。请务必修改 SSH 默认端口，并使用密钥登录而非密码。在 UFW 中，你可以这样配置（假设 SSH 端口改为 2222）：

sudo ufw allow from 123.45.67.89 to any port 2222
sudo ufw enable

这意味着只有你的固定 IP 才能连上服务器，极大降低了被扫描的概率。

第二步：隐藏入口 —— 反向代理配置

直接通过 IP:5678 访问 n8n 是不专业且不安全的。我们需要使用 Nginx 或 Caddy 作为反向代理，将 n8n 隐藏在标准的 80/443 端口之后，并强制 HTTPS。

配置 Nginx 代理

在 Nginx 配置文件中，我们需要设置代理头，确保 n8n 能正确识别客户端信息。最关键的是设置 WEBHOOK_URL，否则 Webhook 节点将无法工作。

注意： 以下配置假设你已将域名指向服务器 IP。

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://localhost:5678;
        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;
    }
}

配置完成后，使用 Certbot 申请免费的 SSL 证书，将 HTTP 重定向到 HTTPS。这样，你的 n8n 流量在传输过程中就是加密的，防止中间人攻击。

第三步：应用层加固 —— 环境变量配置

n8n 的安全性很大程度上取决于启动时的环境变量配置。如果你还在使用默认配置，那相当于大门没锁。

1. 强制用户认证

在 Docker 启动命令或 docker-compose.yml 中，必须设置 N8N_BASIC_AUTH_ACTIVE=true，并启用强用户名密码。

environment:
  - N8N_BASIC_AUTH_ACTIVE=true
  - N8N_BASIC_AUTH_USER=admin
  - N8N_BASIC_AUTH_PASSWORD=你的复杂密码

这将要求所有访问 n8n 的人必须先登录。如果没有这一步，任何知道你域名的人都能访问你的工作流。

2. Webhook 端点保护

n8n 的 Webhook 功能非常强大，但也最容易被滥用。如果你的 Webhook 是公开的，建议开启 N8N_RESTRICT_FILE_ACCESS=true，并限制 Webhook 的访问来源。

虽然 n8n 原生对 Webhook 的 IP 白名单支持有限，但我们可以通过 Nginx 层来控制：

location /webhook/ {
    allow 123.45.67.89; # 只允许特定 IP 访问 webhook
    deny all;
    proxy_pass http://localhost:5678/webhook/;
    # ... 其他 proxy 设置
}

第四步：凭证管理 —— 最后的防线

即便服务器被攻破，我们也需要确保数据库里的 API Key、密码是安全的。这就是凭证加密的作用。

加密密钥 (Encryption Key)

n8n 使用 AES-256 加密算法来加密数据库中的凭据。如果你不设置 N8N_ENCRYPTION_KEY，n8n 会使用一个随机生成的密钥。这意味着一旦容器重启或重装，所有保存的凭据都会失效（因为解密失败）。

实战指南：

• 生成一个强密钥（至少 32 位字符，包含大小写和符号）。
• 将其设置为环境变量：N8N_ENCRYPTION_KEY=your_super_secret_key

这样，即使黑客拖库了你的数据库，没有这个密钥，他们也无法还原你的 API 密钥。这是数据泄露的最后一道防线。

环境变量 vs 数据库存储

虽然 n8n 允许通过环境变量定义凭据（如 NODES_EXCLUDE），但对于大多数动态凭据（如 OAuth 令牌），建议存储在数据库中并依靠上述的加密密钥保护。切勿将明文密码直接写在 docker-compose 文件中并提交到 Git 仓库。

避坑指南：实战中的常见误区

在 N8N大学 的过往案例中，我们发现以下几个配置错误最常导致安全问题：

1. 忽略 n8n 的版本更新

n8n 官方会定期发布安全补丁。如果你使用的是 Docker 部署，千万不要使用 :latest 标签且从不更新。建议定期执行：

docker-compose pull
docker-compose up -d

或者使用 Watchtower 等工具自动更新，但需谨慎，避免新版本破坏现有工作流。

2. 数据库暴露在公网

如果你使用外部数据库（如 PostgreSQL），请确保数据库端口（默认 5432）**绝不能**对公网开放。n8n 的 Docker 容器应通过 Docker Network 与数据库连接，而不是通过公网 IP。

3. 调试模式 (Debug Mode)

在生产环境中，切勿开启 N8N_DEBUG=true。这会输出大量日志，其中可能包含敏感的请求头和参数信息，增加信息泄露的风险。

FAQ 常见问题解答

Q1: 我只在内网使用 n8n，还需要配置这些安全措施吗？

A: 即使是内网环境，也建议配置基础的认证和加密。内网并不意味着绝对安全，内部威胁（如离职员工）和横向移动攻击（如内网蠕虫）依然存在。基础的安全配置是专业运维的标准。

Q2: 如何备份加密后的凭证？

A: 凭证是加密存储在数据库中的。备份时，你只需要备份数据库文件（如 SQLite 的 .db 文件）或导出 PostgreSQL 数据。只要你在恢复数据时使用相同的 N8N_ENCRYPTION_KEY，凭据就能正常解密使用。

Q3: 设置了防火墙后，Webhook 无法接收外部请求怎么办？

A: 这通常是因为防火墙未放行端口，或者 Nginx 未正确转发 Header。检查 Nginx 配置中的 proxy_set_header 是否完整，并确认云服务商的安全组规则允许外部流量进入 443 端口。

总结与资源

安全不是一个一次性的动作，而是一个持续的过程。通过隐藏端口、强制 HTTPS、开启认证以及使用加密密钥，你的 n8n 实例已经比 90% 的部署更安全了。

在 N8N大学，我们始终相信：技术的价值在于创造，而安全是创造的基石。希望这篇指南能让你在自动化的路上走得更稳、更远。

更多 n8n 实战干货，欢迎访问 n8n大学官网。