打开IIS管理器，何配点中你的置il重则站点，右侧功能视图里找到“URL Rewrite”图标——如果没看到这个图标，写规说明模块根本没装。何配去微软官网搜“URL Rewrite Module 2.0”，置il重则下载对应版本（x64还是写规x86看系统），装完重启IIS管理器。何配这一步卡住过不少人，置il重则装完不重启，写规图标死活不出来。何配

装好之后，置il重则双击进入URL Rewrite面板，写规右侧操作栏点“Add Rule(s)”。何配空白规则、置il重则反向代理、写规请求阻止这几类模板摆在那儿。我一般直接选“Blank rule”，手动写匹配逻辑更可控。取个名字，比如“remove-index-php”，别用中文，IIS对中文规则名偶尔抽风。

匹配模式填 ^index\.php/(.*)，这是正则。勾选“Ignore case”，忽略大小写。下面的“Action”区域选“Rewrite”，重写目标写 / { R:1}。R:1 是反向引用，把第一个括号里捕获的内容原样拼到根路径后面。举个例子，访问 example.com/index.php/about，会被内部重写成 example.com/about，浏览器地址栏不变，但IIS内部已经换了处理路径。

很多人栽在正则转义上。点号要写成 \.，斜杠不用转义。测试时别急着上生产，规则列表里有个“Test pattern”按钮，输入一个真实URL，看捕获组对不对。我见过有人写 ^index.php(.*) 结果把 index.phpfoo 也匹配进去了，少了那个反斜杠，事故就来了。

条件（Conditions）那块别忽略。默认有个 { HTTPS} 不等于 off 的条件，意思是只对HTTPS请求生效。如果你站点同时跑HTTP和HTTPS，这个条件会让HTTP请求绕过规则。删掉它，或者改成匹配 { HTTP_HOST} 包含特定域名。我自己的博客就吃过亏——HTTP下重写死活不触发，查了半小时才发现是这个默认条件在作祟。

规则写完后，别点“Apply”就完事。左侧树形菜单点回站点根，右侧“URL Rewrite”里能看到规则列表。双击进去还能微调。真正生效需要刷新浏览器缓存，或者用无痕窗口测。有时候IIS工作进程缓存了旧规则，iisreset 命令重启一下最稳妥。

举个实际场景。WordPress站点想隐藏 index.php，规则这样写：匹配模式 ^index\.php$，条件加一条 { REQUEST_URI} 不匹配 ^/index\.php，动作选“Redirect”301跳转到 /。注意这里用Redirect而不是Rewrite，因为要改变浏览器地址。Rewrite是内部重写，Redirect是外部跳转，搞混了会出重定向循环。

调试阶段打开失败请求跟踪。IIS管理器里点站点，右侧“Failed Request Tracing”启用，添加一个跟踪规则，状态码填200-999。然后访问一个URL，去 %SystemDrive%\inetpub\logs\FailedReqLogFiles 看生成的XML。里面会告诉你规则是否匹配、条件是否通过、重写后的URL是什么。这个工具比瞎猜快十倍。

最后说个坑。URL Rewrite模块和ARR（Application Request Routing）经常一起用。如果你要做反向代理到Node.js或Tomcat，先装ARR，再在URL Rewrite里建反向代理规则。代理规则里的“Server variables”要手动加 HTTP_X_FORWARDED_PROTO 之类的头，否则后端拿不到原始协议。我见过有人代理后CSS加载失败，就是因为后端以为请求是HTTP，实际前端是HTTPS，混合内容被浏览器拦了。

规则文件存在站点根目录的 web.config 里。别直接手改这个文件，IIS管理器界面操作会自动生成XML。手改容易把 <rewrite> 节点放错位置——它必须在 <system.webServer> 下面，放 <system.web> 里IIS根本不认。