使用Nginx反向代理、TLS和安全头保护n8n

2 分钟阅读·Matthieu·webhookssecuritylets-encryptreverse-proxynginxn8n|

将自托管的n8n实例部署在Nginx后方，配置Let's Encrypt TLS、安全头、速率限制、防火墙规则和webhook保护。每个步骤都包含验证命令。

本教程将你的自托管n8n实例部署在Nginx后方，配置TLS、安全头、速率限制和防火墙规则。你将从暴露在5678端口的n8n转变为生产就绪的配置，只有HTTPS流量能够访问编辑器和webhook。

前置条件：

  • 通过Docker Compose在VPS上运行的n8n（）
  • 一个域名（例如n8n.example.com），其A记录指向你的服务器IP
  • 以非root用户通过SSH访问服务器，且该用户具有sudo权限
  • 在托管商防火墙中开放80和443端口（Virtua Cloud默认已开放）

本指南基于Ubuntu 24.04 LTS。命令在Debian 12上也可使用，需做少量调整。全文使用n8n 2.x版本。

如何将Nginx配置为n8n的反向代理并支持WebSocket？

Nginx位于互联网和n8n之间，将请求转发到localhost:5678。n8n编辑器依赖WebSocket连接来实现实时更新。如果WebSocket代理配置不正确，编辑器界面会卡死并显示"Connection lost"。你需要配置proxy_pass到localhost:5678、用于WebSocket的HTTP/1.1升级头，以及N8N_PROXY_HOPS=1环境变量，让n8n从X-Forwarded-For中读取真实客户端IP。

安装Nginx

sudo apt update && sudo apt install -y nginx

验证Nginx是否正在运行：

sudo systemctl status nginx

你应该看到绿色的active (running)。如果没有，启动并启用它：

sudo systemctl enable --now nginx

enable --now标志做两件事：enable使Nginx在重启后自动启动，--now立即启动它。

创建Nginx server块

为你的n8n域名创建新的配置文件：

sudo nano /etc/nginx/sites-available/n8n.example.com

粘贴以下配置。将n8n.example.com替换为你的实际域名：

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name n8n.example.com;

    # Will be replaced by Certbot later
    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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;
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding off;
    }
}

顶部的map块处理WebSocket升级。当浏览器发送Upgrade: websocket头时，Nginx将其传递。对于普通HTTP请求，它发送close。这使n8n编辑器保持响应。

proxy_buffering off和proxy_cache off防止Nginx缓冲n8n的server-sent events，否则会导致编辑器延迟。

启用站点并测试配置：

sudo ln -s /etc/nginx/sites-available/n8n.example.com /etc/nginx/sites-enabled/
sudo nginx -t

你应该看到：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

如果测试通过，重新加载：

sudo systemctl reload nginx

验证n8n是否可以通过Nginx访问：

curl -s -o /dev/null -w "%{http_code}" http://n8n.example.com

200响应表示Nginx正在将流量转发到n8n。502表示n8n没有在5678端口运行，用docker ps检查。

更新n8n环境变量

打开n8n的.env文件（与docker-compose.yml在同一目录）：

nano ~/n8n-docker/.env

添加或更新以下变量：

N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PROXY_HOPS=1
WEBHOOK_URL=https://n8n.example.com/
N8N_EDITOR_BASE_URL=https://n8n.example.com/
N8N_SECURE_COOKIE=true

各变量的作用：

变量 值 用途
N8N_HOST 你的域名 告诉n8n在webhook URL中使用哪个主机名
N8N_PROTOCOL https n8n生成HTTPS webhook URL而非HTTP
N8N_PROXY_HOPS 1 n8n信任一层X-Forwarded-For来获取真实客户端IP
WEBHOOK_URL 完整URL 覆盖自动生成的webhook基础URL
N8N_EDITOR_BASE_URL 完整URL 用于邮件通知和SAML重定向的URL
N8N_SECURE_COOKIE true Cookie仅通过HTTPS发送。防止在纯HTTP上的会话劫持

重启n8n以应用更改：

