Client Route Report
This screen is reached from Admin menu > Analytic > Reports > Metrics, under the Conflicts tab. The Conflicts tab is only visible in the Admin menu; it does not appear on the Metrics page under the Project menu.
The screen has two tabs — the two sub-reports of the Conflicts tab:
Static analysis of the stored configuration. Shows whether routes conflict with one another.
Asks the running workers what they would do with a given request. A record of the gateway's current behaviour rather than of its configuration.
Overview
Client Route Report analyzes the client route configurations of your API Proxies and Proxy Groups to detect potential conflicts. Through this report, you can see route conflicts in advance and resolve configuration issues.
Report Table
Report results are displayed in the following columns:
| Field | Description |
|---|---|
| Project | Name of the project that the route belongs to |
| Type | Type of the route (API Proxy or Proxy Group) |
| Name | Name of the API Proxy or Proxy Group |
| Paths | Defined paths of the route |
| Hosts | Defined hosts of the route |
| Headers | Defined headers of the route (in name:value format) |
| Methods | HTTP methods supported by the route |
| Deployments | Deployed/Total environment count (e.g., 2/3) |
| Conflict | Conflict status of the route (No Conflict, Exact Match, Prefix Conflict) |
| Actions | View details button |
View Details
You can click the View Details button to view route details. The detail dialog shows the following information:
- Project name
- Type (API Proxy/Proxy Group)
- Name
- Paths
- Hosts
- Headers
- Methods
- Conflict status
- Environment name
- Access URL
- Deploy status
- Redeploy requirement
Information about other routes in conflict:
- Project name
- Type
- Name
- Path
- Conflict reason
Conflict Statuses
Routes can have three different conflict statuses:
The route has no conflicts with other routes. This route can be used safely.
The route's path, host, header, and method configuration exactly matches another route. This is a serious conflict.
The route's path conflicts with the prefix of another route's path. This situation may cause a potential problem.
Excel Export
The Route Conflicts sub-report carries its own Export button on its filter row, next to Clear Query and Search. Clicking it downloads the report built from the current filter criteria in ZIP format.
Excel export includes all results according to the current filtering criteria. Because the sub-report owns this action, the shared Export button on the Metrics page's filter row is hidden while the Conflicts tab is open. Route Trace has no Excel export; its result can be copied to the clipboard as JSON instead.
Sorting
You can sort the report table in ascending or descending order by Project, Type, and Name columns. You can click the column header to sort.
This report is designed to analyze all routes. All results are displayed without pagination.
Route Trace
The Route Trace sub-report asks every running worker pod, separately, which API Proxy would serve the request you describe.
The conflict report examines the stored configuration — it tells you what the routing table should look like. Route Trace looks at the worker's in-memory routing table — it tells you what the worker is actually doing. When the two disagree, the problem is not in the configuration but in the worker's memory, and that gap is invisible from either view alone.
No request is sent to the backend. The answer comes from the pod's in-memory routing table. No call reaches the backend service, and traffic logs, quota and rate limit counters are unaffected. It is therefore safe to run against a live environment.
Describing the Request
| Field | Description |
|---|---|
| Environments | Environments to probe. Leave empty to probe every published environment. |
| HTTP Method | The request's method. ALL is absent from the list: it is a configuration wildcard, not a method a client can send. |
| Path | The requested address. Must start with /. |
| Host | For host based routes. If left empty the host criterion is treated as empty — fill it in when testing routes that differ by host. |
| Headers | Name/value pairs for header based routes. The Add Host Header shortcut also sends the Host value as a header. |
| Body (SOAP) | Only needed for SOAP proxies, where the method name is resolved from the envelope. Leave empty for REST. |
Two further options are available:
- Include competing routes — lists the routes that lost the match and why each one was eliminated. When a request reaches the wrong proxy, the explanation is here.
- Run index consistency audit — scans the worker's in-memory route index. Enable it when a match looks impossible; it walks every category, so it is not free.
Reading the Result
The result leads with agreement across pods, not with the pod list. A gateway is only correct if every pod resolves a path to the same proxy; if it does not, the request succeeds or returns 404 depending on which pod the load balancer picked.
The routing table is consistent across pods. Configuration is what decides the outcome.
The same request resolves on some pods and not on others. From outside this looks like an intermittent 404.
The same request reaches different destinations depending on the pod. The workers' in-memory routing tables have drifted apart; configuration alone does not explain this.
The pods that answered agree, but at least one pod could not be reached. The state of that pod is unknown.
Below the agreement banner, pods that answered identically are collapsed into a single card; when pods disagree the smaller group is flagged separately — those are the pods to investigate. At the bottom sits the pod table as evidence. Expanding a row shows:
- How the request was read — the way the worker interpreted the path. Stripping the root context is a frequent source of surprise and is shown explicitly. If no category matched at all, that is stated too: the routing table holds nothing shaped like this request.
- Competing routes — the separate outcome of the host, header, URI and method rule for each one. The question mark beside an elimination reason means the reason was derived from the available route data rather than observed directly.
- Index findings — when the audit is enabled, the points at which the routing table is inconsistent with itself.
- Group members — when the match came through a Proxy Group, the members in the order the worker would consider them.
A pod reporting an error does not mean the whole report failed; the other pods may well have answered. The banner states how many pods responded.
A competing route listed as Matched but not reached deserves particular attention. It means the route matches and its category was searched, yet resolution did not find it — a combination that should not be possible, and one that points at the worker's in-memory index rather than at configuration. Index audit findings are likewise about the running worker's state rather than about configuration; in that case the affected worker may need to be restarted.
Results can be copied to the clipboard as JSON together with the request description. Header values are excluded from the copied content (header names are kept), so credentials such as Authorization or Cookie do not end up in a support ticket.