Intermittent 502 Bad Gateway errors from MCP endpoint under moderate call volume (no retry guidance)

[MikeKovetsky]

Hi Bright Data team,

We’re using the Bright Data MCP in an agent-based workflow (via n8n).
Under moderate load (~100 MCP calls per workflow run), we occasionally receive:

502 Bad Gateway responses (HTML error page from gateway)

The error is rare per-call, but statistically guaranteed at scale.
There is currently no documented retry / backoff guidance specific to MCP usage.

Questions:

1. Are intermittent 502s expected from the MCP gateway?
2. Do MCP endpoints support Retry-After headers?
3. Is there an official recommended retry + backoff policy for MCP?
4. Are there known concurrency or rate limits specific to MCP usage?

This is not a routing issue on our side — MCP dynamically selects endpoints/params as designed.

Thanks in advance — guidance here would help make MCP reliable at scale.

[meirk-brd]

Hi Mike,

Thanks for reaching out.

In general, you shouldn’t see 502 errors originating from the MCP endpoint itself. In some cases, a 502 may be returned by a specific MCP tool, depending on the target you’re interacting with-for example, if a target site is actively blocking requests. That said, these cases are something we can usually handle and remediate.

To help me investigate further and advise on the best next steps (or address the issue if it’s on our side), could you please share a bit more information?

Specifically:

• The email address you used to sign up for Bright Data (I tried mkovetsky@gmail.com, but it appears the account may be associated with a different email).
• Confirmation on whether you’re certain the 502 response is coming from the MCP gateway itself (mcp.brightdata.com), or from one of the MCP tools.

Once I have this information, I’ll be able to dig deeper into what might be causing the failures and provide more concrete guidance.

[MikeKovetsky]

I appreciate your quick response, Meir!

The email we're likely using is m@portal.ai. Or h@portal.ai.
We've refactored our workflow to use brightdata less often, so I haven't see 502 in the last 2 days.
I'll provide the details if it happens again.

[meirk-brd]

Sounds good @MikeKovetsky

Leaving this issue open for now until we can ensure there are no 502's on your end!

[MikeKovetsky]

@meirk-brd, just flagging that we’re still seeing this issue. It’s not very frequent, but it could become critical once we start scaling. Some details:

When it occurs, subsequent requests fail as well.

We sometimes see 504 Gateway Timeout followed by 502 Bad Gateway errors (screenshots attached from our production n8n workflows).

Our pipeline triggers a high number of MCP requests in a short time (often 50+). My suspicion is that this burst causes timeouts and possibly a server restart before autoscaling can react, leading to temporary downtime.

Happy to share more details if needed.

[autumn-ma]

This is prominent for API calls as well, it has increased from 4% to 40% in span of few hours. I have raised ticket about this but it seems they are lying about sub 15 minutes reply :) Also since on residential proxy they charge $8/Gb, each 502 failure uses 700bytes, if we scale to 10,000 failed 502s ≈ 7MB. At $8/GB that's ~$0.06 which seems really scummy.