IIS结合ARR与URL Rewrite实现高效反向代理的实战指南

1. 为什么选择IIS做反向代理最近接手一个项目客户环境比较特殊——只有一台Windows Server云服务器跑着几个用.Net开发的系统。按照我往常的习惯肯定首选Nginx做反向代理但这次真的被现实打败了。Nginx官方文档明确写着不建议在生产环境使用Windows版本这行红字看得我头皮发麻。硬着头皮研究IIS方案时发现其实微软自家的ARRApplication Request Routing和URL Rewrite组合拳用顺手之后真香你可能好奇IIS反向代理和Nginx有什么区别实测下来最明显的差异是性能开销。Nginx确实更轻量但在纯Windows环境下IIS方案反而更稳定。特别是处理ASP.NET请求时省去了跨进程通信的开销。另一个隐藏优势是配置继承——所有规则都能直接写在web.config里和项目代码一起做版本控制部署时少踩很多坑。2. 环境准备与组件安装2.1 安装ARR组件微软的组件命名有时候真让人摸不着头脑。我翻遍IIS 10的管理界面愣是没找到反向代理的开关。后来才发现需要单独安装ARR模块官方下载页面藏得那叫一个深。建议直接收藏这个直达链接Application Request Routing下载页安装时有个细节要注意如果服务器已经运行着IIS安装完成后一定要重启World Wide Web Publishing服务。我有次偷懒没重启配置界面死活不显示ARR图标白白浪费半小时查问题。安装成功后在IIS管理器的首页会出现一个新的Application Request Routing Cache图标这就是我们的主力工具了。2.2 安装URL Rewrite模块光有ARR还不够就像有枪没子弹。URL重写功能需要额外安装URL Rewrite模块下载地址同样不太好找URL Rewrite下载页。这个模块安装比较简单但建议勾选导入示例规则选项里面自带的正则表达式模板能省不少事。验证安装是否成功有个小技巧随便打开一个站点的web.config文件如果能看到rewrite节点说明模块已经就绪。我习惯在开发机上先装好这两个组件把基本配置调通后再上生产环境避免在客户现场手忙脚乱。3. 配置ARR核心参数3.1 启用代理功能打开IIS管理器找到服务器节点注意不是站点节点双击Application Request Routing Cache图标。在右侧操作面板点击Server Proxy Settings这里有两个关键参数Enable proxy勾选这个复选框才能激活反向代理功能Proxy timeout建议设置为300秒以上特别是对接老旧系统时有个坑我踩过好几次修改完服务器级配置后必须点右上角的应用按钮单纯关窗口是不会保存设置的。曾经有次配置完死活不生效最后发现是忘了点这个按钮血泪教训啊3.2 连接数优化继续在ARR设置界面点击Cache选项卡。对于API网关场景建议关闭磁盘缓存Enable disk cache取消勾选内存缓存大小保持默认即可。重点调整Max connections per server参数这个值决定了到后端服务器的最大并发连接数。怎么确定合适的值呢我的经验公式是CPU核心数 × 100。比如4核服务器就设400但不要超过2000。曾经给一个高并发系统设成5000结果把后端服务打挂了监控发现TCP连接数暴增导致端口耗尽。4. 实战反向代理规则配置4.1 图形化配置方法现在来到最核心的部分配置具体的反向代理规则。以把api.example.com代理到内网192.168.1.100:8080为例在IIS中选中目标站点双击URL Rewrite图标点击右侧Add Rule(s)选择Reverse Proxy在弹出窗口填写Inbound rules:api.example.comRewrite URL:http://192.168.1.100:8080/{R:1}勾选Stop processing of subsequent rules这种配置方式适合快速验证但实际生产环境我更推荐直接编辑web.config因为可以版本化管理。图形界面生成的规则有时候会包含冗余参数手动精简后更清晰。4.2 手动编写web.config规则打开站点的web.config文件在system.webServer节点下添加如下配置rewrite rules rule nameAPI Proxy stopProcessingtrue match url^(.*) / conditions add input{HTTP_HOST} pattern^api.example.com$ / /conditions action typeRewrite urlhttp://192.168.1.100:8080/{R:1} / /rule /rules /rewrite这个配置比图形界面生成的更灵活可以添加多个条件判断。比如要实现根据URL路径分流到不同后端rule nameMulti-Backend Routing match url^(.*) / conditions logicalGroupingMatchAny add input{PATH_INFO} pattern^/order/(.*) / /conditions action typeRewrite urlhttp://order-service:8080/{R:1} / /rule5. 高级技巧与性能调优5.1 负载均衡配置ARR其实是个隐藏的负载均衡神器。假设你有三个订单服务实例可以这样配置在ARR界面点击Server Farms新建服务器组添加三个后端服务器地址在URL重写规则中将action的url改为http://订单服务集群/{R:1}实测下来ARR的加权轮询算法相当稳定。我给主备机房配置7:3的权重比流量分配误差不超过2%。有个小技巧在服务器属性里设置健康检查URLARR会自动屏蔽异常节点。5.2 响应内容重写有时候后端返回的链接需要替换域名这时候要用到出站规则。比如把后端返回的Location: http://internal/api/xxx改成公网域名outboundRules rule nameRewrite Location Header match serverVariableRESPONSE_Location pattern^http://internal(.*) / action typeRewrite valuehttp://api.example.com{R:1} / /rule /outboundRules这个功能在处理第三方系统对接时特别有用。有次对接一个老系统所有返回的JS/CSS路径都是内网地址用出站规则批量替换后完美解决。6. 常见问题排查指南6.1 代理请求失败分析遇到502错误时按这个顺序检查确认ARR的Enable proxy已勾选检查后端服务是否监听正确端口在失败请求跟踪日志里查看X-ARR-LOG-ID头在事件查看器中筛选Application Request Routing来源的日志有个特别隐蔽的坑如果后端是HTTPS服务必须安装服务器证书并配置serverVariablesrewrite allowedServerVariables add nameHTTPS / /allowedServerVariables /rewrite6.2 性能问题定位当发现延迟增高时可以在ARR设置中开启Failed Request Tracing调整Proxy timeout值为更大数值检查服务器内存是否不足ARR会缓存响应内容我遇到过一个典型案例某API突然变慢最后发现是有人上传大文件触发了磁盘缓存。关闭磁盘缓存后性能立即恢复正常。监控ARR的内存使用率很重要超过80%就要考虑扩容了。