Callback verification failed (Error 429) while saving workflows with whatsapp trigger behind Nginx

emiliano2025 · February 12, 2026, 8:28pm

I am experiencing a persistent HTTP 429 (Too Many Requests) error combined with a curl_errno = 56 whenever I try to manually save a workflow. This happens consistently on a self-hosted instance. After analyzing my Nginx logs, I noticed bursts of telemetry data and external webhook hits (Facebook) that seem to be saturating the connection or triggering a rate limit, preventing the editor from saving the workflow JSON.

What is the error message (if any)?

(#2200) Callback verification failed with the following errors: curl_errno = 56; curl_error = CONNECT tunnel failed, response 429; HTTP Status Code = 429; HTTP Message = Too Many Requests

Share the output returned by the last node

The nodes execute correctly, but the UI fails to persist the changes to the database due to the 429 error during the POST request to the internal API.

Information on your n8n setup

n8n version: 1.121.3 (Docker image)
Database: SQLite (default)
n8n EXECUTIONS_PROCESS setting: default
Running n8n via: Docker Compose (behind Nginx Reverse Proxy)
Operating system: Ubuntu / Debian (GCP Virtual Machine)

Additional Context

I have already tried:

Disabling telemetry (N8N_DIAGNOSTICS_ENABLED=false).
Increasing Node.js memory (NODE_OPTIONS=--max-old-space-size=2048).
Setting N8N_LOG_LEVEL=info.
Checking Google Cloud Firewall (Port 5678, 80, 443 are open).

The issue persists, suggesting a possible bottleneck in the proxy-to-container communication or a strict rate-limiting policy in the underlying infrastructure when handling large JSON payloads.

emiliano2025 · February 12, 2026, 9:02pm

I would like to add that some WhatsApp messages from Meta are not reaching my webhook. They don’t even appear in the scenario execution logs.

Anshul_Namdev · February 12, 2026, 10:07pm

Hi @emiliano2025 Welcome!
Please consider updating your docker instance as it is currently a lot behind from the latest stable version, just update the docker image and things would work just fine:

emiliano2025 · February 13, 2026, 3:33am

Hi,

Following your suggestion, I have successfully updated my Docker instance to the latest stable version of n8n. However, the issue remains unresolved.

Specifically:

Activation Issues: When I try to publish the workflow, I consistently get the error: ‘Callback verification failed… HTTP Status Code = 429; Too Many Requests’.
Inconsistent Behavior: To get the workflow to actually publish, I have to refresh the page and click the ‘Publish’ button multiple times. It only works after several attempts.
Missing Logs: Even when the workflow is finally ‘Active’, many WhatsApp messages from Meta still don’t reach my webhook and do not appear in the execution logs at all.

Thank you.

A_A4 · February 13, 2026, 8:35am

Hello @emiliano2025 ,

The error CONNECT tunnel failed coupled with HTTP 429 confirms your instance is still trying to use the n8n Development Tunnel instead of your own Nginx domain.

To fix this immediately,
you must remove N8N_TUNNEL_SUBDOMAIN (and --tunnel) from your configuration and ensure WEBHOOK_URL is set to your actual domain (e.g., https://n8n.your-domain.com/);
this bypasses the rate-limited tunnel and routes traffic directly through Nginx.

Furthermore, since you are using the default SQLite database on a GCP VM, the dropped WhatsApp messages are likely due to SQLite “locking” during high traffic or saves, so you should migrate to PostgreSQL to handle concurrent requests without freezing.

Gunter_Berger · February 13, 2026, 11:23am

I am experiencing the exact same issue with Whatsapp Webhook Node. Did you ever find a solution to your problem?

gibacache · February 13, 2026, 12:03pm

I am also experiencing the same issue:

Some whatsapp messages not triggering the workflow.
Error when publishing the workflow that contains the whastapp trigger node. Error message:

(#2200) Callback verification failed with the following errors: curl_errno = 56; curl_error = CONNECT tunnel failed, response 429; HTTP Status Code = 429; HTTP Message = Too Many Requests

Environment / deployment

n8n version: 2.7.4 (Community)
Docker image: docker.n8n.io/n8nio/n8n:2.7.4 (Alpine)
Deployment: Docker Compose behind Traefik on a Hostinger VPS
Database: Default SQLite (/home/node/.n8n volume)

Gunter_Berger · February 13, 2026, 2:47pm

We have exactly the same issue. It’s a real nightmare. It’s kept me busy for 3 days and still no answer. I am praying someone has a solution to this:

Some whatsapp messages not triggering the workflow.
Error when publishing the workflow that contains the whastapp trigger node. Error message:

(#2200) Callback verification failed with the following errors: curl_errno = 56; curl_error = CONNECT tunnel failed, response 429; HTTP Status Code = 429; HTTP Message = Too Many Requests

Environment / Deployment

n8n version: 2.7.4 (Community)
Docker image: docker.n8n.io/n8nio/n8n:latest (Alpine)
Deployment: Docker Compose behind Traefik on a Hostinger VPS
Docker version: 28.5.1, build e180ab8
Database: Default SQLite (/home/node/.n8n volume)

emiliano2025 · February 13, 2026, 7:50pm

Update – Issue Resolved

It seems the issue has been resolved.

I upgraded n8n to the latest stable version and migrated the database from SQLite to PostgreSQL to better handle concurrent executions and improve overall stability.

Originally, I was running n8n with the default SQLite database in Docker. Under heavier load and concurrent workflow executions, things started behaving inconsistently.

Here’s exactly what I did:

Exported all workflows:

n8n export:workflow --all --output=workflows.json

Exported all credentials:

n8n export:credentials --all --output=credentials.json

Identified and preserved the existing encryption key from:
```
/home/node/.n8n/config
```
(This is critical. Without using the same N8N_ENCRYPTION_KEY, credentials will not decrypt properly after migration.)
Created a dedicated PostgreSQL container.
Updated docker-compose.yml to use:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST
- DB_POSTGRESDB_DATABASE
- DB_POSTGRESDB_USER
- DB_POSTGRESDB_PASSWORD
- N8N_ENCRYPTION_KEY=<original_key>

Restarted the stack and imported everything back:

n8n import:workflow --input=workflows.json
n8n import:credentials --input=credentials.json

After that, everything worked correctly.

However, I’m still monitoring the WhatsApp webhook behavior to confirm whether that specific problem is fully resolved. I’d prefer to observe it under normal load for some time before drawing conclusions.

Moving from SQLite to PostgreSQL made a noticeable difference in stability, especially when handling concurrent executions and heavier workloads.

If you’re experiencing strange behavior under load, I strongly recommend migrating to PostgreSQL instead of staying on SQLite in production.

Thanks again to everyone for the guidance.

Orionpax · February 14, 2026, 5:10am

This is a tricky issue @emiliano2025 the HTTP 429 error when saving workflows, combined with the Facebook webhook error mentioning “CONNECT tunnel failed,” suggests your Nginx reverse proxy is hitting rate limits, but not necessarily from n8n itself.

Solutions to try:

1. Check and Adjust Nginx Rate Limiting

Look for rate limiting directives in your Nginx config:

# Find these in your nginx.conf or site config
limit_req_zone
limit_conn_zone
limit_rate

If you find them, either increase the limits or exclude the n8n editor API:

# Example: Exclude editor API from rate limiting
location /rest/ {
    limit_req off;
    limit_conn off;
    proxy_pass http://n8n:5678;
    # ... other proxy settings
}

# Keep rate limits only on webhook endpoints
location /webhook/ {
    limit_req zone=webhook_limit burst=20 nodelay;
    proxy_pass http://n8n:5678;
}

2. Increase Nginx Connection Limits

Add these to your Nginx config:

# In http block
worker_connections 4096;
keepalive_timeout 65;
keepalive_requests 1000;

# In your n8n location block
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
proxy_request_buffering off;
client_max_body_size 50M;  # For large workflow JSONs

3. Fix the Facebook Webhook Issue

The Facebook webhook verification failure might be causing cascading issues. In your Facebook webhook node configuration:

Make sure your webhook URL is publicly accessible
Verify the webhook token matches exactly
Consider temporarily disabling Facebook webhooks to see if the 429 errors stop

4. Add n8n Environment Variables

Add these to your Docker Compose:

environment:
  - N8N_DIAGNOSTICS_ENABLED=false  # You already have this
  - N8N_METRICS=false
  - EXECUTIONS_DATA_SAVE_ON_ERROR=none
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false
  - N8N_PAYLOAD_SIZE_MAX=16  # MB, increase if needed
  - N8N_CONCURRENCY_PRODUCTION_LIMIT=10

5. Check GCP Network Limits

GCP has connection limits per VM instance. Check if you’re hitting:

Egress bandwidth limits
Connection tracking limits (conntrack)

Run on your GCP instance:

# Check current connections
ss -s

# Check conntrack usage
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# If count is near max, increase it:
sudo sysctl -w net.netfilter.nf_conntrack_max=262144

6. Optimize Your Nginx Proxy Configuration

Here’s a complete recommended Nginx config for n8n:

upstream n8n {
    server n8n:5678;
    keepalive 64;
}

server {
    listen 443 ssl http2;
    server_name your-domain.com;

    # SSL config here...

    client_max_body_size 50M;
    
    location / {
        proxy_pass http://n8n;
        proxy_http_version 1.1;
        
        proxy_set_header Connection "";
        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_request_buffering off;
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
        
        # Disable rate limiting for editor
        limit_req off;
        limit_conn off;
    }
}

7. Temporary Workaround

While debugging, you can bypass the issue by:

Exporting your workflow as JSON (Download)
Making changes
Importing it back

henryford · February 14, 2026, 2:17pm

I just did this and still my messages were not getting through. Any updates @emiliano2025

gibacache · February 17, 2026, 3:25am

Seems is not a DB or n8n issue…

henryford · February 17, 2026, 4:07pm

Yes we figured it out, it has been Hostinger all along.

emiliano2025 · February 18, 2026, 4:36pm

Hi,

I hope you’re doing well.

I’m reaching out because, unfortunately, the issue we previously discussed has started occurring again. Despite the initial fix, the same error message has resurfaced in my workflow.

Error:
Workflow could not be published:

(#2200) Callback verification failed with the following errors: curl_errno = 56; curl_error = CONNECT tunnel failed, response 429; HTTP Status Code = 429; HTTP Message = Too Many Requests

This is my docker-compose:

version: '3.8'

services:
  n8n-db:
    image: postgres:16-alpine
    container_name: n8n-db
    restart: always
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
    volumes:
      - ./db_data:/var/lib/postgresql/data
    networks:
      - n8n_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5

  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: always
    depends_on:
      n8n-db:
        condition: service_healthy
    ports:
      - "${N8N_PORT}:${N8N_PORT}"
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=${N8N_PORT}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - NODE_ENV=${NODE_ENV}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}
      
      # Security
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_DIAGNOSTICS_ENABLED=false
      
      # Database
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=n8n-db
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      

      - NODE_OPTIONS=${NODE_OPTIONS}
    volumes:
      - ./data:/home/node/.n8n
    networks:
      - n8n_net

networks:
  n8n_net:
    driver: bridge

Please let me know if you see anything wrong in my configuration

emiliano2025 · February 18, 2026, 4:37pm

I apologize, I hadn’t seen this previous response. I will follow your instructions/suggestions right away and will get back to you with the results as soon as I’m done.

emiliano2025 · February 18, 2026, 10:35pm

Update – Clarification Regarding the 429 Error

Hi,

After further investigation on my side, I want to clarify something important regarding the HTTP 429 error during workflow activation with the WhatsApp Trigger.

From the Nginx access logs, I can see Meta’s servers successfully reaching the webhook endpoint, including the hub.mode=subscribe verification request. My server consistently responds with HTTP 200.

There are no HTTP 429 responses in my Nginx access logs or error logs. The infrastructure is not rate-limiting these requests, and there are no limit_req or limit_conn directives configured in Nginx.

When activating the workflow, I sometimes see a 400 response on the first activation attempt and then a successful 200 on a subsequent attempt. This suggests the issue is intermittent.

Given that:

The webhook endpoint is publicly accessible
Meta verification requests return HTTP 200
No 429 responses are generated by my server

It appears that the 429 is not originating from my infrastructure, but likely from the outgoing request n8n makes to the Meta Graph API when attempting to register or update the webhook subscription.

If there is a way to enable more detailed logging of the Graph API response during activation, I’d be happy to provide that.

Thanks.

henryford · February 18, 2026, 11:35pm

Just switch n8n cloud or elestio bro