HTTP Request node failing with 403 when checking updates from website

Questions
1

Hey everyone, I am building an automated workflow in n8n to track version updates and patchreleases from our project website, but I keep hitting an obstacle with the HTTP Request node. The plan is to have a schedule trigger fetch the latest version metadata every morning, parse the JSON response, and send an alert to our Discord channel whenever a new build is detected.

Whenever the workflow runs on schedule, the node intermittently throws an ETIMEDOUT or 403 Forbidden error, even though opening the URL directly in a browser loads instantly without any verification challenges. I tried passing custom user-agent headers and enabling the retry on fail toggle, but it still drops connections during peak hours or returns inconsistent response structures.

Has anyone run into similar session or header handshake issues when polling custom endpoints like this, and is there a recommended way to manage headers or handle proxy rotation directly inside n8n to keep these checks reliable?

2

Hey @kentvent88, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Milan_AutomableAI, @darrell_tw, @lvalics - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hey @kentvent88, Welcome to the n8n community!

Which exact URL is the HTTP Request node calling? The link in your post returned an HTML homepage when I checked it, so I can’t tell which JSON endpoint you’re polling.

In a test copy disconnected from Discord, open Options → Response, set Response Format to Text, and enable Include Response Headers and Status plus Never Error. Can you share the 403 response body and headers with cookies/tokens removed, the full ETIMEDOUT error, and whether you’re on Cloud or self-hosted?

4

The 403-in-n8n-but-fine-in-browser pattern almost always comes down to one thing: the server isn’t judging you by your User-Agent string, it’s judging your TLS fingerprint.

n8n’s HTTP Request node uses Node’s TLS stack, which handshakes differently from Chrome or Firefox. Bot protection (Cloudflare Bot Management, Imperva, and the like) spots that before any header is even sent — so no header you set will fix it. Intermittent failures plus the occasional ETIMEDOUT fits rate-limiting layered on top of that.

Before changing anything, diagnose:

  1. Hit the same URL with curl from the same machine/network n8n runs on. If curl also gets 403, it’s server-side protection, not an n8n setting.
  2. Read the response body and headers on the 403 — Cloudflare challenge pages or cf-mitigated headers tell you exactly what’s blocking you.

Then, in order of what actually fixes it:

  1. Don’t scrape HTML for release info — use the feed. Most projects publish an Atom/RSS feed, a changelog API, or GitHub releases. Polling a feed is reliable, cheap, and doesn’t fight bot protection. n8n’s RSS Read node exists for exactly this.
  2. If you must hit the page: send a full browser header set (Accept, Accept-Language, Accept-Encoding, Referer, Sec-Fetch-*) and reuse a session — do one GET to harvest cookies, then pass them on later requests. Keep-alive helps.
  3. Slow down. Poll hourly or daily, not every few minutes, and use retry with backoff plus jitter. Hammering is what turns a soft 403 into a hard IP block.
  4. Proxy rotation exists (HTTP(S)_PROXY env vars or per-node proxy), but it’s the heavy hammer — try the steps above first. And check the site’s ToS and robots.txt, since some sites explicitly forbid automated polling.

If you share the URL Deepankar asked about, it’s usually obvious from the response headers whether it’s Cloudflare or plain rate-limiting.