cd ~/n8n-docker && docker compose down && docker compose up -d

验证n8n是否加载了新的环境变量：

docker compose logs --tail=20 n8n | grep -i "editor\|webhook\|proxy"

你应该看到引用你的域名和HTTPS协议的日志行。

如何为n8n反向代理添加Let's Encrypt TLS？

Certbot自动化Let's Encrypt证书的颁发，并自动配置Nginx的TLS。运行Certbot后，所有HTTP流量将重定向到HTTPS，n8n编辑器和webhook在传输过程中被加密。

安装Certbot

sudo apt install -y certbot python3-certbot-nginx

获取证书

sudo certbot --nginx -d n8n.example.com

Certbot将：

  1. 通过HTTP-01验证你拥有该域名
  2. 从Let's Encrypt获取证书
  3. 修改你的Nginx配置以添加TLS设置和HTTP到HTTPS的重定向

当提示输入电子邮件地址时，输入一个真实的地址。你会在那里收到续期失败的警告。

验证TLS是否工作

curl -I https://n8n.example.com

检查响应中的HTTP/2 200。如果看到证书错误，等待几分钟让DNS传播。

从本地机器（不是服务器）测试证书链：

openssl s_client -connect n8n.example.com:443 -servername n8n.example.com </dev/null 2>/dev/null | head -20

查找Verify return code: 0 (ok)。

验证自动续期

Certbot安装了一个systemd定时器，在证书过期前自动续期。确认它是活动的：

sudo systemctl status certbot.timer

你应该看到active (waiting)。在不实际续期的情况下测试续期流程：

sudo certbot renew --dry-run

dry run成功意味着你的证书将每60-90天自动续期。

n8n在生产环境中需要哪些安全头？

安全头告诉浏览器如何处理你网站的内容。没有这些安全头，你的n8n编辑器容易受到点击劫持（clickjacking）、MIME类型嗅探攻击和跨站脚本攻击。在Nginx配置中添加六个头来封堵这些漏洞。

打开Certbot修改过的Nginx配置：

sudo nano /etc/nginx/sites-available/n8n.example.com

在监听443端口的server块（Certbot创建的那个）中，在location /块上方添加这些头：

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' wss://n8n.example.com; frame-ancestors 'none'" always;

将CSP connect-src指令中的n8n.example.com替换为你的实际域名。wss://条目允许到编辑器的WebSocket连接。

各安全头的作用：

安全头 值 防范内容
Strict-Transport-Security 1年，含子域 浏览器始终使用HTTPS。阻止SSL剥离攻击
X-Frame-Options DENY 没有人可以将你的n8n编辑器嵌入iframe。阻止点击劫持
X-Content-Type-Options nosniff 浏览器信任声明的MIME类型。阻止MIME混淆攻击
Referrer-Policy strict-origin-when-cross-origin 限制泄露给外部站点的引用信息
Permissions-Policy 拒绝摄像头、麦克风、地理位置 浏览器阻止访问n8n不需要的硬件API
Content-Security-Policy 见上文 控制浏览器允许哪些脚本、样式和连接

CSP头是最复杂的。n8n编辑器在工作流构建器中使用内联脚本和eval()，因此script-src需要'unsafe-inline'和'unsafe-eval'。这是一个已知的权衡。其他指令是限制性的：只允许同源资源和到你域名的WebSocket连接。

测试并重新加载：

sudo nginx -t && sudo systemctl reload nginx

验证安全头是否存在：

curl -sI https://n8n.example.com | grep -iE "strict-transport|x-frame|x-content|referrer|permissions|content-security"

你应该在输出中看到所有六个头。如果缺少任何一个，检查配置文件中是否有拼写错误。

如何在VPS上为n8n配置防火墙？

UFW阻止所有流量，只允许你明确放行的。对于Nginx后方的n8n，只需要开放三个端口：22（SSH）、80（HTTP，用于Certbot续期和重定向）和443（HTTPS）。n8n直接监听的5678端口必须从外部封锁。许多指南跳过了这一步，导致n8n在没有TLS的情况下可被访问。

