Isso é possível no IIS usando os plug-ins suportados ARR e URLrewrite. Eles são instalados como ferramentas integradas na GUI do Gerenciador do IIS.
Se você instalar o pacote ARR mais recente, receberá o URLrewrite incluído. A documentação on-line está faltando um pouco, mas com um pouco de ajustes o que você quer fazer é realizável sem muito trabalho.
Mesmo que o gui seja bastante amigável, minha sugestão é que você salve regularmente o seu applicationHost.config durante o teste, já que o gui ocasionalmente fica fora do padrão. Isso é verdade, pelo menos, com ARR v2.5, que foi o que usei ao fazer isso. Então você tem configurações de texto de trabalho que você pode copiar / colar de cada vez que você decide limpar sua configuração. Isso economizará muito tempo.
No applicationHost.Config procure especialmente por esses elementos XML:
<rewrite>
...
</rewrite>
<webFarms>
...
</webFarms>
A seção webfarms é onde seus locais de conteúdo definidos no gui acabam, é essencialmente configuração para um balanceador de carga de proxy reverso, em que um farm é uma conexão de serviço virtual para um ou mais nós de back-end. Da mesma forma, a seção de reescrita é onde você encontra suas condições para o qual o conteúdo deve ser buscado em qual farm.
Aqui segue-se um trecho de configuração real que não corresponde totalmente ao seu caso de uso, mas que pode servir como inspiração independentemente. Possivelmente, você só precisa editar a segunda regra de reescrita para corresponder ao seu cenário. O caso de uso apresentado é para quando o IIS é usado como um proxy de passagem para dois farms de back-end, o conteúdo dinâmico é servido a partir do "htmlFarm", enquanto solicitações de conteúdo estático predefinido, como imagens do "imageFarm". A seleção é feita com base no início do URI. Se o URI começar com / images /, ele será considerado como conteúdo estático e roteado para "imageFarm", caso contrário, ele será roteado para "htmlFarm". Em ambos os casos, o IIS está se apresentando ao cliente como o único servidor da web. Uma verificação de integridade simples também é feita de duas maneiras diferentes, uma para cada farm. Isso foi apenas por meio de experiência e eu apenas incluí-lo como ruído residual que, no entanto, poderia ser útil para você.
<rewrite>
<globalRules>
<clear />
<rule name="Route all to htmlFarm" patternSyntax="ECMAScript">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="(.*\.)?site01.com" />
</conditions>
<action type="Rewrite" url="http://htmlFarm/{R:0}" />
</rule>
<rule name="Route /images/* to imageFarm" stopProcessing="false">
<match url="images/.*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="http://imageFarm/{R:0}" />
</rule>
</globalRules>
</rewrite>
....
<webFarms>
<webFarm name="htmlFarm" enabled="true">
<server address="192.168.50.77" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<server address="192.168.50.78" enabled="true" />
<applicationRequestRouting>
<loadBalancing algorithm="WeightedRoundRobin" />
<healthCheck url="http://site01.com" responseMatch="Testing" />
</applicationRequestRouting>
</webFarm>
<webFarm name="imageFarm" enabled="true">
<server address="192.168.50.81" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<server address="192.168.50.82" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<applicationRequestRouting>
<healthCheck url="http://site01.com/images/test.txt" responseMatch="WillTest" />
<loadBalancing algorithm="WeightedRoundRobin" />
</applicationRequestRouting>
</webFarm>
<applicationRequestRouting>
<hostAffinityProviderList>
<add name="Microsoft.Web.Arr.HostNameRoundRobin" />
<add name="Microsoft.Web.Arr.HostNameMemory" />
</hostAffinityProviderList>
</applicationRequestRouting>
</webFarms>
Novamente, não em seu caso de uso, mas ainda assim: uma limitação na ARR é que, embora um nó do IIS com ARR possa fornecer redundância para o back-end, ele será um ponto único de falha. Você precisa de dois ou mais nós do IIS / ARR configurados de forma idêntica com o NLB ou um balanceador de carga separado na frente para superar isso. Web-fronts-as-usual em outras palavras: -)
Em última análise, abandonamos o IIS / ARR para o Apache, mas mais por meio de um acidente político que causou um grande surto de humor no escritório. Eu realmente não agradeço nem acima do outro como eu acho que ambos funcionam e funcionam muito bem. O monitoramento no Apache, no entanto, é péssimo em comparação direta com o IIS, e de forma alguma desejo que esse comentário seja uma chama para qualquer coisa. É apenas minha experiência direta com respeito a outras opiniões possivelmente diferentes sobre o assunto.
Boa sorte!