很多兄弟在 N8N 大学咨询时，总问我同一个问题：“我把 n8n 跑起来了，能跑通了，但这就算完事了吗？”

笔者告诉你，这恰恰是危险的开始。

想象一下，你精心搭建的自动化城堡，大门敞开，密码是默认的，甚至还没装锁。这就是裸奔在公网上的 n8n 默认配置。一旦被扫描端口，你的工作流、敏感数据、甚至服务器权限都可能瞬间沦陷。

今天，笔者不讲虚的，直接上硬货。这是我部署 n8n 时雷打不动的安全清单，每一个都是从实战坑里爬出来的经验。看完这篇，你的 n8n 才算真正有了“护城河”。

第一道门：把默认密码扔进垃圾桶

这是最基础，也是最容易被新手忽略的一步。n8n 默认的用户名是 n8n@localhost，密码是随机生成的，通常在部署日志里能看到。

但很多人为了方便，直接用这个默认密码，或者干脆不设密码（在 Docker 里通过环境变量 N8N_BASIC_AUTH_ACTIVE=false 关闭认证）。这在公网环境下无异于裸奔。

笔者强烈建议： 进入 n8n 后台，第一时间去 用户设置 (User Settings) -> 个人资料 (Personal)，把默认密码改掉。设置一个包含大小写、数字和符号的强密码。

如果是在 Docker Compose 部署，建议直接在配置文件中通过环境变量固定你的管理员账号密码：

N8N_BASIC_AUTH_USER: admin@yourdomain.com
N8N_BASIC_AUTH_PASSWORD: Your_Strong_Password_Here

这样做，即便重装容器，你的权限也不会丢失，且避免了使用默认账号带来的安全隐患。

第二道门：强制 HTTPS，拒绝明文传输

如果你的 n8n 暴露在公网，HTTP 协议传输的数据是明文的。这意味着你工作流中流转的 Token、API Key、用户信息，都可能在传输过程中被中间人截获。

HTTPS 不仅是加密，更是现代应用的信任基石。在 n8n 中启用 HTTPS 有两种主流方式：

1. 通过 Nginx 反向代理（推荐）

这是最灵活、最专业的做法。在 Nginx 配置中配置 SSL 证书（可以使用 Let's Encrypt 免费获取），然后将 443 端口的流量转发到 n8n 的内部端口（如 5678）。

关键配置如下：

server {
    listen 443 ssl;
    server_name n8n.yourdomain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    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;
    }
}

2. 开启 n8n 自身的 HTTPS（适合单机测试）

如果你不想折腾 Nginx，n8n 也支持直接通过环境变量开启 HTTPS。你需要准备 key 和 cert 文件，并在 Docker Compose 中挂载：

N8N_PROTOCOL: https
N8N_SSL_KEY: /path/to/key.pem
N8N_SSL_CERT: /path/to/cert.pem

但要注意，这种方式在生产环境不如 Nginx 反向代理稳定，且不利于后续扩展其他服务。

第三道门：设置 IP 白名单（防火墙层）

即便有账号密码，我们依然希望只有特定的 IP 才能访问后台。这在企业内部使用时尤为重要。

如果你使用 Nginx 反向代理，可以通过 Nginx 的配置来限制 IP 访问。

在 Nginx 的 location / 块中添加以下规则：

location / {
    # 只允许公司内网 IP 和你的开发机 IP 访问
    allow 192.168.1.0/24;
    allow 123.45.67.89;
    deny all;

    proxy_pass http://localhost:5678;
    # ... 其他 proxy 设置
}

这样配置后，除了你指定的 IP 段，其他任何来源的请求都会直接被拒绝（返回 403 Forbidden）。这能有效防御暴力破解和未授权扫描。

第四道门：数据存储加密与备份

n8n 的所有数据（工作流、凭证、执行历史）默认存储在 SQLite 数据库中。如果你的服务器被入侵，数据库文件直接被拖走，数据就裸露了。

解决方案：

1. 文件系统加密：如果条件允许，对服务器的存储卷进行加密（如使用 LUKS 或 AWS EBS 加密）。这样即便硬盘丢失，数据也是密文。