关于UFW的更深入介绍，请参阅。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP - Certbot renewal'
sudo ufw allow 443/tcp comment 'HTTPS - n8n via Nginx'
sudo ufw enable

提示确认时，输入y。验证规则：

sudo ufw status verbose

你应该看到端口22、80和443的三条ALLOW规则。没有其他规则。5678端口不在列表中，这意味着它被阻止了。

从本地机器确认n8n不能直接访问：

curl -s --connect-timeout 3 http://n8n.example.com:5678 || echo "Connection refused - correct!"

如果你得到"Connection refused"或超时，防火墙正在工作。如果你得到n8n的响应，Docker可能绕过了UFW。Docker直接修改iptables，可以覆盖UFW规则。

将n8n绑定到localhost并阻止Docker绕过UFW

最简单的解决方法是将n8n仅绑定到localhost。在你的docker-compose.yml中，修改端口映射：

    ports:
      - "127.0.0.1:5678:5678"

这确保n8n只接受来自同一台机器的连接。同一服务器上的Nginx可以访问它，但外部流量不行。

重启n8n：

cd ~/n8n-docker && docker compose down && docker compose up -d

如果仅此不够（从本地机器再次用curl测试），你还可以禁用Docker的iptables管理。编辑/etc/docker/daemon.json：

sudo nano /etc/docker/daemon.json

添加：

{
  "iptables": false
}

然后重启Docker：

sudo systemctl restart docker
cd ~/n8n-docker && docker compose up -d

**警告：**设置"iptables": false会阻止Docker创建NAT和转发规则。这可能会破坏容器间通信和容器的出站互联网访问。如果你的n8n工作流向外部API发送HTTP请求（大多数都会），请在此更改后测试出站连通性。仅绑定localhost通常就足够了。

从本地机器再次验证5678端口不可达。

如何在Nginx中对n8n的webhook端点进行速率限制？

速率限制保护你的webhook端点免受滥用和拒绝服务攻击。你为每个IP地址定义一个请求速率。合法的集成（GitHub、Stripe）以可预测的速率发送webhook。攻击者不断轰击你的webhook URL时会收到429 Too Many Requests响应，而不是触发工作流。

关于速率限制策略的更多信息，请参阅。

在Nginx配置文件的顶部添加limit_req_zone指令，放在任何server块之外，紧挨着现有的map指令：

limit_req_zone $binary_remote_addr zone=webhooks:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=editor:10m rate=30r/s;

这创建了两个区域：

  • webhooks：每IP每秒10个请求。处理外部服务的回调。
  • editor：每IP每秒30个请求。编辑器发出许多小的API调用，需要更高的限制。

在监听443的server块内，在主location /之前为webhook路径添加单独的location块：

    # Rate limit webhook endpoints
    location /webhook/ {
        limit_req zone=webhooks burst=20 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        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;

        # Generous timeout for long-running webhook workflows
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }

    location /webhook-test/ {
        limit_req zone=webhooks burst=5 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        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;
    }

burst=20参数允许短暂的峰值，最多20个请求后才触发速率限制。这处理了GitHub从一次push发送多个webhook事件等情况。nodelay立即处理突发请求，而不是排队。

在主location /块中，添加编辑器速率限制：

    location / {
        limit_req zone=editor burst=50 nodelay;
        limit_req_status 429;

        # ... existing proxy settings ...
    }

测试并重新加载：

sudo nginx -t && sudo systemctl reload nginx

通过向测试webhook发送一批请求来验证速率限制是否工作：

for i in $(seq 1 30); do
    curl -s -o /dev/null -w "%{http_code} " https://n8n.example.com/webhook/test-rate-limit
done
echo

你应该看到404响应（webhook路径不存在，这是正常的）和429响应的混合，后者在速率限制生效时出现。

如何将n8n编辑器限制为特定IP地址？

默认情况下，任何知道你的n8n URL的人都可以访问登录页面。在Nginx层面的IP白名单在n8n自身认证之前增加了一道防线。只有来自你的IP地址（或你的VPN）的请求才能到达编辑器。Webhook端点保持对互联网开放，以便外部服务可以调用它们。

