n8n webhook no responde: 5 causas y cómo solucionarlo (2025)

Has creado tu workflow en n8n, configurado el nodo Webhook con cuidado, activado el workflow… pero cuando haces una petición HTTP al webhook: nada. Silencio absoluto. O peor: error 404, timeout, o respuesta vacía.

Este es uno de los problemas más frustrantes trabajando con n8n, especialmente si eres principiante. La buena noticia: en el 90% de casos tiene solución rápida. En esta guía cubrimos las 5 causas más comunes y cómo solucionarlas paso a paso.

Síntomas comunes de webhooks que no funcionan

Antes de diagnosticar, identifica exactamente qué síntoma tienes:

• 404 Not Found: n8n dice que el webhook no existe
• Timeout / No response: Petición se queda esperando indefinidamente
• Workflow no se ejecuta: Webhook recibe petición pero workflow no arranca
• Respuesta vacía: Webhook ejecuta pero no devuelve datos esperados
• Error CORS: Falla desde navegador pero funciona desde Postman/curl

Cada síntoma tiene causas específicas. Vamos por ellas.

Causa 1: Workflow no está activado (90% de principiantes)

Síntoma: 404 Not Found al llamar al webhook.

Por qué ocurre: En n8n, los webhooks solo responden cuando el workflow está ACTIVO. Si el workflow está en modo inactivo (icono gris en lugar de verde), el endpoint webhook simplemente no existe para n8n.

Solución

Paso 1: Verificar estado del workflow

En la interfaz de n8n:

• Mira la esquina superior derecha del workflow
• Busca el toggle «Inactive / Active»
• Debe estar en Active (verde)
• Si está en «Inactive» (gris), haz clic para activarlo

Paso 2: Verificar URL del webhook

Una vez activado, el nodo Webhook te muestra dos URLs:

• Test URL: Solo funciona cuando tienes el workflow abierto en editor y en modo «listen»
• Production URL: Funciona 24/7 una vez workflow está activo

Usa la Production URL para integraciones reales:

https://tu-n8n.com/webhook/nombre-webhook

Truco rápido: Copia la Production URL, pégala en nueva pestaña navegador. Deberías ver algo (incluso un error JSON) en lugar de 404.

Comando de test con curl

curl -X POST https://tu-n8n.com/webhook/nombre-webhook \
  -H "Content-Type: application/json" \
  -d '{"test": "data"}'

Si devuelve 404: workflow no está activo o URL incorrecta.

Causa 2: Configuración incorrecta del nodo Webhook

Síntoma: 404 o workflow no se ejecuta aunque esté activo.

Por qué ocurre: El nodo Webhook tiene varias opciones que si no se configuran bien pueden romper su funcionamiento.

Solución: Verificar configuración

1. HTTP Method correcto

En el nodo Webhook, verifica que el HTTP Method coincide con el que usas al llamarlo:

• Si tu petición es POST, el webhook debe tener method POST
• Si es GET, method GET
• Si quieres aceptar cualquiera, usa * (wildcard)

Error común: Webhook configurado como GET pero llamas con POST (o viceversa).

2. Path del webhook (Webhook URL suffix)

El Path debe ser:

• Único (no compartido con otro webhook)
• Sin espacios ni caracteres especiales (usa guiones: mi-webhook-test)
• Case-sensitive: MiWebhook ≠ miwebhook

Buenas prácticas para paths:

✅ /telegram-bot-webhook
✅ /shopify-order-created
✅ /api/v1/ingest-data

❌ /mi webhook con espacios
❌ /webhook (demasiado genérico, conflictos)
❌ /MiWebhook (camelCase confunde, usa kebab-case)

3. Authentication

Si has configurado autenticación en el webhook (Header Auth, Basic Auth, etc.), tus peticiones DEBEN incluir las credenciales correctas.

Ejemplo con Header Auth:

