Getting HTTP 429 on HTTP Request node, destination is blocking my N8N Cloud IP. Help?

Hi everyone,

I’ve been stuck on a persistent HTTP 429 error in my HTTP Request node for almost 2 days now and I’m running out of ideas. Hoping someone here has dealt with something similar.

What’s happening

My workflow makes a POST request to upload a file to an external endpoint. It’s been running fine for months. Two days ago, it started failing with:

AxiosError: Request failed with status code 429

The errorDetails object is empty — no response body, no headers info, just the 429 status.

What I’ve tried so far

  1. Retrying manually — same error every time, even hours apart

  2. Testing with different data — same file that worked yesterday fails today

  3. Testing my N8N outbound IP against httpbin.org/get → returns HTTP 200 fine, so the IP isn’t globally blocked

  4. Testing multiple destination domains (all hosted with the same provider) → all return 429

  5. Adding Retry on Fail (3 attempts, 10s wait) — doesn’t help, each retry also 429

  6. Waiting several hours between attempts — no change

What the destination hosting provider told me

After escalating to their support team, I received this written response from their Customer Success Team Leader:

"The rate-limiting you’re experiencing is applied at the IP level. When a large volume of requests originates from a small number of shared IPs — which is common with services like Microsoft’s infrastructure — our systems flag those IPs for abusive activity in order to protect server stability for all of our customers.

This isn’t a block on automation tools themselves, and it isn’t something we’re able to lift on a case-by-case basis, as the limits are applied globally.

The root cause here lies with how Microsoft allocates IPs for its services — routing many clients through the same IPs rather than assigning dedicated ones. And sends requests through a single user-agent rather than giving custom ones. That’s unfortunately outside of our control to resolve on our end."

Their two suggested “solutions” were:

  1. Contact Microsoft to request a dedicated IP or custom User-Agent for my requests

  2. Move my N8N workflow off N8N Cloud and self-host it on their servers

Neither of these feels like a realistic option for someone on a standard N8N Cloud plan.

Where I’m stuck

  • The destination provider refuses to whitelist my IP, confirmed in writing

  • I can’t change the N8N Cloud outbound IP

  • I don’t see any option in the N8N Cloud interface to change the User-Agent or route requests through a proxy

  • N8N Cloud (to my knowledge) doesn’t offer dedicated IPs on standard plans

So the block is real, deliberate, and on their side — not my code, not my auth, not my workflow logic. But I still need to get this workflow running.

My questions

  1. Has anyone run into this before? A destination hosting provider refusing requests from N8N Cloud because of shared IP reputation?

  2. Are there any N8N Cloud settings I’m missing that could help? For example:

    • Can I somehow change the User-Agent that N8N sends?

    • Is there a way to route the outbound request through a proxy?

    • Does any plan tier offer a dedicated/static outbound IP?

  3. What workarounds have worked for others? I’ve seen people mention reverse proxies (Cloudflare Workers, AWS Lambda, etc.) — is that the standard approach, or is there something simpler?

  4. Is this something the N8N team can help with via support — maybe by negotiating whitelist agreements with major hosting providers, or by offering different outbound IP pools? Or is it completely on the user to work around?

  5. Is the destination provider’s reasoning legitimate? They’re essentially saying “all Microsoft Azure IPs are suspect” — which seems like it would affect a LOT of N8N Cloud users. Is this a wider issue the community is aware of?

Any advice would be hugely appreciated — this is blocking a production workflow and I’ve already lost 2 days on it.

Thanks in advance

welcome to the n8n community @Penguin32
From what you described, this sounds like an upstream IP reputation/rate-limit policy.
I’d treat the cleanest workaround as moving just that outbound call behind your own relay endpoint (small VPS, Cloudflare Worker, AWS Lambda, etc.) and have n8n call the relay instead. That gives you control over IP, headers, and retry logic without migrating your whole n8n setup. I’d also open an n8n support ticket to ask whether your plan offers static/dedicated egress options or known alternatives for blocked destinations.