I have an IIS server using Application Request Routing as a reverse proxy to an application running on another machine. I need to redirect one public path and pass the rest of the requests through to the backend.
I’m unsure where to put the URL Rewrite rules and how their order interacts with the ARR proxy rule. Does IIS evaluate the rules in a predictable order, and is there a reliable way to tell whether a request was redirected locally or forwarded upstream?
I’m looking for a configuration approach that won’t accidentally send the redirect back through the proxy.
For a typical IIS reverse-proxy setup, inbound URL Rewrite rules run before ARR forwards the request. The rule rewrites the incoming URL to the backend address, and ARR then proxies the request to that rewritten destination URL.
So, if your inbound rewrite rules point to an application server, ARR uses that target for the proxy request. On the response path, outbound rewrite rules can modify content coming back from the backend before IIS sends it to the client.
If proxying does not happen as expected, check that ARR proxying is enabled and that the rewrite rule’s pattern, conditions, and action target are correct.
Inbound URL Rewrite rules run before ARR forwards the request to the backend. Outbound rules run on the response after ARR receives it from the backend. So the answer depends on which direction you mean.
In a typical IIS reverse proxy configuration, the flow is:
/api/orderstohttp://backend:8080/api/orders. This is an internal rewrite, not a redirect sent to the browser.When you use an ARR server farm, a routing rule can rewrite the request to the farm name instead of a particular server. URL Rewrite selects the farm; ARR handles server selection and forwarding.
One distinction matters when debugging: rules on the proxy server and rules on the backend server run in separate IIS request pipelines. Backend rewrite rules run only after ARR has forwarded the request to that server. If you need to change the destination path or set a permitted request server variable before forwarding, put that logic in an inbound rule on the proxy, not in an outbound rule.