# En nodo Webhook: Header Name = "X-API-Key", Header Value = "mi-secreto-123"

# Petición debe incluir ese header:
curl -X POST https://tu-n8n.com/webhook/test \
  -H "X-API-Key: mi-secreto-123" \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

Si el header no coincide: 401 Unauthorized o 403 Forbidden.

4. Response Mode

En configuración avanzada del Webhook, verifica Response Mode:

• Respond to Webhook: El workflow ejecuta y luego responde (sincrónico)
• Respond Immediately: Responde inmediatamente sin esperar workflow (asíncrono)
• When Last Node Finishes: Responde cuando workflow termina (default recomendado)

Si ves «no response», puede ser que Response Mode esté mal configurado.

Causa 3: Problemas de red, firewall o acceso externo

Síntoma: Webhook funciona desde localhost pero no desde internet externo. Timeout o connection refused.

Por qué ocurre: n8n escucha en puerto interno (5678 default) pero no es accesible desde internet sin configuración adicional.

Solución: Exponer n8n correctamente

Escenario A: n8n en servidor propio (homelab, VPS)

Necesitas reverse proxy (Nginx, Caddy, Traefik) o túnel seguro (Cloudflare Tunnel).

Opción 1: Cloudflare Tunnel (recomendado, gratis, sin abrir puertos)

# Instalar cloudflared
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
sudo mv cloudflared /usr/local/bin/
sudo chmod +x /usr/local/bin/cloudflared

# Crear túnel (autenticación con Cloudflare)
cloudflared tunnel login
cloudflared tunnel create n8n-tunnel

# Configurar túnel apuntando a n8n local
cloudflared tunnel route dns n8n-tunnel n8n.tudominio.com

# Archivo config (~/.cloudflared/config.yml)
tunnel: n8n-tunnel
credentials-file: /home/user/.cloudflared/xxxxx.json

ingress:
  - hostname: n8n.tudominio.com
    service: http://localhost:5678
  - service: http_status:404

# Ejecutar túnel
cloudflared tunnel run n8n-tunnel

Ahora https://n8n.tudominio.com/webhook/test es accesible desde internet.

👉 Guía completa: Cloudflare Tunnel para homelab seguro

Opción 2: Nginx reverse proxy

# /etc/nginx/sites-available/n8n
server {
    listen 80;
    server_name n8n.tudominio.com;

    location / {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        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;
    }
}

# Activar site y reiniciar nginx
sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

# Certificado SSL con Let's Encrypt
sudo certbot --nginx -d n8n.tudominio.com

Escenario B: n8n en Docker

Verifica que el puerto está mapeado correctamente:

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n
    ports:
      - "5678:5678"  # Host:Container
    environment:
      - N8N_HOST=n8n.tudominio.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.tudominio.com/
    volumes:
      - ./n8n-data:/home/node/.n8n

Importante: WEBHOOK_URL debe apuntar a tu dominio público, no localhost.

Escenario C: n8n cloud (n8n.io)

Webhooks deberían funcionar out-of-the-box. Si no, verifica:

• Plan activo (webhooks no disponibles en trial expirado)
• URL correcta: https://tuorganizacion.app.n8n.cloud/webhook/...

Causa 4: Workflow tarda demasiado y hace timeout

Síntoma: Webhook recibe petición, workflow empieza a ejecutar, pero el llamador recibe timeout (30-60 segundos sin respuesta).

Por qué ocurre: Workflow tiene operaciones lentas (llamadas API externas lentas, loops grandes, procesamiento pesado) y excede timeout del cliente.

Solución: Workflows asincrónicos

Opción A: Respond Immediately (recomendado para workflows largos)

Configura el nodo Webhook con Response Mode: Respond Immediately.

Esto responde al cliente instantáneamente (200 OK) y luego ejecuta el workflow en background.

Flujo típico:

