You may encounter "
Bad gateway error code 502"(
IIS log shows 502 response too, but everything is fine with HTTP) on a .NET Core website with
HTTPS protocol
randomly after enabling
CDN. According to Cloudflare's documentation, this is a known issue pattern:
"This issue can occur when communicating with an origin that partially supports HTTP/2. If the origin requests a downgrade to HTTP/1.1 (for example, via an RST_STREAM frame with HTTP_1_1_REQUIRED), Gateway will not automatically reissue the request over HTTP/1.1 and will instead return a 502 Bad Gateway. To resolve this, disable HTTP/2 at the origin server."
What's happening?
- Cloudflare connects to your .NET Core/Kestrel origin using HTTP/2 (over HTTPS).
- During the HTTP/2 connection, your .NET Core application encounters a situation where it needs to fall back to HTTP/1.1.
- It signals this by sending an RST_STREAM frame with HTTP_1_1_REQUIRED error code.
- Cloudflare does NOT automatically retry the request over HTTP/1.1 when it receives this signal. Instead, Cloudflare returns a 502 Bad Gateway to the client.
With plain HTTP (no Cloudflare proxy), clients connect directly to your origin and can handle the HTTP/2→HTTP/1.1 transition properly.
Why it's random?
- Not all triggers HTTP/2 → HTTP/1.1 fallback.
- Depends on specific request patterns, connection states, or resource usage.
- May only happen under certain load conditions or with specific request types.
Solutions:
- Disable HTTP/2 at Origin (Recommended Quick Fix), this forces Cloudflare to connect using HTTP/1.1, which .NET Core handles reliably
- In IIS: Disable HTTP/2 protocol bindings for your site.
- In .NET Core/Kestrel: Configure Kestrel to not use HTTP/2.
2. Fix HTTP/2 Implementation in .NET Core
- Ensure you're using a recent version of .NET Core (3.1+ recommended).
- Keep Windows updated for the latest HTTP/2 support in Schannel.
- Check for known HTTP/2 bugs in your specific .NET Core version.
3. Cloudflare-Side Workaround
- In Cloudflare dashboard, go to Speed > Settings > Protocol Optimization. However, the most reliable fix is usually on the origin side.
Article ID: 2333, Created: March 26 at 1:58 AM, Modified: March 26 at 2:07 AM