Problem Azure API manager routing to backend

Question

Problem Azure API manager routing to backend

Peter Vercoutter 0

I have a network problem that I've narrowed down to the Azure API manager. I've got 2 services, erpservice (backend: https://api-erpservice.van.be/p/dock/erpservice/) and configuratorservice (backend:https://api-configuratorservice.van.be/p/dock/configuratorservice/). If I try to use another backend url for erpservice (https://api.van.be/p/dock/erpservice/) and configuratorservice (https://api.van.be/p/dock/configuratorservice/) (that are defined URL's and going to the same api backend service) , it seems like Azure is 0.0x% of the time sending to the wrong backend. Namely, the other service of the two.

Is it possible that Azure API mgr has problems with multiple API's having the same hostname? Does it have networking pooling problems? In the application insights of the API's, it also looks like it's using the right backend url.

I don't have a scenario where it's reproduceable, it's really random.

My API policy looks like this

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="configuratorservice-backend" />
    </inbound>
    <backend>
        <forward-request timeout="0" />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

0 comments

2 answers

Your answer

Answer 1

Siddhesh Desai 6,555 Microsoft External Staff Moderator

Hi @Peter Vercoutter

Thank you for reaching out to Microsoft Q&A.

Azure API Management does not have any inherent issues with routing traffic when multiple APIs use the same hostname, and it does not randomly forward requests to an incorrect backend due to networking or connection pooling. Routing in APIM is deterministic and is strictly controlled by API configuration, operation matching, and applied policies. When traffic appears to be routed to the wrong backend in a seemingly random manner, the issue is almost always related to policy inheritance, backend resource reuse, API path or operation overlap, or API revision/version configuration. Although Application Insights may show the expected backend URL, an inherited or overridden policy can still redirect traffic at runtime, which makes the behavior appear intermittent and difficult to reproduce.

Refer below points to resolve this issue or this is the workaround

Verify policy scope and inheritance

Ensure that the <set-backend-service> policy is applied only at the intended API or operation level. Check for the same policy at the global (All APIs), product, or parent API level, as policies applied there are inherited by all APIs and can cause traffic to be routed to an unintended backend.

Use dedicated backend resources per API

Even if multiple APIs ultimately point to the same backend host, define separate backend resources in APIM (for example, one backend for erpservice and another for configuratorservice). This avoids accidental reuse or overrides of backend configuration across APIs.

Validate API base paths and operation definitions

Confirm that each API has a unique base path and that there are no overlapping or wildcard (/*) operations that could match requests for multiple APIs. Overlapping paths can cause APIM to select an unexpected API or operation.

Check API revisions and versions

Make sure only the intended API revision or version is active and receiving traffic. If multiple revisions are enabled, traffic may be split, leading to different backend routing behavior.

Enable APIM diagnostic logs for backend requests

Turn on API Management diagnostic logging (BackendRequest/BackendResponse). These logs show the exact backend URL used for each request and are the most reliable way to confirm which backend APIM is actually calling.

Peter Vercoutter 0 Reputation points

2026-04-28T11:06:16.07+00:00

Thank you for your response. I had already checked all of your options. I've also looked in the application insights to the exact used backend url, and that seems to be correct. But the call still ends up at the wrong backend. I was wondering if Azure APIM could make a mistake somwhere by reusing connections because they just have the same hostname, not the full path.
Siddhesh Desai 6,555 Reputation points Microsoft External Staff Moderator

2026-05-01T06:45:40.1166667+00:00
Hi @Peter Vercoutter

Azure API Management does not route requests based on hostname-only connection reuse, and it does not mix requests across backends due to HTTP connection pooling. Even when multiple APIs share the same hostname, APIM maintains strict request isolation and applies routing decisions per request based on the resolved API, operation, and policy execution. Under the hood, APIM uses HTTP connection pooling, but this operates at the transport layer and does not override or influence routing decisions at the application layer (path + policy). If Application Insights confirms that the correct backend URL is being selected, yet the request is processed by the wrong backend service, the issue is not due to connection reuse but rather due to how the backend service itself interprets or routes the request after APIM forwards it. This can happen in scenarios where gateways, reverse proxies, or backend infrastructure route requests based on hostname or insufficient path/context separation, making the issue appear as if APIM is misrouting.

Refer below points to resolve this issue or this is the workaround

Validate backend infrastructure routing.

Check whether https://api.van.be is behind a reverse proxy, load balancer, or gateway (e.g., Application Gateway, NGINX, IIS, Kubernetes ingress). If routing is based only on hostname and not strictly on path (/erpservice vs /configuratorservice), requests may be misdirected after leaving APIM. Ensure backend routing rules differentiate using full paths and not just hostname.

Confirm Host header behavior and enforce it explicitly.

If the backend uses the Host header for routing, APIM may be forwarding the same host (api.van.be) for both APIs. In such cases, the backend may not distinguish correctly between services. You can explicitly set the Host header per API:

<set-header name="Host" exists-action="override"> <value>api-erpservice.van.be</value> </set-header>

Check for backend-side connection reuse issues.

While APIM itself does not mix routing, intermediate infrastructure (like proxies or ingress controllers) may reuse connections improperly if routing rules are not strict. Verify that backend components do not cache or reuse connections in a way that ignores request paths.

Test with unique hostnames vs shared hostname.

You already observed that using distinct hostnames (api-erpservice.van.be and api-configuratorservice.van.be) works correctly. This strongly indicates the issue lies in backend routing configuration when using the shared hostname (api.van.be). Prefer distinct hostnames or enforce strict routing rules internally.

Enable end-to-end request tracing across all layers.

Correlate requests using headers like x-correlation-id or traceparent from APIM through backend logs. This helps confirm that APIM forwards correctly and identifies exactly where the routing deviation occurs.
Pravallika KV 14,235 Reputation points Microsoft External Staff Moderator

2026-05-05T11:50:56.5866667+00:00

@Peter Vercoutter , following up to see if you had a chance to check the above response and if it was helpful. Please let us know if you have any questions.
Peter Vercoutter 0 Reputation points

2026-05-06T07:23:18.2366667+00:00

I've already tried all those proposals before I made this ticket. But thank you for the extensive list of options. We will keep our stable configuration for now: using different hostnames.
FYI: The calls are going over a proxy before reaching the backend but we also checked everything there already. We've lost to much time already on this topic and it's not worth it anymore since we have a stable environment now. Thank you!

Answer 2

Azure API Management supports multiple APIs that share the same hostname. The behavior described is not caused by hostname reuse or connection pooling between different backends.

Key points from the configuration and platform behavior:

The set-backend-service policy
- The policy explicitly routes the request to the backend entity identified by backend-id:
```
     <set-backend-service backend-id="configuratorservice-backend" />
```
- This changes the backend service base URL for the request to the URL configured on the configuratorservice-backend entity, regardless of the original API serviceUrl.
- Backend entities are the supported way to centralize backend URLs and apply features like load balancing and circuit breaker rules across multiple APIs.
Multiple backends with the same hostname
- API Management can have multiple backend entities whose URLs share the same hostname but differ by path (for example, /erpservice vs /configuratorservice).
- API Management selects the backend based on the policy (backend-id or base-url) applied to the request, not by hostname alone. Having the same hostname on different backends is supported and is not documented as a cause of cross-routing.
Automatic backend detection
- At runtime, if set-backend-service is not used, API Management can automatically detect and use a backend entity when its URL matches the backend service URL being called.
- In the provided policy, set-backend-service is explicitly used, so the backend for that operation is determined by backend-id, not by automatic detection.
Recommended checks
- Ensure each API/operation that must call a specific backend uses the correct set-backend-service policy (correct backend-id) at the effective policy level (API, operation, product, or global). Use “calculate effective policy” to confirm there is no conflicting routing policy.
- Verify that each backend entity has the correct base URL and that there is no overlap or misconfiguration between the erpservice and configuratorservice backend definitions.
- Avoid trailing-slash inconsistencies in base-url definitions, as recommended, to prevent subtle misrouting or path concatenation issues.

There is no documented limitation indicating that API Management randomly routes to the wrong backend when multiple APIs share the same hostname. When set-backend-service is configured with the correct backend-id, requests are routed deterministically to the configured backend entity.

References:

Share via

Problem Azure API manager routing to backend

2 answers

Your answer