1. Cliente llama webhook
2. n8n responde inmediatamente: {"received": true}
3. Workflow continúa ejecutándose en background
4. Cliente no espera, sigue con su lógica

Ventajas: Sin timeouts, cliente no bloqueado, UX mejor.

Desventajas: Cliente no recibe resultado del workflow (útil para fire-and-forget, no para APIs que necesitan respuesta).

Opción B: Dividir workflow en dos (webhook + queue)

Workflow 1 (receptor):

• Nodo Webhook (recibe petición)
• Guarda datos en base de datos, archivo o cola (Redis, RabbitMQ, Google Sheets, etc.)
• Responde inmediatamente: {"status": "queued", "id": "123"}

Workflow 2 (procesador):

• Trigger: Poll (cada X minutos) o Webhook secundario
• Lee datos de la cola
• Procesa (operaciones lentas aquí)
• Actualiza estado en base de datos

Cliente puede consultar estado vía otro endpoint: /webhook/status?id=123

Opción C: Optimizar workflow

Si el workflow DEBE responder sincrónicamente, optimiza:

• Reduce llamadas API externas innecesarias
• Usa cache cuando sea posible (nodo Cache)
• Evita loops grandes (procesa en batch)
• Usa nodo HTTP Request con timeout razonable (5-10s max)

Causa 5: Errores dentro del workflow que rompen ejecución

Síntoma: Webhook recibe petición, workflow arranca, pero falla a mitad y no responde nada o responde error genérico.

Por qué ocurre: Un nodo dentro del workflow falla (error HTTP, expresión inválida, datos faltantes) y rompe la ejecución.

Solución: Error handling y debugging

1. Revisar historial de ejecuciones

En n8n:

• Ve a Executions (icono lista en sidebar)
• Busca la ejecución del webhook
• Identifica qué nodo falló (icono rojo)
• Click en nodo fallido → ver error específico

Errores comunes:

• Cannot read property 'X' of undefined: Dato esperado no existe
• HTTP Request failed: 404/500: API externa falló
• Expression error: Expresión JavaScript inválida

2. Añadir error handling

Usa nodos Error Trigger para capturar errores:

Setup básico:

• Crea nuevo nodo: Error Trigger
• Configura qué hacer cuando falla workflow (notificación, log, respuesta custom)
• Conecta Error Trigger a nodo de respuesta alternativa

Ejemplo:

Webhook → HTTP Request (puede fallar) → Respond to Webhook
                ↓ (si falla)
         Error Trigger → Set (prepara error response) → Respond to Webhook

Así, incluso si falla, webhook responde con error legible en lugar de timeout.

3. Debugging con nodo Set / Code

Inserta nodo Set o Code antes del nodo problemático para inspeccionar datos:

// Nodo Code (JavaScript)
console.log('Datos recibidos:', $input.all());
return $input.all();

Ejecuta workflow en modo Test, revisa console logs en navegador (F12 → Console).

4. Validación de datos de entrada

Añade nodo IF después del Webhook para validar datos requeridos:

Webhook → IF (verifica campos requeridos existen)
           → TRUE: continúa workflow
           → FALSE: Respond con error 400 Bad Request

Esto previene errores downstream por datos malformados.

Problemas avanzados y casos especiales

Error CORS (Cross-Origin Resource Sharing)

Síntoma: Webhook funciona desde Postman/curl pero falla desde frontend JavaScript con error CORS.

Solución:

Añade nodo Respond to Webhook con headers CORS:

Response Headers:
{
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type, Authorization"
}

Para producción, reemplaza * con dominio específico: "https://tuapp.com".

Además, maneja peticiones OPTIONS (preflight):

• Configura webhook con method * (acepta todos)
• Añade nodo IF que detecta OPTIONS y responde inmediatamente con headers CORS

Webhook se ejecuta múltiples veces por una sola petición

Síntoma: Una petición al webhook ejecuta el workflow 2-3 veces.

Causas:

