Azure APIM intermittently receives ASP.NET Core HTTP 500.30 response from Azure AI Search backend

Djay 0 Reputation points
2026-10-27T13:17:33.5833333+00:00

We are experiencing an intermittent issue in Azure API Management when calling an Azure AI Search backend.

The APIM operation forwards the following request:

GET https://<search-service>.search.windows.net/indexes/document/docs/?$top=10&api-version=2019-05-06

The same request through the same APIM instance intermittently returns either HTTP 200 or HTTP 500, without any configuration changes.

Successful request

  • HTTP 200
  • Content-Type: application/json
  • OData-Version: 4.0
  • Azure Search request-id returned
  • Backend response time approximately 19 ms in the captured APIM trace

Failed request

  • HTTP 500
  • Content-Type: text/html
  • Response size: 2416 bytes
  • Backend response received in approximately 3 ms in the captured APIM trace
  • Response body contains: HTTP Error 500.30 - ASP.NET Core app failed to start

Additional investigation performed

  • Direct REST calls to the Azure Search endpoint return HTTP 200.
  • Azure Search Explorer works successfully.
  • Azure Search operation logs checked during the affected period showed successful operations.
  • Search throttling does not correlate with the failures.
  • APIM SNAT Port Analysis reports no SNAT allocation issue.
  • APIM gateway LastErrorReason, LastErrorMessage, LastErrorSource and LastErrorSection are empty.
  • The equivalent operation works in our lower environment.
  • Successful and failed APIM traces show the same backend URL and effectively the same request being forwarded.

The unusual part is that the failed request receives an ASP.NET Core 500.30 HTML response despite the configured backend being Azure AI Search.

What could cause APIM traffic addressed to an Azure AI Search hostname to intermittently receive an ASP.NET Core 500.30 response instead of the expected Azure Search response?

Could this indicate an issue somewhere in the DNS, private networking, routing, or backend platform path? What additional telemetry could help identify which component is generating the 500.30 response?

I've attached sanitised APIM traces for both a successful and failed request for comparison.

APIMError(2).txt
APIMSuccess(2).txt

Azure API Management
Azure API Management

An Azure service that provides a hybrid, multi-cloud management platform for APIs.

0 comments No comments

1 answer

Sort by: Most helpful
  1. Hemant Bharadwaj 85 Reputation points Microsoft Employee
    2026-10-27T15:07:07.32+00:00

    Likely cause: APIM is intermittently reaching a different backend target than Azure AI Search (or a differently routed path), which can explain fast HTML failures with ASP.NET Core 500.30 instead of Search JSON responses.

    Why this fits your data:

    1. Direct calls to Azure AI Search succeed.
    2. Failed APIM responses are HTML with ASP.NET Core startup signature, not typical Search error payload.
    3. The same APIM operation alternates between success and failure, which points to routing or resolution variance.

    Diagnostic branches:

    1. DNS/private endpoint resolution differs across APIM paths.
    2. APIM policy conditionally changes backend URL or headers.
    3. Mixed public/private network path to Search causes inconsistent backend reachability.

    Recommended steps:

    1. Compare successful vs failed APIM traces for final backend URL and Host header.
    2. Enable APIM diagnostics/resource logs and correlate failed calls by timestamp.
    3. Validate Search endpoint networking model is consistent:
      • public endpoint + firewall allow rules, or
      • private endpoint + correct private DNS and VNet path.
    4. Review APIM policies for conditional backend rewrite rules.
    5. If issue persists, open Azure support with sanitized traces and exact UTC times.

    Validation checks:

    1. Run repeated test calls and classify by response content-type and status.
    2. Confirm all failed calls map to one backend path pattern.
    3. After DNS/policy fixes, verify failures disappear across APIM units.

    References:

    “If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.