在Windows服务器上部署网站时，为了美化URL或实现路由分发，很多团队会在IIS中配置URL Rewrite模块。但配置完成后偶尔会遇到一个奇怪现象：HTML页面正常返回，浏览器却完全没有样式，控制台里样式表请求要么返回404，要么返回了HTML内容。这种IIS Rewrite规则导致样式表加载失败的问题，本质上大多是重写规则的作用范围没有合理约束，把本该直接送达静态文件处理器的CSS请求也卷进了重写流程。
理解IIS请求管线与Rewrite的执行时机
IIS处理一个HTTP请求时，会经过一系列有序的模块，URL Rewrite模块通常在身份验证之前或之后介入，具体取决于配置。当请求到达时，如果Rewrite规则匹配成功，URL会被内部重写到另一个路径，例如从 /product/123 重写到 /product.aspx?id=123。问题在于，许多初学者写规则时使用了过于宽泛的匹配模式，例如匹配所有不包含点的路径，却忘了样式表地址如 /css/style.css 虽然包含点，但某些正则写法仍可能误命中，或者被另一条通用规则拦截。
更常见的误区是，管理员为了省事，在根目录的 web.config 里放了一条捕获一切的规则：只要不是真实文件就重写到首页。这条逻辑在只做前端路由时看似合理，但IIS的 exists 判断依赖于静态文件模块是否已映射该扩展名。若CSS所在目录权限异常或MIME类型未注册，IIS会认为文件不存在，于是Rewrite将其转交动态页，动态页返回HTML，浏览器拿到text/html却当作CSS解析，自然样式全无。因此排查时必须先弄明白规则究竟在什么阶段、以什么条件触发。
我们可以通过失败请求跟踪（Failed Request Tracing）来观察重写模块到底改写了哪些URL。开启后能看到 RewriteModule 的日志，确认 /css/style.css 是否出现在重写列表中。如果确实被重写，就说明规则条件需要立刻调整。这一步不需要改代码，只需看清管线行为，就能避免盲目猜测。
通过条件排除保护静态样式资源
最稳妥的写法是在Rewrite规则中加入条件，明确跳过已有物理文件或特定扩展名。IIS Rewrite支持 {REQUEST_FILENAME} 和 {HTTP_URL} 等服务器变量，利用它们可以判断请求是否指向真实静态文件。例如下面这段配置，只有当请求的文件不存在时才重写，样式表只要物理存在就不会被卷入。
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="RouteToIndex" stopProcessing="true">
<match url="^.*$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.aspx" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
另一种做法是按扩展名白名单排除。比如明确声明如果URL以 .css、.js、.png 结尾就停止处理。这种写法在规则较多时更直观，也能防止未来新增的动态规则误伤静态目录。需要注意的是，stopProcessing 属性非常关键，它告诉IIS匹配到该规则后不要再执行后续规则，减少不必要的开销。
如果站点采用了前后端分离，静态资源由独立域名或CDN提供，那么IIS侧甚至不需要为这些资源写任何规则。但若是同域部署，务必在测试环境用curl模拟请求，观察响应头中的 Content-Type 是否为 text/css。若变成了 text/html，则证明排除条件没有生效，需要回头检查条件拼写或规则顺序。
排查MIME类型与目录权限的隐性陷阱
即便Rewrite规则已经正确跳过CSS，依然可能加载失败，这时要怀疑IIS是否真的能处理 .css 扩展名。在较老的IIS版本或精简安装中，CSS的MIME类型可能未被注册，服务器会返回404.3或者将其当作未知类型拒绝。此时浏览器请求样式表会直接失败，与Rewrite无关，但容易被误认成规则问题。可在IIS管理器的MIME类型中添加 .css 对应 text/css 来修复。
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".css" mimeType="text/css" />
</staticContent>
</system.webServer>
</configuration>
目录权限也是隐性杀手。IIS进程账户（如 IUSR 或 ApplicationPoolIdentity）需要对样式表所在目录有读取权限。若权限不足，静态文件模块同样会报404，而重写规则中的文件存在性判断也可能受影响。建议用浏览器无缓存刷新，并结合服务器上的失败请求日志，确认是重写层还是静态文件层抛出的错误。
最后，当使用了集成管线模式时，托管代码里的 HttpModule 也可能干扰静态文件。如果自己在程序里注册了捕获所有请求的处理器，而没有调用 HttpContext.Current.RewritePath 的跳过逻辑，同样会造成CSS失效。此时应在 web.config 的 modules 节点中，将静态文件相关扩展名从托管模块中移除，或设置 preCondition="managedHandler" 限定模块只对托管请求生效。综合重写规则、MIME与权限三方面，才能彻底解决IIS Rewrite导致样式表加载失败的问题。
IIS_Rewrite样式表加载CSS失效修改时间：2026-08-18 15:40:35