If it returns HTTP/2 200: The network is fine; the issue is inside n8n (likely a stale proxy setting).
If it returns Could not resolve host: You have a DNS issue.
If it returns Connection timed out or 403 Forbidden: Your VPS IP is blocked by the BBC or your firewall is blocking outbound port 443.
If you tried to use Cloudflare or another tool to bypass regional restrictions, you might have set global proxy variables that n8n is still trying to use via PM2.
Check your current environment variables:
env | grep -i _PROXY
To fix via PM2:
Stop the n8n process: pm2 stop n8n (or whatever your process name is).
Clear the environment variables from the PM2 process:
pm2 delete n8n
Start n8n again without the proxy variables:
pm2 start <your-n8n-start-command> --name n8n
If the curl test failed with “Could not resolve host,” your DNS settings might have been corrupted during the Cloudflare installation.
Try switching to Google DNS or Cloudflare DNS:
Edit /etc/resolv.conf:
sudo nano /etc/resolv.conf
Replace the contents with:
nameserver 1.1.1.1
nameserver 8.8.8.8
Save and test the curl command again.
Many large sites (like the BBC) block IP ranges from popular VPS providers (DigitalOcean, Hetzner, AWS) to prevent scraping. If curl returns a 403 Forbidden or simply hangs:
Test with a different URL: Run curl -I https://www.google.com. If Google works but BBC doesn’t, your VPS IP is blocked.
Solution: You will need to use a Proxy node or a VPN on your VPS to route the request through a residential IP.
This tests the connection outside of n8n, so we can tell if the problem is your VPS/network or something specific to n8n. If the curl fails too, it’s likely your server’s connection or DNS. If it works fine, the issue is on n8n’s side. So with this we will be able to check your problem better!
Hi @kaung_min Welcome!
A 200 from curl with the node still failing puts this inside the Node process, not the network. The Cloudflare client brings up IPv6, and once it is removed the box can still resolve AAAA records that no longer route, curl falls back to IPv4 on its own but Node does not. Force IPv4 first:
Adding one thing to kjooleng’s list, because it catches people out and the symptom looks identical to an IP block: it is often not the IP, it is the HTTP client.
We scrape for a living and measured this recently. On one Cloudflare-protected site, from a single clean IP, same minute, same URL: undici failed 8 out of 8 with 403, while got-scraping passed 4 out of 4. Nothing changed but the client library. On a different site, every HTTP client we tried failed and only a real browser got through. The TLS ClientHello differs between clients and Cloudflare reads it before your request reaches the application at all.
So the practical test: if curl from the VPS returns 200 but n8n’s HTTP Request node still 403s from that same box, your IP is fine. curl and Node’s fetch look different on the wire, and the site is reacting to that, not to where you are.
Second thing from the same investigation, worth trying before you go buy residential proxy: the block can be path-scoped rather than domain-wide. On that site the rendered HTML page 403’d for every client, but the JSON endpoint the page itself calls was not covered by the rule and returned 200 happily. Open the page in a browser, look at the network tab, find what it fetches for its own data and point the HTTP Request node at that instead. It is usually a much smaller response too, which matters if you are paying for bandwidth.
For the BBC specifically, kjooleng is right that VPS ranges get blocked wholesale, so that one probably is the IP. Worth running both checks before spending money on proxies though.