• Cliente hace retry automático (navegador, librería HTTP)
• Múltiples workflows activos con el mismo webhook path
• Load balancer o proxy hace retry

Solución:

1. Idempotencia: Añade deduplicación con nodo Set/Code que guarda IDs procesados

// Nodo Code
const requestId = $json.id;  // Asume cliente envía ID único

// Check si ya procesamos este ID (via cache, DB, etc.)
if (alreadyProcessed(requestId)) {
  return []; // Skip workflow
}

return [$json];

2. Verifica workflows duplicados: Lista todos tus workflows, busca webhooks con mismo path.

Webhook no recibe payload grande (datos truncados)

Síntoma: Peticiones con payload >1MB no llegan completas o fallan.

Solución:

Aumenta límite de payload en n8n:

# Variable de entorno (docker-compose.yml o .env)
N8N_PAYLOAD_SIZE_MAX=16  # MB (default es 16MB)

# Si usas reverse proxy (Nginx), aumenta también ahí:
client_max_body_size 50M;

Checklist de debugging completo

Usa este checklist cuando un webhook no funcione:

Checks básicos (5 minutos)

• ☐ Workflow está ACTIVE (toggle verde)
• ☐ Usas Production URL (no Test URL)
• ☐ HTTP Method coincide (GET/POST/etc.)
• ☐ URL webhook es correcta (copia-pega desde n8n)
• ☐ Si hay auth, incluyes credenciales correctas

Checks de red (10 minutos)

• ☐ n8n es accesible desde internet (ping dominio)
• ☐ Reverse proxy o túnel configurado correctamente
• ☐ Puerto correcto (5678 default, o tu custom port)
• ☐ Firewall permite tráfico al puerto n8n
• ☐ HTTPS configurado si usas dominio público

Checks de workflow (15 minutos)

• ☐ Revisar Executions para ver si workflow se ejecutó
• ☐ Si ejecutó: identificar nodo que falló
• ☐ Si no ejecutó: problema es en webhook config o red
• ☐ Verificar datos de entrada con nodo Set/Code
• ☐ Añadir error handling (Error Trigger)

Comandos útiles para debugging

Test webhook básico:

curl -X POST https://n8n.tudominio.com/webhook/test \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

Test con autenticación:

curl -X POST https://n8n.tudominio.com/webhook/test \
  -H "Content-Type: application/json" \
  -H "X-API-Key: tu-secreto" \
  -d '{"data": "ejemplo"}'

Ver respuesta completa (headers incluidos):

curl -i -X POST https://n8n.tudominio.com/webhook/test \
  -H "Content-Type: application/json" \
  -d '{}'

Verificar conectividad n8n:

# Desde servidor donde corre n8n
curl http://localhost:5678

# Debería devolver interfaz HTML de n8n

Logs de n8n (Docker):

docker logs -f n8n

# Busca errores cuando llamas al webhook

Preguntas Frecuentes

¿Cuál es la diferencia entre Test URL y Production URL?

Test URL: Solo funciona cuando tienes el workflow abierto en editor y haces clic en «Listen for Test Event». Se desactiva al cerrar editor. Útil para desarrollo. Production URL: Funciona 24/7 una vez workflow está activo. Usa esta para integraciones reales, webhooks de terceros, APIs, etc. Regla: nunca uses Test URL en producción.

¿Puedo tener múltiples webhooks en un mismo workflow?

Sí, pero solo UNO puede ser el trigger (inicio del workflow). Los demás webhooks deben estar en sub-workflows o ser webhooks de respuesta. Si necesitas múltiples entry points, crea múltiples workflows (uno por webhook trigger) y comparte lógica via sub-workflows.

¿n8n reintenta automáticamente si webhook falla?

