I am having URL cannot be fetch in my hosted n8n

I set up n8n on vps with pm2 and nginx.

When i use Google-console-ai, it says location not available so I decided to use cloudflare.
After using cloudflare, I get like ..

It was not possible to connect to the URL. Please make sure the URL " <![CDATA[BBC Sport]]> **" it is valid!

It worked before so I disconnect and uninstall cloudflare.

But still getting that error.

Please let me know the solution if anybody has faced similar problem.

Thanks.

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

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Serkan_Sahin, @darrell_tw, @koms24 - 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.

@kaung_min

Log into your VPS via SSH and run the following command to see if the OS can reach the URL independently of n8n:

curl -I https://feeds.bbci.co.uk/sport/football/rss.xml
  • 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:

  1. Stop the n8n process: pm2 stop n8n (or whatever your process name is).
  2. Clear the environment variables from the PM2 process:
pm2 delete n8n
  1. 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:

  1. Edit /etc/resolv.conf:
sudo nano /etc/resolv.conf
  1. Replace the contents with:
nameserver 1.1.1.1
nameserver 8.8.8.8
  1. 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.

Hello!

Try running this directly on your VPS via SSH:

curl -v <![CDATA[BBC Sport]]>

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!

It works to fetch with curl in the server terminal tho

I get 200 when use curl with url in server terminal tho

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:

export NODE_OPTIONS="--dns-result-order=ipv4first"
pm2 restart n8n --update-env

pm2 keeps the environment the process was started with, so --update-env is what actually passes the variable through.
See this:

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.

After like 1 day, it works automatically. I think n8n baned me for a short period of time .