如何在IIS中配置请求重路由至其他节点？含ARR方案咨询

咱们先把问题根源捋清楚：你的轮询负载均衡会随机把请求分发到两台节点，但Node1只运行Service2的应用池，Node2只运行Service1的应用池——这就导致当LB把Service1的请求打到Node1时，因为AppPool1是停止状态，直接返回503错误；同理Service2请求打到Node2也会失败，这就是你看到的间歇性失败的核心原因。

既然没法操作负载均衡器，咱们可以在两台Windows节点上用ARR（Application Request Routing）+ URL重写模块来做请求的本地路由，把请求转发到运行对应服务的节点上，完全透明处理，用户感知不到。

准备工作 #

首先在两台节点上都安装必要组件：

• 安装URL重写模块（IIS官方扩展，可通过Web平台安装器或微软官网下载）
• 安装ARR 3.0（Application Request Routing，是URL重写的扩展工具，专门用于反向代理和请求路由，同样通过Web平台安装器搜索安装）
• 确保两台节点能互相访问对方的服务：比如Node1能访问http://Node2/Service1，Node2能访问http://Node1/Service2（先测试连通性，避免网络或权限阻碍）
• 在IIS服务器级别，打开Application Request Routing Cache面板，点击左侧的「服务器代理设置」，勾选「启用代理」并保存——这是ARR能实现反向代理的前提配置。

针对Node1的配置（仅运行Service2） #

1. 打开IIS管理器，选中「默认网站」，进入「URL重写」功能
2. 创建第一个反向代理规则，把Service1的请求转发到Node2：
   • 右键点击「规则」→「添加规则」→选择「反向代理」
   • 规则名称：Route Service1 to Node2
   • 匹配URL：选择「正则表达式」，输入模式^Service1/(.*)（匹配所有以Service1开头的请求路径）
   • 操作设置：目标地址填写http://Node2/Service1/{R:1}（{R:1}用来保留请求的后续路径，比如Service1/api/get会转发到Node2/Service1/api/get）
   • 如果你的LB用的是HTTPS访问，记得勾选「启用SSL offloading」，避免证书校验问题
3. Service2的请求无需额外配置——Node1的AppPool2处于运行状态，默认会处理本地的Service2请求。

针对Node2的配置（仅运行Service1） #

1. 同样进入默认网站的「URL重写」功能
2. 创建反向代理规则，把Service2的请求转发到Node1：
   • 规则名称：Route Service2 to Node1
   • 匹配URL：正则表达式模式^Service2/(.*)
   • 操作设置：目标地址填写http://Node1/Service2/{R:1}，根据LB的协议情况勾选SSL offloading
3. Service1的请求会由Node2本地运行的AppPool1处理，无需额外规则。

验证效果 #

配置完成后，测试访问https://LBDomainEntry/Service1和https://LBDomainEntry/Service2：

• 不管LB把请求发到Node1还是Node2，都会被自动路由到运行对应服务的节点，再也不会出现间歇性的503失败
• 可以查看IIS的访问日志确认转发情况，或者开启**失败请求跟踪（FRT）**排查可能的异常

替代方案（若暂不使用ARR） #

如果暂时没法安装ARR，也可以用URL重写模块做302重定向，但用户体验不如反向代理：

• 在Node1上创建重写规则，匹配^Service1/(.*)，操作设置为「重定向」到https://LBDomainEntry/Service1/{R:1}，但这种方式会触发浏览器跳转，且存在LB再次把请求发到原节点导致循环的风险——所以ARR的反向代理方案是更可靠的选择。

内容的提问来源于stack exchange，提问作者user2618875