1. 为什么生产环境需要IIS反向代理?
在真实的线上业务场景中,IIS反向代理的部署往往源于三个典型需求:首先是对外隐藏真实服务器拓扑,比如将Java应用服务器伪装成IIS服务以降低被针对性攻击的风险;其次是解决跨域访问限制,特别是当前端页面需要聚合多个后端服务的API时;最后是作为负载均衡的前置层,配合ARR(Application Request Routing)模块实现流量分发。
我曾在金融行业项目中遇到一个典型案例:客户要求将Spring Boot应用通过IIS暴露,同时要兼容老版本.NET应用的URL规则。通过反向代理的URL重写规则,我们成功将/legacy/api路由到.NET服务器,而/modern/api则指向Java服务,这种无缝集成正是反向代理的核心价值。
2. 生产环境部署前的关键准备
2.1 服务器角色与功能安装
在Windows Server 2019上执行以下PowerShell命令安装必要组件:
powershell复制Install-WindowsFeature Web-Proxy, Web-URL-Auth, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, Web-Mgmt-Compat
特别注意:如果遇到"找不到源文件"错误,需通过-Source参数指定安装源路径,例如:
powershell复制Install-WindowsFeature Web-Proxy -Source D:\sources\sxs
2.2 ARR与URL重写模块安装
从微软官方下载以下两个MSI包:
- Application Request Routing 3.0
- URL Rewrite 2.1
安装后需在IIS管理器中启用代理功能:
- 打开ARR服务器代理设置
- 勾选"启用代理"
- 将代理模式改为"反向代理"
重要提示:生产环境务必禁用"正向代理"选项,否则服务器可能被滥用为开放代理。
3. 实战配置反向代理规则
3.1 基础反向代理配置
在web.config中添加如下规则,将/api路径代理到后端服务:
xml复制<rule name="ReverseProxy" stopProcessing="true">
<match url="^api/(.*)" />
<action type="Rewrite" url="http://backend-server:8080/{R:1}" />
<serverVariables>
<set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />
</serverVariables>
</rule>
关键参数说明:
^api/(.*)使用正则匹配以api开头的路径{R:1}捕获组引用,保留原始URL的路径部分HTTP_X_ORIGINAL_HOST向后端传递原始主机头
3.2 生产环境高级配置技巧
3.2.1 连接池优化
在应用程序池高级设置中调整:
- 队列长度从默认1000改为2000
- 启动模式改为"AlwaysRunning"
- 禁用重叠回收(避免请求中断)
3.2.2 缓冲区调优
通过PowerShell修改注册表:
powershell复制Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" -Name "UriEnableCache" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" -Name "UriMaxUriBytes" -Value 32768
4. 生产环境疑难问题排查
4.1 证书验证失败问题
当出现"远程证书无效"错误时,检查步骤:
- 在规则中添加条件:
xml复制<conditions>
<add input="{HTTP_HOST}" pattern="^yourdomain\.com$" />
</conditions>
- 设置代理保留主机头:
xml复制<action type="Rewrite" url="https://backend/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
4.2 大文件传输416错误
解决Requested Range Not Satisfiable错误:
- 修改web.config的
<requestFiltering>节点:
xml复制<requestFiltering>
<requestLimits maxAllowedContentLength="4294967295" />
<verbs allowUnlisted="true">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
</verbs>
</requestFiltering>
- 调整IIS的maxAllowedContentLength值
5. 安全加固与性能监控
5.1 安全防护配置
禁用危险HTTP方法:
xml复制<security>
<requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
</verbs>
</requestFiltering>
</security>
防范短文件名漏洞:
powershell复制Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "NtfsDisable8dot3NameCreation" -Value 1
5.2 性能监控方案
使用PerfMon监控关键计数器:
- ASP.NET Applications\Requests/Sec
- Web Service\Current Connections
- Memory\Available MBytes
创建自定义性能警报:
powershell复制New-CounterAlert -Name "HighProxyQueue" -Counter "\ASP.NET Applications\Requests Queued" -Threshold 1000 -SampleInterval 60
6. 高可用架构设计
对于关键业务系统,建议采用以下架构:
- 部署至少两台IIS反向代理服务器
- 使用NLB(网络负载均衡)分发流量
- 配置ARR服务器组实现后端健康检查
- 设置0-100-0的渐进式流量切换策略
配置示例:
xml复制<webFarm name="BackendFarm" enabled="true">
<server address="backend1" enabled="true">
<applicationRequestRouting>
<healthCheck url="http://backend1/health" interval="00:00:05" responseMatch="OK" />
</applicationRequestRouting>
</server>
<applicationRequestRouting>
<loadBalancing algorithm="WeightedRoundRobin" />
</applicationRequestRouting>
</webFarm>
在实际运维中,我们发现ARR的健康检查机制有个隐蔽缺陷:当后端返回404但服务实际可用时,会导致误判。解决方案是在健康检查接口中始终返回200状态码,而在响应体中包含实际健康状态。
