I have my n8n set up in a Ubuntu VM on my Synology NAS. It was pain but everything is working now after setting up reverse proxy etc. Google API works fine for example. Telegram hook keeps pointing at my NAS local IP. Any way to fix this?
On new Telegram Message: 400 - {“ok”:false,“error_code”:400,“description”:“Bad Request: bad webhook: IP address MYLOCALIP is reserved”} - Bad Request: bad webhook: IP address MYLOCALIP is reserved
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.)
If telegram is getting the local IP I would guess that the webhook url env option has not been applied correctly.
If you check the url in the node does it show what you have set or the local address? I would maybe recommend stopping the container and starting it again as a restart doesn’t tend to do the job.
Thank you @Jon for getting back to me & for the welcome. I was looking for a long time to integrate langchain stuff into an actual workflow - N8N is perfect for this!
I stopped the Container and started again, no change. It also works perfect for other hooks like GDrive witrh the webhook_url ENV. I don’t think it is applied in the Telegram Trigger.
In general I want to provide a personal assistant to myself and the family through this. I don’t necessarily need to use Telegram, it just happens to be the one messenger we all have that doesn’t cost extra like whatsapp or needs additional tinkering like signal… Happy to go with another alternative if you folks have one?
Looking at the Telegram trigger node on my home instance it appears to be working as expected. What is the URL being displayed for the node?
It is also worth noting that not all triggers work the same so the GDrive trigger is polling based and doesn’t need the correct URL. Could you add a webhook node a workflow and see what the URL is for that as well?
Never looked into that tbh. That’s a worker type setup, right? You think that would solve this issue or something you’d recommend generally when building a chat agent?
I actually added it after some initial failures. So removing it won’t change the behaviour I guess.
I ended up deploying n8n to a hetzner server without any issues. So it definitely must be some misconfig on the reverse proxies on my end I suppose. I’ll try to fix it and post once successful!
It sounds like there could just be something funky with the NAS although it shouldn’t really make a difference. Did you set the same env options on both?
