Classic ASP环境下URL重写/重定向是否会变更ApplicationPool？

我来帮你拆解这个问题，结合IIS和http.sys的工作逻辑逐一说明：

1. URL内部重写不会改变应用池的选择 #

当你用IIS URL重写模块把www.myentrepreisename.com/myclientname1内部改写为新域名时，用户浏览器地址栏不会有变化——但应用池的选择早在重写之前就确定了。

http.sys作为Windows的HTTP内核驱动，会在请求到达IIS应用程序管道之前，就根据原始请求的主机头（Host）和URL路径匹配对应的站点绑定与应用池。原始请求的主机头是www.myentrepreisename.com，路径是/myclientname1，所以http.sys会直接把请求转发到原站点对应的原应用池，后续的内部重写只是在IIS内部修改了请求的路径信息，不会推翻已经确定的应用池分配。

这种情况下，请求还是会跑到原来的应用池里，达不到拆分资源的目的。

2. "应用池选择在http.sys中进行，原URL始终选原池"的说法完全属实 #

这个结论是对的。http.sys的核心职责之一就是请求路由：它监听所有进入的HTTP请求，根据站点绑定的主机名、端口、路径前缀，把请求转发到对应的IIS工作进程（即应用池）。这个路由决策是在请求进入应用程序逻辑之前就完成的，和后续的URL重写、ASP代码执行完全无关。

只要用户发起的原始请求还带着原主机头和路径，http.sys就会一直把请求送到原应用池，不管你在IIS内部怎么改写URL。

3. 重定向（3xx跳转）可以让请求进入正确的应用池 #

重定向和内部重写的本质区别在于：重定向会给浏览器返回一个3xx状态码（比如301永久重定向、302临时重定向），告诉浏览器"请访问新的URL"。浏览器收到后会发起一个全新的请求，此时请求的主机头变成myclientname1.myentreprisename.com，http.sys就会根据这个新的主机头匹配到你配置的对应站点，进而把请求送到myclientname1pool里。

这种方式虽然会让用户地址栏显示新域名，但确实能实现让请求进入目标应用池的需求。

额外建议：不想改变用户访问地址的替代方案 #

如果不想让用户看到域名变化，又要实现应用池拆分，可以考虑两种方案：

• 在原站点的/myclientname1路径下配置反向代理（用IIS ARR模块），把请求转发到新域名的站点。此时后端请求会进入新应用池，而用户看到的还是原地址——不过要注意Classic ASP的会话状态、身份验证等是否兼容反向代理场景。
• 直接把原站点下的/myclientname1设置为独立的应用程序，然后给它指定myclientname1pool。IIS支持单个站点下的不同应用使用不同应用池，这样不需要修改域名就能完成资源拆分。

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