为编辑器路径添加新的location块。将其放在webhook位置之后、主location /之前：

    # Restrict editor/API access to specific IPs
    location /rest/ {
        allow 203.0.113.50;   # Your office/home IP
        allow 10.0.0.0/8;     # Your VPN range
        deny all;

        limit_req zone=editor burst=50 nodelay;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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;
        proxy_buffering off;
    }

将203.0.113.50替换为你的实际IP。用以下命令查找：

curl -4 ifconfig.me

/rest/路径处理n8n编辑器的API调用。主location /仍然提供编辑器前端和webhook服务。要实现更严格的锁定，你也可以限制根路径，并仅为/webhook/和/webhook-test/添加单独的开放位置。

测试并重新加载：

sudo nginx -t && sudo systemctl reload nginx

从你的允许IP验证：

curl -s -o /dev/null -w "%{http_code}" https://n8n.example.com/rest/settings

200表示你被允许访问。从不同的IP（使用不在你Wi-Fi上的手机），在浏览器中访问https://n8n.example.com/rest/settings。你应该收到403 Forbidden。

如何保护n8n webhook免受未授权访问？

Webhook URL默认是公开的。任何发现或猜到URL的人都可以触发你的工作流。两种策略可以防范：保持webhook路径不可预测，以及在工作流内验证HMAC签名。

使用带有唯一ID的生产webhook

n8n为每个Webhook节点生成两个webhook路径：

  • 测试URL：/webhook-test/<id>（仅在编辑器打开时激活）
  • 生产URL：/webhook/<id>（在工作流激活时激活）

<id>默认是UUID。不要将其改为可猜测的内容，如/webhook/github或/webhook/stripe。随机UUID是你的第一道防线。

在工作流中验证HMAC签名

GitHub和Stripe等服务用共享密钥对其webhook负载进行签名。你的n8n工作流应在处理数据之前验证此签名。

对于GitHub webhook，在Webhook节点后添加一个IF节点，条件如下：

  1. 在GitHub仓库设置中，设置一个webhook密钥（用openssl rand -base64 32生成）
  2. 在n8n工作流中，在Webhook节点后添加一个Code节点：
const crypto = require('crypto');
const secret = $env.GITHUB_WEBHOOK_SECRET;
const signature = $input.first().headers['x-hub-signature-256'];
const body = JSON.stringify($input.first().json);
const expected = 'sha256=' + crypto.createHmac('sha256', secret).update(body).digest('hex');

if (signature !== expected) {
  throw new Error('Invalid webhook signature');
}

return $input.all();
  1. 将密钥存储在n8n的环境中，不要硬编码在工作流里。将其添加到.env文件：
GITHUB_WEBHOOK_SECRET=your-generated-secret-here

并在docker-compose.yml中将其暴露给n8n：

    environment:
      - GITHUB_WEBHOOK_SECRET=${GITHUB_WEBHOOK_SECRET}

对于Stripe webhook，模式类似但使用不同的头（stripe-signature）和时序安全比较。查看Stripe的webhook签名文档了解当前的签名方案。

隐藏n8n版本信息

默认情况下，n8n在API响应中包含版本信息。禁用版本信息披露以增加侦察难度：

在.env文件中：

N8N_VERSION_NOTIFICATIONS_ENABLED=false

在Nginx配置中，在server块内添加：

    server_tokens off;

版本信息披露帮助攻击者针对特定n8n版本中的已知漏洞发起攻击。隐藏它迫使攻击者盲目探测。

如何调整n8n的超时和上传限制？

一些n8n工作流运行数分钟，处理大型数据集或等待外部API。Nginx默认的60秒超时会终止这些请求。如果负载超过Nginx默认的1 MB body限制，文件上传工作流会失败。

在HTTPS服务器的主location /块中，添加或更新：

    # Timeout tuning for long-running workflows
    proxy_connect_timeout 60s;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;

    # Allow file uploads up to 50 MB
    client_max_body_size 50m;

