Local installation on Windows 10 (not Docker), Telegram trigger keeps waiting indefinitely. Other solutions haven't worked

Hello, I’m new to the community and new to n8n. I’ve only been using it for a couple of weeks, and I’d like to learn more about this product.

I’m a computer engineer, and I consider my technical knowledge to be high, or at least medium-high. However, after several days, I haven’t been able to solve a problem that seems to be a recurring one on this forum. I’ve read multiple posts about it in this community and other forums, but none of the solutions have worked for me.

First of all, I’d like to say that I’m Spanish and my English level isn’t very high, so I’ve translated this text using translation tools. I apologize if this translation isn’t very good.

I’ll explain the problem.

Describe the problem/error/question

A few days ago, I installed N8N locally on a Windows 10 computer using npm (I prefer not to use Docker for now, for reasons I won’t explain so as not to be too long-winded). I don’t want to use a tunnel due to the requirements of the project it’s for, although I’ve also tried it and haven’t gotten it to work.

Therefore, I have a Windows 10 computer, a fixed IP address within the local network, and on my router, I’ve redirected external port 443 to port 5678 of this machine.

Since the IP address is dynamic, I used dynamic DNS (DDNS) to have an updated domain pointed to this IP. I used both FreeDNS and NoIP (DDNS.net). For both domains, I requested a Let’s Encrypt certificate, which was installed correctly.

So far, so good. I can successfully access the N8N dashboard from both domains (or subdomains), which are something like (my_subdomain).moot.es and (my_subdomain).ddns.net, and I can work correctly.

The problem arises when I use a Telegram trigger. In this case, when I activate the node, it waits without responding to messages sent by Telegram.