2. 切换到 PostgreSQL 并加密连接：对于生产环境，强烈建议弃用 SQLite，改用 PostgreSQL。在 Docker Compose 中配置 PostgreSQL 时，确保数据库连接字符串使用 SSL 模式：

DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: n8n
...
# PostgreSQL 连接参数中加上 sslmode=require

3. 定期加密备份：不要只备份原始数据库文件。写个脚本，每天把数据库 dump 出来，用 GPG 加密后上传到 S3 或其他云存储。只有你手握解密私钥，这才是最安全的。

第五道门：凭证（Credentials）的最小权限原则

这是 n8n 安全配置中最容易被忽视的“软肋”。

很多兄弟在添加 API Key 时，习惯性给“读写所有权限”。一旦 n8n 被攻破，黑客能利用这些高权限 Key 做任何事。

笔者的硬核建议：

1. 按需授权：如果你的工作流只需要读取数据，就绝不要授予写入权限。例如，连接 MySQL 时，专门创建一个只读的数据库用户给 n8n 使用。

2. 使用环境变量管理敏感信息：虽然 n8n 有内置的凭证存储，但在 Docker 部署时，可以通过 env_file 引入环境变量。这样，敏感信息不会直接暴露在 n8n 的 UI 界面中，且更容易在不同环境间迁移。

3. 定期轮换 Key：养成习惯，每 3-6 个月更换一次 API Key。这虽然麻烦，但能极大降低长期泄露的风险。

避坑指南：那些年我踩过的坑

在配置安全的过程中，有两个坑笔者必须提醒大家：

坑 1：Webhook 滥用导致 DDoS

n8n 的 Webhook 节点默认是公开的。如果你的 Webhook URL 泄露，或者被恶意扫描，攻击者可以疯狂请求这个 URL，导致你的 n8n 崩溃，甚至产生巨额流量费。

解决办法： 在 Nginx 层面对 Webhook 路径进行限流（Rate Limiting）。例如，限制每个 IP 每秒只能请求 1 次：

limit_req_zone $binary_remote_addr zone=webhook:10m rate=1r/s;

location /webhook/ {
    limit_req zone=webhook burst=5 nodelay;
    proxy_pass http://localhost:5678/webhook/;
}

坑 2：忘记关闭“公开注册”

如果你的 n8n 开启了多用户模式（Multi-user），默认情况下，任何知道地址的人都可以注册账号。这非常危险。

在系统设置中，确保关闭 “允许用户注册” (Allow user registration)。只允许管理员创建用户，或者通过 SAML/SSO 集成企业认证。

FAQ 常见问题解答

Q1: 我只是在内网使用，也需要这么复杂的安全配置吗？
A: 相对宽松，但不能放松。至少要设置强密码。内网虽然相对安全，但不能排除内网横向渗透的风险（例如内网有其他被入侵的机器）。基础认证是底线。

Q2: Docker 部署时，端口映射 5678:5678 暴露在外网，怎么处理最安全？
A: 最安全的做法是只映射给 Nginx，即 127.0.0.1:5678:5678，不直接暴露公网 IP。然后通过 Nginx 代理并配置 SSL 和 IP 白名单。不要把 5678 端口直接扔到公网防火墙上。

Q3: 如果 n8n 坏了，我的数据会丢失吗？
A: 如果你使用的是 SQLite 且没有备份，是的。这也是为什么我强烈建议生产环境切换到 PostgreSQL 并配置定期备份的原因。n8n 只是工具，数据才是资产。

总结与资源

安全不是一次性的配置，而是一种持续的习惯。从修改默认密码开始，到配置 HTTPS、限制 IP、加密存储，再到管理凭证权限，这五道防线构成了 n8n 的纵深防御体系。

不要等到数据泄露了才后悔。现在就去检查你的 n8n 部署，把漏掉的配置补上。

如果你在配置过程中遇到具体报错，欢迎前往 N8N大学 (n8ndx.com) 搜索相关教程或留言，笔者会在社区第一时间回复。

保护好你的自动化城堡，让技术真正为你所用。