IIS7 WordPress伪静态规则配置指南，安全避坑选哪家好

找建站公司最怕什么？不是技术烂，而是拿着几千块的预算，最后花了两万五还觉得被割了韭菜。很多人搜“网站建设哪家好”，其实心里没底，因为不懂技术细节，只能听销售忽悠。今天咱们不聊虚的，直接拆解一个高频踩坑点：IIS7 WordPress伪静态规则。很多公司为了省事，直接给你套个通用模板，结果网站打不开，或者安全漏洞满天飞。搞清楚这个配置，你才能判断对方是专业搞站，还是混日子的皮包公司。

威胁场景：为什么伪静态配置不当是安全重灾区

很多市场人员觉得，伪静态不就是把 ?p=123 变成 /post-123/ 吗？看着挺高级，利于SEO，其实这里面藏着巨大的安全隐患。

我见过太多案例，公司上了IIS服务器，装了WordPress，默认规则没改对，或者干脆没改。结果呢？

目录遍历漏洞：如果IIS没有正确拦截非静态文件请求，攻击者可以直接访问 /wp-admin/、/xmlrpc.php 甚至 .htaccess 文件（虽然IIS不用这个，但原理类似，可以探测服务器信息）。
恶意脚本上传执行：配置错误导致某些可执行文件（如 .php、.asp）被解析为静态文本，或者反过来，静态文件被当成脚本执行。
信息泄露：错误的URL重写规则可能暴露服务器版本、数据库连接字符串路径等敏感信息。

举个真实案例：一家做外贸培训的公司，找了一家“便宜”的建站商。上线后流量不错，但三个月后后台被挂马。查日志发现，攻击者通过一个未正确重写的URL，直接访问了 /wp-includes/ 下的某个文件，结合弱口令，成功获取了后台权限。

为什么IIS7在这个环节特别容易出问题？因为IIS的URL重写模块（URL Rewrite Module）和Apache的 .htaccess 逻辑完全不同。很多建站公司是做Linux出身的，直接把Apache的规则硬套在IIS上，或者用了一些过时的、不兼容IIS7.5+的旧规则，导致安全防护形同虚设。

漏洞原理：IIS7与Apache规则的本质差异

要避坑，你得懂原理。IIS7默认不处理URL重写，必须安装 IIS URL Rewrite Module。

核心区别：

Apache：依赖 .htaccess 文件，规则是“匹配-替换”，逻辑相对直观。
IIS：依赖 web.config 文件，规则是基于XML的 <rule> 元素，使用正则表达式匹配 url 和 conditions，然后 action 重定向。

常见的错误配置导致的安全漏洞：

通配符滥用：有些规则写得过于宽泛，例如将 * 匹配所有请求，然后重定向到 index.php。这会导致静态资源（CSS/JS/图片）也被当成PHP请求处理，不仅性能差，还可能导致文件内容被篡改或注入。
未过滤敏感路径：规则中没有排除 /wp-admin/、/wp-login.php、/xmlrpc.php 等敏感路径。攻击者构造特殊URL，绕过前端验证，直接访问后端接口。
HTTP状态码错误：重定向时使用了 302（临时重定向）而不是 301（永久重定向），或者反过来。这会导致SEO权重分散，甚至被搜索引擎判定为异常行为。

对比示例（错误 vs 正确）：

错误配置（常见于劣质建站公司）：

<!-- web.config 片段 - 错误示例 -->
<rewrite><rules><rule name="Catch All" stopProcessing="true"><match url=".*" /><action type="Rewrite" url="index.php" /></rule></rules>
</rewrite>

解析：这个规则太“贪婪”了。它把包括 /wp-login.php、/style.css 在内的所有请求都重写到了 index.php。虽然WordPress内部会处理，但IIS层面的安全防护完全失效，攻击者可以更容易地探测服务器行为，且静态资源加载路径混乱，容易被中间人攻击篡改。

正确配置（安全且高效）：