The environment variables are set as follows:
GENERIC_TIMEZONE=Atlantic/Canary
TZ=Atlantic/Canary
N8N_HOST=(my_subdomain).ddns.net (I’ve also tried https://(my_subdomain).ddns.net)
N8N_PROTOCOL=https
N8N_RUNNERS_ENABLED=true
N8N_SSL_CERT=C:/Users/(User)/Documents/CertificadosN8N/fullchain.pem
N8N_SSL_KEY=C:/Users/(User)/Documents/CertificadosN8N/privkey.pem
NODEJS_PREFER_IPV4=true
WEBHOOK_URL=https://(my_subdomain).ddns.net

The Telegram node webhook tells me the following: Address:
https://(my_subdomain).ddns.net/webhook-test/638a02ec-dd74-47ae-bd6b-5b3d402a4b30/webhook
If I make a call to that address using curl with a POST while the node is active, I get this response:
{“message”:“Provided secret is not valid”}
Which I believe indicates that the node is listening correctly.
If I request information from the Telegram API with
https://api.telegram.org/bot***gC9XPIUSrGuwGoZMU/getWebhookInfo
I get this: result
{“ok”:true,“result”:{“url”:“https://(my_subdomain).ddns.net/webhook-test/638a02ec-dd74-47ae-bd6b-5b3d402a4b30/webhook”,“has_custom_certificate”:false,“pending_update_count”:20,“max_connections”:40,“ip_address”:“83...**”,“allowed_updates”:[“message”]}}

The same workflow installed on n8n.io works correctly.
I also tried disabling the Windows firewall and antivirus, but that didn’t solve the problem.

What is the error message (if any)?

There is no error, just waiting

Please share your workflow

It is a simple node of a Telegram trigger waiting for a message

Information on your n8n setup

  • n8n version: 1.82.3
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): npm
  • Operating system: Windows 10

I would really recommend using docker/docker compose for this, as its the recommended way from n8n.

But, this may help, try adding this env var for n8n:

  • N8N_EDITOR_BASE_URL=https://{domain}

It should correctly update more UI values with your domain, especially in cases for auto created connection URIs.

As I mentioned, Docker isn’t a solution for my project. However, I tried it on an Ubuntu virtual machine and had the same problem.

Unfortunately, using the N8N_EDITOR_BASE_URL variable didn’t work either.

Check here about the “secret” webhook parameter. That is what is indicated in your error. Or it could be the secret of the credential itself, did you register the webhook via n8n or curl?

I understand that the webhook was registered from n8n when the credential was created. In the cloud version of n8n, it worked perfectly following the same procedure.

When you try get the webhook to proc from telegram, can you open your chrome/browser dev tools and check the console/network sections to see the request? It would provide more clear details.

It could also be this:

EncryptedCredentials

Describes data required for decrypting and authenticating EncryptedPassportElement. See the Telegram Passport Documentation for a complete description of the data decryption and authentication processes.
|Field|Type|Description|
|data|String|Base64-encoded encrypted JSON-serialized data with unique user’s payload, data hashes and secrets required for EncryptedPassportElement decryption and authentication|
|hash|String|Base64-encoded data hash for data authentication|
|secret|String|Base64-encoded secret, encrypted with the bot’s public RSA key, required for data decryption|

No message is displayed in the Chrome console. I don’t find any explicit webhook calls in the network section. I assume the request is being made by Telegram in the backend.

I was assuming the request made it to your webhook, does it not? Do you get errors on n8n when the webhook is triggered via an event on telegrams end?

No calls are being received from the webhook, however, other calls to the same subdomain do come in. The image shows a call to retrieve an image. I assume the webhook calls are made on the same port 5678. I currently have the external port 443 redirected to the internal port 5678 on the router, and with this configuration, n8n works correctly. I assume Telegram also sends calls to the webhook through port 443.

N8n doesn’t throw any errors, it just waits until I stop it or it times out

So this only comes from making a request to the n8n webhook via curl?

{“message”:“Provided secret is not valid”}

Could you ctl a ctl c the entire workflow, click the ‘</>’ button on the forums and paste the workflow in the field that appears so I can see your setup?

Yes, that response is generated when running the curl -X POST (webhook address) command.
So, I understand that the call is reaching n8n. What I don’t understand is why it doesn’t appear in the network section of Chrome’s devtools :thinking:.
The workflow is just a trigger node. I’ll paste it below.

The Telegram credentials are also configured correctly.

I’ve also tested two bots, one of which I’ve also tested on n8n cloud, and it works perfectly.

So this works on cloud without issue but not self hosted?

There may be setup issues then.

Yes, exactly.

My options are twofold:

  1. It’s an N8N configuration issue. I’ve run countless tests, trying every option I’ve seen in this community and other forums, but I haven’t gotten it to work. I can’t think of anything else to try.

  2. The problem is with my computer or network. Again, I’ve tried everything I can think of. The ports are open (5678 and 5679 with the external port 443 redirected to the internal port 5678). I have the Letsencript certificate installed. I’ve disabled the firewall and antivirus. The application is actually accessible, and when I make a curl call to the webhook, it seems to respond, so I don’t think this is the problem.

I’m trying an external test, setting up a VPS on Hostinguer with Ubuntu and using Docker (although this option wouldn’t work for me in the real world). I haven’t gotten it to work yet, but when I do, I’ll test the webhook to see if it works.

Yeah, having this exclusively local or via IP, makes docker have a lot more issues. Its best to try behind a server with a domain.

Maybe an ssl issue?

I could try using nginx as a reverse proxy, as a last resort. However, I’m one of those people who isn’t satisfied with just solving the problem; I always want to know why it’s failing. I’ll keep trying when I have time. Thanks for your help @ThinkBot.

Hi @mdmiko. It’s unlikely since, as I said, the dashboard is accessed correctly via https, and curling the webhook seems to respond.

Sure, but typically its not entirely meant to be run from an IP. I myself nginx reverse proxy, and so do we with clients. Rarely tried n8n via IP as there are lots of SSL issues with that etc.

Yes, that’s true. I’ve also encountered another issue: the Telegram API only works on certain ports and doesn’t support 5678, which I’d also need to address. I’ll try the reverse proxy option as soon as I can. Thanks.

Same situation. I work without docker and the same error.Have you found the answer yet?