proxy_read_timeout 300s给工作流最多5分钟来响应。根据你最长工作流的执行时间来调整。webhook的location块已经有了速率限制部分的超时设置。

client_max_body_size 50m允许通过webhook和编辑器端点上传最大50 MB的文件。处理CSV导入、图片上传或文档转换的n8n工作流需要此设置。

测试并重新加载：

sudo nginx -t && sudo systemctl reload nginx

完整Nginx配置参考

所有更改完成后的完整配置。将其与你的文件对比：

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

limit_req_zone $binary_remote_addr zone=webhooks:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=editor:10m rate=30r/s;

server {
    listen 80;
    listen [::]:80;
    server_name n8n.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name n8n.example.com;

    ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    server_tokens off;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' wss://n8n.example.com; frame-ancestors 'none'" always;

    client_max_body_size 50m;

    # Rate limit webhook endpoints
    location /webhook/ {
        limit_req zone=webhooks burst=20 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        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;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }

    location /webhook-test/ {
        limit_req zone=webhooks burst=5 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        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;
    }

    # Restrict editor API to specific IPs
    location /rest/ {
        allow 203.0.113.50;
        allow 10.0.0.0/8;
        deny all;

        limit_req zone=editor burst=50 nodelay;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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;
        proxy_buffering off;
    }

    # Main location - editor frontend and fallback
    location / {
        limit_req zone=editor burst=50 nodelay;
        limit_req_status 429;

        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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;
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding off;
        proxy_connect_timeout 60s;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

如何验证n8n编辑器中的WebSocket连接是否正常？

n8n编辑器使用/rest/push上的WebSocket连接接收实时工作流执行更新。如果此连接失败，你会看到"Connection lost"横幅，编辑器在工作流运行后不会更新。

在浏览器中打开n8n编辑器。打开浏览器开发者工具（F12），转到Network选项卡，按"WS"（WebSocket）过滤。你应该看到一个到wss://n8n.example.com/rest/push的连接，状态为101（Switching Protocols）。

从命令行测试WebSocket升级：

curl -sI -H "Upgrade: websocket" -H "Connection: Upgrade" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" -H "Sec-WebSocket-Version: 13" https://n8n.example.com/rest/push

101 Switching Protocols响应确认WebSocket代理正在工作。200或400意味着升级头没有到达n8n。回去检查map指令和Upgrade/Connection代理头。

出了问题？

n8n编辑器显示"Connection lost"

WebSocket代理出了问题。检查：

  1. map $http_upgrade $connection_upgrade块是否存在于配置顶部
  2. proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection $connection_upgrade是否在location /块中
  3. 是否设置了proxy_http_version 1.1（WebSocket需要HTTP/1.1）

检查Nginx日志：

sudo journalctl -u nginx -f

重启后出现"502 Bad Gateway"

n8n容器未运行或未在5678端口监听：

docker ps | grep n8n
docker compose logs --tail=50 n8n

Certbot续期失败

检查定时器是否在运行并手动测试：

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

如果续期失败，确保UFW中80端口是开放的，且HTTP server块仍然存在（Certbot需要它来完成HTTP-01验证）。

从允许的IP收到"403 Forbidden"

你的IP可能已经改变。用curl -4 ifconfig.me检查当前IP，并更新Nginx配置中的allow指令。

速率限制过于激进

如果合法的webhook发送方收到429错误，增加limit_req_zone和limit_req指令中的rate和burst值。先监控传入请求的速率：

sudo tail -f /var/log/nginx/access.log | grep webhook

下一步

  • 为n8n实例设置自动备份和更新（）
  • 了解更多Nginx反向代理模式（）
  • 深入探索TLS配置（）
  • 返回工作流自动化概览（自托管工作流自动化）

版权所有 2026 Virtua.Cloud。保留所有权利。 本内容为 Virtua.Cloud 团队原创作品。 未经书面许可，禁止复制、转载或再分发。

准备好亲自尝试了吗？

几秒内部署您自己的服务器。支持 Linux、Windows 或 FreeBSD。

查看 VPS 方案
用Nginx反向代理和TLS保护n8n（2026）