<!-- web.config 片段 - 正确示例 -->
<rewrite><rules><!-- 规则1：处理WordPress核心结构 --><rule name="WordPress - Admin Area" stopProcessing="true"><match url="^wp-admin$" ignoreCase="false" /><action type="Rewrite" url="index.php" /></rule><!-- 规则2：排除静态文件，防止被重写 --><rule name="WordPress - Static Files" stopProcessing="true"><match url="^wp-content" ignoreCase="false" /><action type="None" /></rule><!-- 规则3：处理标准WordPress URL结构 --><rule name="WordPress" stopProcessing="true"><match url=".*" /><conditions><add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /><add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /></conditions><action type="Rewrite" url="index.php" /></rule></rules>
</rewrite>

解析：这个配置明确排除了 /wp-content 等静态目录，并且只有当请求既不是文件也不是目录时，才交给 index.php 处理。这样既保证了SEO友好的URL，又防止了静态资源被恶意重写，安全性大幅提升。

防护方案：手把手教你配置安全伪静态

既然知道了坑在哪，怎么自己验证建站公司的水平？或者如果你自己动手，该怎么配？

步骤1：安装 IIS URL Rewrite Module

确保你的IIS7服务器上安装了 URL Rewrite 2.0 或更高版本。如果没有，网站会直接报错 404。

步骤2：编辑 web.config 文件

找到你的网站根目录下的 web.config 文件。如果没有，创建一个。

步骤3：应用上述“正确配置”代码

将上面的XML代码插入到 <system.webServer> 节点内。

步骤4：验证与测试

访问一个正常的文章页面，看URL是否变成 /post-slug/。
访问 /wp-admin/，看是否能正常登录。
访问 /wp-content/themes/your-theme/style.css，看是否能正常加载样式。
关键测试：尝试访问 /wp-includes/class-wp.php，应该返回 403 或 404，而不是直接显示代码。

进阶安全加固：禁止访问敏感文件

在 <rewrite> 之前，添加以下规则，直接禁止访问 .php 源码文件（除了 index.php）和敏感配置文件：

<rules><rule name="Block sensitive files" stopProcessing="true"><match url="^(wp-config\.php|\.htaccess|web\.config|xmlrpc\.php)" /><action type="CustomResponse" statusCode="403" statusCodeReason="Forbidden" /></rule>
</rules>

注意：xmlrpc.php 是WordPress的一个重大安全隐患，很多攻击者利用它进行暴力破解。如果你的网站不需要使用XML-RPC接口，强烈建议直接禁用它。

检测与修复：如何快速判断网站是否被“坑”

如果你已经找了一家公司建好了站，怎么判断他们的伪静态配置是否靠谱？

方法1：查看源代码中的Link标签

打开任意一篇文章，按F12查看源代码，搜索 <link rel="canonical">。如果这里的URL是 ?p=123 格式，说明伪静态没生效，或者配置错误。

方法2：使用百度搜索资源平台检测

登录 百度搜索资源平台，使用“抓取诊断”功能。输入你的网站URL，看百度是否能正确抓取并识别你的页面结构。如果百度抓取的是带问号的URL，而前端显示的是伪静态URL，说明IIS重写规则有问题，导致搜索引擎和浏览器看到的URL不一致，这会严重影响SEO权重。

方法3：手动测试URL重写

在浏览器地址栏输入：

http://yoursite.com/non-existent-page/ -> 应该返回 WordPress 的 404 页面，而不是 IIS 的 404 或 500 错误。
http://yoursite.com/wp-admin/ -> 应该跳转到登录页。
http://yoursite.com/feed/ -> 应该返回 RSS 内容。

如果以上任何一项失败，说明配置有误。

修复建议：

如果发现问题，不要自己乱改 web.config。联系建站公司，要求他们提供完整的 web.config 备份，并对照上述“正确配置”代码进行修正。如果他们连 web.config 都搞不清楚，直接考虑换供应商，因为这说明他们的技术团队连基础服务器配置都不懂。