Hi everyone,
I’m running a self-hosted n8n instance on a Hostinger VPS behind Traefik.
I have built my own custom JavaScript chatbot that sends requests directly to an n8n webhook using fetch().
The strange problem is that the chatbot works perfectly on some devices but completely fails on others.
For example: Works on my phone. Works on my own computer. Does not work on my mother’s computer. Some other users also report the same issue.
The important thing is that the problem is device-specific, not user-specific.
A few months ago I changed my webhook domain because I thought antivirus software was blocking it.
Originally I used another domain, but I changed everything to:
using Traefik with HTTPS.
Unfortunately, nothing changed. The chatbot still works on some devices but not on others.
Today I also fixed another issue where Traefik had stopped because Nginx was occupying port 80. Traefik is now running correctly, HTTPS works, and the webhook is accessible.
The confusing part is:
On devices where it works, everything is perfect.
On devices where it doesn’t work, the request never seems to reach the chatbot correctly.
My frontend displays “Unknown error”, but that message is my own fallback message, not an n8n error. It is shown whenever the JavaScript fetch() fails or the request cannot be completed.
The workflow itself works correctly when the request reaches n8n.
I’m attaching screenshots of:
My setup.
Successful workflow executions.
The frontend behaviour.
Has anyone experienced a situation where a webhook works on some devices but not on others?
Could this be related to:
CORS?
Browser security?
Antivirus software?
DNS or SSL?
Reverse proxy (Traefik)?
Something else I’m overlooking?
Also, what would be the best way to debug why fetch() succeeds on some devices but fails on others?
Any suggestions would be greatly appreciated.
Describe the problem/error/question
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
@Rafael_Van_Meerbeek device-specific failures + your own fallback firing means the fetch is dying at the network level before it ever reaches n8n, so its not your workflow, its DNS/TLS/antivirus on those specific devices. quickest way to split it: on a device where it fails, open the webhook URL directly in the browser and check the console. a cert/security warning points to TLS trust (older devices not trusting the chain), and cant-resolve or connection-refused points to DNS or antivirus blocking the domain. which one shows up?
@Rafael_Van_Meerbeek connection-timed-out (not name-not-resolved, no cert warning) means DNS resolves fine but the TCP connection to the IP never completes, and that varying by device is usually IPv6. check if your domain has an AAAA record, if it does but the VPS/Traefik isnt actually serving v6 (or its misconfigured), the devices that try the v6 address hang while v4 ones connect fine. quickest fix, remove the AAAA record so everyone uses IPv4, or fix IPv6 on the server. confirm it with curl -6 vs curl -4 to the domain from a failing network.
dig api.novaintellectagents.com A
dig api.novaintellectagents.com AAAA
The AAAA query returns no answer, so the API is IPv4-only.
Does that rule out the IPv6 theory?
The strange thing is that the affected devices still get ERR_CONNECTION_TIMED_OUT, while other devices on different networks can access the exact same endpoint without any issues.
@Rafael_Van_Meerbeek yeah that rules IPv6 out, good check. so DNS resolves but the same IP times out from some networks, and a timeout (not connection-refused) means the packets are being silently dropped, which is almost always a firewall. prime suspect is server-side: fail2ban, ufw, or Hostingers own firewall banning those source IPs. check fail2ban-client status, ufw status, and the Hostinger firewall panel for bans. then run tracert to 31.97.199.227 from a failing network, if it reaches Hostinger and stops there its the server firewall, if it dies earlier its ISP/routing on that network.
@Rafael_Van_Meerbeek nice, that fully rules out your side, server and firewall are clean. so its upstream, either the route to 31.97.199.227 is broken from those networks (your tracert will show where it dies), or more likely the IP is on a reputation blocklist those networks/ISPs/antivirus honor and silently drop, recycled Hostinger VPS IPs often carry a bad rep from a previous tenant. check it on abuseipdb or spamhaus. cleanest fix either way: put the domain behind Cloudflare (free), you get a well-reputed IP every network can reach and it hides your origin, which sidesteps both the routing and reputation issues at once.
Hey @Rafael_Van_Meerbeek, Cloudflare suggestion is the right move here. steps to get it done:
Check the IP reputation first, paste 31.97.199.227 into abuseipdb.com and spamhaus.org. If it shows a bad history, that confirms the root cause.
Add your domain to Cloudflare (free), sign up, add novaintellectagents.com, and point your nameservers to Cloudflare. Your A record stays the same but traffic now flows through Cloudflare’s clean IPs, which every network trusts.
Make sure the orange cloud is ON for api.novaintellectagents.com in Cloudflare DNS, that’s what proxies the traffic and hides your origin IP.
In Traefik, restrict inbound connections to Cloudflare’s IP ranges only (they publish the list at IP Ranges | Cloudflare ) this protects your origin and prevents anyone bypassing Cloudflare directly to your VPS IP.
This should fix the device-specific failures entirely since no one will be hitting your Hostinger IP directly anymore.
ERR_CONNECTION_TIMED_OUT means the request is dying before n8n can even be wrong. The first split I would make is:
zero request in Traefik/Hostinger logs = routing, firewall, ISP, or server edge;
request appears but no workflow execution = n8n/webhook path problem;
execution appears and fails = workflow logic problem.
So I would stop debugging CORS until you prove whether the failing device reaches Traefik at all.
From one failing network, do you see any access-log line for that request on the server side?
Tony’s split (Traefik logs first) is the right call - don’t chase CORS until you confirm the request is even reaching your server.
If you do see the request hitting Traefik but it fails there, check the SSL cert chain. Missing intermediate certs cause device-specific drops that look identical to timeouts - devices running stricter root stores (older Windows, some Android versions) will silently drop the connection. Test the chain at SSL Server Test (Powered by Qualys SSL Labs) or run curl -v --max-time 5 https://api.novaintellectagents.com from the failing machine. If you see SSL certificate verify failed or the chain is incomplete, that’s your culprit - Traefik needs the full cert bundle including intermediates.
I second the use of Cloudflare for applications like this!
@Rafael_Van_Meerbeek obvious question but have you ruled out the browser blocking the request? Have you tested say Safari vs Chrome vs Firefox? to see if you’re getting the same behavior across all 3?
Works on my phone.
Does not work on my mother’s computer.
