Describe the problem/error/question
Hola.
Tengo N8N alojado en una cuenta de Hostinger.
Cuando intento ejecutar un nodo “When chat message received” (Cuando se recibe mensaje de chat), no hace absolutamente nada. Sin mensajes de error, sin marca de verificación verde que muestre que lo intentó… nada en absoluto. Intenté abrir la URL del chat en mi navegador, al menos se abre, pero tampoco hay respuestas allí. Creé una API en Hostinger y la configuré en N8N, pero eso no resolvió el problema.
Lo que sucede es que tengo otra cuenta de N8N, fuera de Hostinger, y funciona perfectamente allí, aunque esa versión está completamente desactualizada.
Intentę buscar soluciones en línea, pero aún no he encontrado a nadie que hable sobre este problema específico. ¿Alguien más ha pasado por esto?
What is the error message (if any)?
Please share your workflow
Este es el que no funciona (recreado a partir del que sí funciona):
Este es el que sí funciona.
Share the output returned by the last node
Information on your n8n setup
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app): Hostinger
- Operating system:
@Caike_Oliveira los logs no muestran nada ejecutado, así que el mensaje del chat en realidad no está llegando a n8n para disparar el trigger, no es el workflow. en una caja auto-alojada como hostinger casi siempre es WEBHOOK_URL que no coincide con tu URL pública real, así que la solicitud del chat no puede volver a entrar. ¿WEBHOOK_URL está configurado, y a qué, tu dominio hostinger real o algo como localhost?
Basándose en lo que dijo @achamm, en Hostinger esto normalmente se configura a través del panel de variables de entorno de la aplicación n8n, no por SSH, en la sección de configuración/ajustes de tu instancia de n8n. Verifica qué valor tiene WEBHOOK_URL allí; debe coincidir exactamente con la URL con la que accedes a n8n (incluyendo https://).
Una cosa que debes verificar independientemente de eso: ¿este flujo de trabajo realmente está guardado y activado (interruptor en la esquina superior derecha del editor)? La URL de producción del Chat Trigger solo responde cuando el flujo de trabajo está activo. Si solo estás abriendo la URL del chat mientras el flujo de trabajo está en estado borrador/inactivo, obtendrás exactamente este síntoma (la página se carga, pero los mensajes no van a ningún lado, ninguna ejecución registrada).
Si está activo y WEBHOOK_URL se ve correcto, intenta hacer clic en el botón “Open chat” directamente desde dentro del nodo en lugar de usar una URL copiada manualmente. Los configuraciones de Hostinger a veces hacen proxy a través de un prefijo de ruta que el propio nodo tiene en cuenta automáticamente en la vista previa, pero una URL escrita manualmente no.
Hola.
Gracias por las respuestas, pero resultó que no tenía nada que ver con webhook.
La „n8n_encryption_key
@Caike_Oliveira buena observación, eso explica perfectamente el error silencioso. Una clave N8N_ENCRYPTION_KEY vacía significa que n8n no puede descifrar tus credenciales guardadas, así que los nodos respaldados por credenciales simplemente fallan sin mostrar ningún error, exactamente lo que estabas viendo.
Vale la pena asegurarlo ahora que funciona: mantén esa clave exacta de forma permanente y haz una copia de seguridad en algún lugar. Si alguna vez cambia o se reinicia a vacío, todas las credenciales que ya hayas guardado se volverán indescifrable y tendrías que volver a introducirlas todas. Así que asegúrate de que esté fijada en la configuración de variables de entorno de Hostinger en lugar de dejarla para que se regenere en un redesploy.
Golpeé esto exactamente con el Chat Trigger y me volvió loco porque la página de chat se carga bien mientras que nada llega a n8n en absoluto. El trigger solo se activa cuando el flujo de trabajo está activo y el chat publica en la URL del webhook de producción, no en la de prueba, así que si estás en la URL de prueba obtienes verde pero nada cada vez. En auto-alojamiento detrás de un proxy inverso es generalmente peor: el proxy se traga la ruta del chat/webhook, o suelta la actualización del websocket, por lo que el mensaje nunca llega. Establece WEBHOOK_URL en tu URL pública real, activa el flujo de trabajo y asegúrate de que el proxy reenvíe tanto las rutas de chat/webhook como las conexiones de websocket. Una vez que se alineen, las respuestas comenzaron a mostrase para mí de inmediato.
