IIS 6 的 ARR 不是微软官方原生的东西。它是个外挂模块，全称 Application Request Routing，从 IIS 7 才开始正式支持。你要是手里还跑着 Windows Server 2003 那套 IIS 6，想用它做反向代理或者负载均衡，得先接受一个事实：这条路走不通，官方没给 IIS 6 做过 ARR。

但现实里偏有人这么干。我见过一个老系统，跑在 IIS 6 上，前端是一台 Windows Server 2003，后端挂着三台 Tomcat。运维那哥们儿硬是用 ISAPI_Rewrite 加自己写的 HTTP 模块拼了个类似 ARR 的东西出来。效果？凑合能用，但每次重启 IIS 都提心吊胆，怕哪个请求卡死把整个 w3wp.exe 拖垮。IIS 6 的架构摆在那儿——每个应用池独立进程，请求队列一满就 503，连个像样的健康检查都没有。ARR 在 IIS 7 上能做的探针、缓存、URL 重写规则，在 IIS 6 上全靠手搓。

为什么 IIS 6 扛不住 ARR 的活？核心问题在 HTTP.sys 和 WAS。IIS 6 的请求管道是线性的，ISAPI 扩展一旦阻塞，整个线程池跟着遭殃。ARR 需要异步转发请求、维护后端连接池、处理超时重试——这些在 IIS 7 的集成管道里是原生能力，在 IIS 6 上你得自己管线程同步，稍不留神就死锁。我试过用 IIS 6 的 ServerXMLHTTP 组件做转发，单线程测试没问题，一上并发就露馅，CPU 直接飙到 100%，响应时间从 50ms 跳到 3 秒。

那有没有人硬上？有。网上能搜到一些老帖子，教你在 IIS 6 里装个叫 “IIS 6 反向代理” 的第三方 ISAPI 过滤器，比如 Ionic 的 ISAPI_Rewrite 配合 mod_proxy 思路。实际部署时你得改 metabase，手动加通配符脚本映射，把 .dll 挂到网站根上。麻烦不说，调试基本靠猜——IIS 6 的日志格式老旧，ARR 那种详细的代理追踪信息想都别想。有一次我帮人排查 502 错误，翻了半天才发现是后端 Tomcat 的 keep-alive 超时设得太短，IIS 6 这边没做连接复用，每次请求都新建 TCP，硬生生把后端拖垮了。

换个角度想，如果现在还有人问 “IIS 6 怎么配 ARR”，我的回答很直接：别折腾。把系统升到 IIS 7.5 以上，装个官方 ARR 3.0，图形界面点几下就完事。IIS 6 的生命周期早就结束了，微软 2015 年就停止支持。你非要在上面跑反向代理，等于开着一辆没有 ABS 的老车上高速，能开，但出事是迟早的。

当然，有些内网环境动不了，机器老、系统老、升级窗口批不下来。那退而求其次，用 Nginx 做前端代理，IIS 6 只当静态文件服务器。Nginx 跑在 Windows 上虽然性能打折，但至少比 IIS 6 自己扛代理强。我见过一个案例，前端 Nginx 做负载均衡，后端三台 IIS 6 各自跑 ASP 应用，稳定跑了两年多。运维说：“别让 IIS 6 干它不擅长的事，它就是个老黄牛，耕好自己的地就行。”

所以 IIS 6 和 ARR 的关系，一句话：ARR 是 IIS 7 之后的产物，IIS 6 想用只能靠第三方拼凑，效果差、维护难、风险高。真要用 ARR，先升级 IIS。不升级，就换个思路，别硬来。

(责任编辑：综合)