How to set up an IIS Reverse Proxy Server

Short answer

Yes, IIS can work as a reverse proxy on modern Windows Server releases when you combine IIS, URL Rewrite, and Application Request Routing. The screenshots in this walkthrough use Windows Server 2019, but the same pattern applies to newer releases such as Windows Server 2022 and Windows Server 2025 when those IIS components are installed. This setup lets IIS receive public traffic and forward it to another website or application server behind it. Do not treat IIS reverse proxy as a security layer by itself. It gives you a controlled front door. You still need TLS, firewall rules, logging, header handling, and a plan for the backend app. For many legacy systems, that front door is the first practical step. Use case Is IIS a good fit? Notes Put a legacy Windows app behind a public endpoint Yes IIS fits well when the app already lives in a Windows environment. Route traffic from one domain to another backend Yes URL Rewrite can preserve paths and forward requests. Centralize TLS in front of an older app Yes Install and manage the certificate on the IIS proxy. Replace a full API gateway No IIS can proxy traffic, but it is not a full traffic management platform. Handle complex cloud native routing Usually no NGINX, Azure Application Gateway, Cloudflare, or a dedicated load balancer may be a better fit. If you are stabilizing aging web infrastructure or planning a larger platform refresh, Tevpro's legacy modernization services can help you decide whether a reverse proxy is enough or whether the application itself needs a deeper modernization plan.

What is an IIS reverse proxy?

An IIS reverse proxy is a Windows Server running IIS that accepts requests from users and forwards those requests to another server. The user connects to the proxy. The proxy forwards the request to the backend. For example, a user may visit:

https://azure-test.tevpro.com/blog

IIS can receive that request and forward it to:

https://tevpro.com/blog

To the user, the request still appears to go through the reverse proxy domain. IIS passes the request to the origin site while the browser stays on the proxy hostname.

Prerequisites

This walkthrough assumes you already have a Windows Server available. We used Windows Server 2019 with IIS 10 for the original screenshots, but the same IIS reverse proxy pattern also applies to newer Windows Server releases, including Windows Server 2022 and Windows Server 2025, as long as IIS, URL Rewrite, and Application Request Routing are available. Requirement Why you need it Windows Server 2019 or newer Hosts IIS and receives public traffic. Newer Windows Server versions can use the same IIS reverse proxy pattern. IIS installed Provides the web server layer. URL Rewrite Creates the inbound rewrite rule. Application Request Routing Enables proxy behavior in IIS. DNS access Points your proxy hostname to the Windows Server. TLS certificate Allows the proxy endpoint to serve HTTPS traffic. Backend application URL The origin site or app IIS will forward traffic to. If you still need to create the Windows VM, Microsoft has a good Azure Windows VM quickstart. This article focuses on the IIS reverse proxy configuration after the server exists.

Step 1: Install IIS

If IIS is not installed yet, install it from Server Manager or PowerShell. This PowerShell command installs the web server role and the management tools:

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

After the install finishes, open IIS Manager and confirm the server appears in the left navigation pane.

Step 2: Install URL Rewrite and Application Request Routing

IIS needs two Microsoft extensions for this reverse proxy pattern:

• URL Rewrite, which creates inbound rules and rewrites request paths.
• Application Request Routing, often called ARR, which allows IIS to proxy requests to another server.

Install both extensions on the server that will act as the reverse proxy. After installation, reopen IIS Manager if it was already open.

Step 3: Enable proxy support in ARR

URL Rewrite handles the rule, but ARR handles the proxy behavior. Without ARR proxy support, the rule may rewrite locally instead of forwarding traffic the way you expect.

1. Open IIS Manager.
2. Select the server node, not just a single website.
3. Open Application Request Routing Cache.
4. Click Server Proxy Settings.
5. Check Enable proxy.
6. Click Apply.

This step is easy to miss. If the rule looks right but IIS refuses to proxy traffic, check ARR before changing the rewrite pattern.

Step 4: Create the IIS website for the proxy

Next, create a website in IIS for the public proxy endpoint. In the original example, we used a subdomain like azure-test.tevpro.com.

1. In IIS Manager, right click Sites.
2. Choose Add Website.
3. Enter a site name.
4. Choose a physical path. This can be a simple folder because the site mainly exists to receive and forward requests.
5. Set the binding. For production, use HTTPS with the correct hostname and certificate.
6. Click OK.

After the website is created, select it in IIS Manager. You should see URL Rewrite in the feature list if the extension was installed correctly.

Step 5: Create the URL Rewrite rule

Now create the rule that forwards incoming traffic to the backend site.

1. Open the new proxy website in IIS Manager.
2. Double click URL Rewrite.
3. Click Add Rule(s) in the Actions panel.
4. Choose Blank rule under inbound rules.
5. Click OK.

For a basic reverse proxy, use a catch-all pattern so the proxy forwards the requested path to the backend site. Setting Value Name Reverse proxy to origin Requested URL Matches the Pattern Using Regular Expressions Pattern (.*) Action type Rewrite Rewrite URL https://tevpro.com/{R:1} Append query string Checked That rule captures the path after the proxy domain and forwards it to the same path on the backend site.

<rule name="Reverse proxy to origin" stopProcessing="true">
  <match url="(.*)" />
  <action type="Rewrite" url="https://tevpro.com/{R:1}" appendQueryString="true" />
</rule>

You can use the Test pattern button to confirm the rule captures the path you expect. For example, a request to /blog should be captured and passed into the rewrite URL.

Step 6: Test the reverse proxy

After you apply the rule, test the proxy from a browser and from the command line. In a browser, open the proxy hostname and a few deeper paths:

https://azure-test.tevpro.com/
https://azure-test.tevpro.com/blog

The content should load from the backend site while the browser stays on the proxy hostname.

From PowerShell, you can check the response status:

Invoke-WebRequest -Uri "https://azure-test.tevpro.com/blog" -UseBasicParsing

For a production proxy, test more than the home page. Check static assets, login pages, API routes, redirects, and large uploads. Reverse proxy issues often show up first in less common paths.

Production hardening checklist

A basic proxy rule is enough for a demo. Production needs more care. Area What to check TLS Install a valid certificate and redirect HTTP to HTTPS. Firewall Allow public traffic only to the proxy. Restrict backend access where possible. Headers Make sure the backend can understand forwarded host and protocol headers. Logging Log proxy traffic and backend traffic so you can trace failures. Timeouts Set reasonable proxy and backend timeout values. Request size Check upload limits if the app accepts files. Authentication Confirm login, cookies, redirects, and callback URLs still work through the proxy. Health checks Have a simple way to know whether the backend app is reachable.

Common IIS reverse proxy problems

Problem Likely cause Fix 502 Bad Gateway IIS cannot reach the backend server. Check DNS, firewall rules, backend status, and TLS trust. Redirect loop The backend thinks the request is HTTP or the wrong host. Review HTTPS redirects and forwarded protocol handling. Static files fail The rule does not preserve paths correctly. Test the rewrite pattern and confirm asset URLs resolve. Login breaks Cookie domain, callback URL, or host header mismatch. Check authentication settings and the public hostname used by the app. Client IP is missing The backend only sees the proxy IP. Configure and log forwarded client IP headers where your stack supports them.

When IIS reverse proxy is enough

IIS reverse proxy is often enough when the goal is practical containment: put a stable HTTPS endpoint in front of an older app, route a subdomain to a backend service, or buy time during a migration. It is usually not enough when the application has deeper problems. If the app cannot handle modern authentication, depends on fragile server state, has no deployment path, or fails under normal traffic, a proxy will only hide part of the problem. It may still be the right first move, but it should not be the whole plan.