No, n8n NO reintenta automáticamente. Si webhook falla, ejecución termina. El cliente (quien llama al webhook) decide si reintenta. Buenas prácticas: implementa error handling en workflow (Error Trigger), responde con códigos HTTP apropiados (200 OK, 400 Bad Request, 500 Internal Error), el cliente puede reintentar basándose en código de respuesta.

Mi webhook funciona pero es muy lento, ¿por qué?

Causas comunes: workflow tiene llamadas API externas lentas (timeout 30s+), loops grandes procesando muchos items, n8n sobrecargado (CPU/RAM al límite), base de datos externa lenta. Soluciones: usa Response Mode «Respond Immediately», divide workflow (webhook rápido + procesamiento background), optimiza llamadas API (reduce timeouts, paraleliza con Split In Batches), escala n8n (más recursos, workers). Meta: webhooks sincrónicos deberían responder en <3 segundos.

¿Cómo uso webhooks de n8n con servicios externos (Telegram, Shopify, etc.)?

Pasos:

1. Crea workflow en n8n con nodo Webhook (path único, ej: /telegram-bot)
2. Activa workflow, copia Production URL
3. Ve al servicio externo (Telegram BotFather, Shopify Admin, etc.)
4. Configura webhook apuntando a tu n8n URL: https://n8n.tudominio.com/webhook/telegram-bot
5. Servicio externo enviará eventos a ese endpoint

Importante: URL debe ser accesible desde internet público (HTTPS recomendado).

¿Cómo aseguro mi webhook para que solo ciertos clientes puedan llamarlo?

Opciones de seguridad:

• Header Authentication: Webhook verifica header secreto (ej: X-API-Key)
• Basic Auth: Usuario/contraseña en request
• IP Whitelist: Solo IPs específicas (config en reverse proxy/firewall)
• HMAC Signature: Servicios externos (Shopify, GitHub) firman payload, verificas firma en workflow
• Cloudflare Access: Autenticación antes de llegar a n8n

Nunca expongas webhooks críticos sin autenticación (bots los encuentran en minutos).

¿n8n tiene rate limiting en webhooks?

n8n self-hosted NO tiene rate limiting por defecto (puedes recibir miles de requests/segundo hasta que servidor colapse). n8n Cloud SÍ tiene límites según plan (ej: 120 requests/minuto en plan Starter). Solución self-hosted: implementa rate limiting en reverse proxy (Nginx: limit_req_zone), usa Cloudflare (rate limiting gratis), añade nodo Redis en workflow para tracking custom.

Recursos adicionales

Guías relacionadas en El Diario IA:

• Guía completa de n8n v2: De cero a experto
• Introducción a n8n: La herramienta de automatización más versátil
• Cloudflare Tunnel para homelab seguro
• Homelab completo 2025: Guía definitiva

Documentación oficial:

• n8n Webhook Node Docs
• n8n Community Forum (troubleshooting específico)

Conclusión

Los webhooks de n8n que no responden tienen, en el 90% de casos, una de estas 5 causas:

1. Workflow inactivo (activar toggle verde)
2. Configuración incorrecta (HTTP method, path, auth)
3. Red/firewall (reverse proxy, túnel, puertos)
4. Timeout (workflow lento, usar async response)
5. Errores internos (revisar Executions, añadir error handling)

Proceso de debugging recomendado:

1. Verifica workflow está activo (30 segundos)
2. Prueba con curl desde terminal (2 minutos)
3. Revisa Executions para ver si workflow se ejecutó (2 minutos)
4. Si ejecutó pero falló: identifica nodo problemático (5 minutos)
5. Si no ejecutó: problema es red/config (10-20 minutos)

Con esta guía y el checklist, el 95% de problemas de webhooks se solucionan en menos de 15 minutos. El otro 5% suele ser configuración avanzada de networking o casos edge específicos (documentación oficial cubre esos).

¿Solucionaste tu webhook? ¿Encontraste algún caso raro no cubierto aquí? ¿Dudas sobre configuración específica? Déjanos un comentario para ayudar a otros.