I am experiencing an issue with some webhooks not being triggered on my self-hosted n8n instance. My instance is configured in queue mode. While some webhooks work fine, others do not seem to be received at all.
To debug, I am monitoring the Traefik access logs inside the Docker container with the command:
However, I notice that some webhook requests never appear in the Traefik logs, meaning they are not reaching n8n at all despite having been sent.
My hosting provider is Hostinger, and I have confirmed that no firewall rules are active in the Firewall Panel in Hostinger App. That might not block incoming webhook requests.
Has anyone encountered similar issues? Could this be related to queue mode, Traefik configuration, or something else ?
What is sending the webhooks? And how are you sure they are being sent?
Queue mode with only 1 main instance and now webhook workers should be very simple in regards to webhooks coming in. All should be sent to the main instance.
So it is very weird that some would work and some not.
I cannot verify with certainty that every webhook is sent, as these webhooks are triggered externally by a CRM called Sellsy. However, I have conducted tests using webhook.site, and in my experience, I have never encountered a case where a webhook was not sent.
I have seen on some posts that the âQueue Modeâ in n8n, when combined with a reverse proxy like Traefik, can potentially cause issues with webhooks not being processed consistently. Honestly, I am not very familiar with the administration side of the n8n instance or the specifics of the reverse proxy setup.
So, while your point about all webhooks going to the main instance under Queue Mode makes sense, the inconsistencies I experience might be related to reverse proxy configuration or other network infrastructure factors that I donât fully manage or understand.
If you have any advice on how to investigate or confirm the webhook delivery from Sellsy or how to handle this properly with n8n in Queue Mode behind a reverse proxy, that would be very helpful.
The config looks fine. Keep in mind you have an encryption key in there, this could be a security risk to have public.
I do not use Traefik myself, but it does look ok. There is loads of people using it, so I think the issue must be somewhere else in the configuration.
Can you test with just a main instance without queue mode? Just to make sure queue mode isnt actually causing it. (which it shouldnât)
Thanks for the suggestion, but Iâm not sure it will help. What exactly do you want to see with this webhook? What do you want me to do, cause the behavior seems totally random.
I experience the same issue even without queue mode. When I test with the CRM and webhook.site, all webhooks appear to be sent correctly.
I suspect the problem might be somewhere in my VPS stack on Hostinger. Iâm trying to monitor incoming POST traffic on the VPS using netstat or other tools, but Iâm quite new to networking.
My Hostinger VPS was initially using the default subdomain: https://n8n.srv1234.hstgr.cloud (no custom domain configured).
After some investigation, I discovered that certain DNS providers have blacklisted the hstgr.cloud domain. This could explain why, depending on the DNS configuration of a service provider like CRM, the DNS resolution for my webhook URL sometimes failedâresulting in missed webhook calls.
To resolve this, I linked a custom domain name to my VPS and updated my Traefik configuration accordingly. Since making these changes, the webhooks are working reliably and I havenât experienced any further webhook losses.
