Hi, I’m running n8n 2.23.2 self-hosted on Docker with Nginx as a reverse proxy and Let’s Encrypt SSL.
The problem: The HTTP Request node (v4.4) hangs indefinitely and returns no output when making GET or POST requests to services.leadconnectorhq.com (GoHighLevel API). It never times out, never returns an error, just shows “No output data.”
What’s strange:
-
The exact same HTTP Request node works perfectly when calling https://v1.api19.com/sms/send (Ahoi SMS API)
-
Both are HTTPS endpoints
-
curl and wget work fine from inside the Docker container to the same GHL endpoint
-
Node.js also returns STATUS 200 from inside the container
Console errors when opening certain nodes:
GET https://n8n.coverageresourcealerts.org/schemas/n8n-nodes-base.googleSheets/4.7.0/sheet/append.json 404
GET https://n8n.coverageresourcealerts.org/schemas/n8n-nodes-base.if/2.3.0.json 404
My Docker run command:
bash
docker run -d --name n8n \
-p 127.0.0.1:5678:5678 \
-e N8N_SECURE_COOKIE=true \
-e WEBHOOK_URL=https://n8n.coverageresourcealerts.org \
-e N8N_EDITOR_BASE_URL=https://n8n.coverageresourcealerts.org \
-e N8N_DEFAULT_HTTP_REQUEST_TIMEOUT=60000 \
-e NODE_ENV=production \
-e N8N_RELEASE_TYPE=stable \
-v n8n_data:/home/node/.n8n \
n8nio/n8n:2.23.2
Nginx config:
nginx
server {
listen 80;
server_name n8n.coverageresourcealerts.org;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name n8n.coverageresourcealerts.org;
ssl_certificate /etc/letsencrypt/live/n8n.coverageresourcealerts.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/n8n.coverageresourcealerts.org/privkey.pem;
location / {
proxy_pass http://localhost:5678;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
chunked_transfer_encoding on;
proxy_buffering off;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
}
What I’ve tried:
-
Setting NODE_TLS_REJECT_UNAUTHORIZED=0
-
Setting N8N_RUNNERS_ENABLED=false
-
Using GET and POST methods
-
Using JSON and Form Urlencoded body types
-
Using query parameters instead of body
-
Adding User-Agent headers
-
Importing cURL directly
Any help would be greatly appreciated. Thank you.
I assume that Node.js works from inside the same container and curl works the issue could be only if HTTP Request node hangs or GoHighLevel.
I’d suspect either:
-
a bug in the specific n8n version you’re running, or
-
an incompatibility between that HTTP Request node version and GoHighLevel’s response handling (compression, chunked encoding, redirects, keep-alive, etc.).
The fastest way to isolate it would be:
-
Create a fresh container running the latest stable n8n.
-
Import a workflow containing only the failing HTTP Request node.
-
Test the same GHL endpoint.
I’ve dealt with something very similar before and based on everything you’ve shared, this isn’t a network, SSL, Docker, or Nginx issue. curl, wget, and Node.js all reaching the GoHighLevel endpoint successfully from inside the container is basically proof that connectivity is fine.
What stands out to me is that the node doesn’t throw an error or timeout it just hangs silently. That specific behavior in my experience means n8n is receiving the response but getting stuck trying to parse or process it, not that the request itself is failing.
Here’s what I’d try:
1. Enable Full Response and disable response parsing in the HTTP Request node. This will help you isolate whether the hang is happening during the request or during how n8n handles what comes back.
2. Compare headers , check the exact headers your working Node.js script sends versus what the HTTP Request node sends. Some GoHighLevel endpoints are sensitive to Accept, Content-Type, or Connection headers.
3. Upgrade if possible 2.23.2 is quite old and there have been several HTTP Request node fixes since then. This honestly feels like something that may already be patched in a newer version.
4. Enable debug logging and watch the container output while the request is running:
N8N_LOG_LEVEL=debug
That should tell you exactly where execution is getting stuck.
Also don’t worry about those 404 schema errors in the browser console, those are just editor UI issues and are completely unrelated to your HTTP node problem.
My honest take: it’s either a response parsing issue specific to how GHL formats their response, or a bug in that version of the HTTP Request node. Everything else you’ve already ruled out points in that direction.
Hi @Maria_Loreto
The problem is that your n8n tool is trying to talk to GoHighLevel, but the conversation is getting “stuck” in the middle. Even though your server is connected to the internet and other tools (like curl) can reach the API, n8n is sending requests that never get an answer, causing it to hang indefinitely without any error message.
This is likely caused by a “packet size” mismatch, known technically as an MTU issue. Think of it like trying to send a physical package through a mail slot; if the package is even one millimeter too wide, it won’t fit. In your case, n8n is sending “packages” of data that are slightly too large for the network path to GoHighLevel, and the network is simply throwing them away instead of telling n8n they were too big.
You might wonder why curl works while n8n doesn’t. This is because different software tools handle data differently. curl is like a seasoned mail carrier who knows exactly how to shrink the package to fit the slot, whereas the engine powering n8n is trying to send the package at full size, leading to a “black hole” where the data disappears and n8n waits forever for a response.
To fix this, you first need to run a simple test command (the “ping test”) to confirm if the packages are indeed too large. If they are, the solution is to change a setting in Docker to lower the maximum packet size. This forces n8n to send smaller “packages” from the start, ensuring they fit through the network pipes and reach GoHighLevel successfully.
docker exec -it n8n ping -s 1472 -M do services.leadconnectorhq.com
Let us know the ping test outcome