IIS请求不存在页面返回200而非404问题求助

这种情况确实挺让人摸不着头脑的，我给你梳理几个实际排查过的方向，应该能帮你找到问题根源：

• 检查URL重写或路由规则
  先看看IIS里有没有配置URL重写模块的规则——说不定有规则把proxy.ashx的请求偷偷转发到了其他处理程序，哪怕你把文件改名了，规则还在生效。打开IIS管理器找到你的站点，点击“URL重写”查看规则列表，有没有匹配proxy.ashx的条目。
  如果你的站点用了ASP.NET路由（比如MVC或Web Forms），还要检查RouteConfig.cs这类配置文件，有没有自定义路由把包含proxy.ashx的请求映射到了某个后台逻辑，而不是依赖物理文件存在与否。

• 排查处理程序映射
  IIS的处理程序映射经常会导致这类“幽灵请求”问题。去站点的“处理程序映射”里搜搜.ashx或者proxy相关的条目：

  • 有没有针对.ashx的通配符映射？哪怕物理文件不存在，IIS也会调用对应的处理程序返回响应。
  • 有没有专门匹配proxy.ashx的自定义映射？这种情况即使文件改名，映射规则还会拦截请求。

• 排除缓存或中间代理影响
  别忽略缓存的可能性！试试这些操作：

  • 用Postman或curl发起请求时勾选“禁用缓存”选项，或者清空本地浏览器缓存后再测试。
  • 如果服务器前面有反向代理（比如ARR、Nginx）或者CDN，检查这些中间层的缓存规则，是不是把proxy.ashx的200响应缓存下来了，导致请求根本没到你的IIS服务器。

• 深挖IIS日志和失败请求跟踪
  既然IIS日志记录了200请求，那就把日志里的细节拉出来看：重点关注cs-host（确认请求的是正确站点）、cs-uri-stem、sc-substatus（200的子状态码）、time-taken和sc-bytes，判断是不是真的IIS在处理请求。
  更有效的方法是开启失败请求跟踪：针对200状态码配置跟踪规则，这样能看到请求在IIS内部的完整处理流程——到底是哪个模块接了请求、返回了空内容，一目了然。

• 检查应用程序池状态
  有时候应用程序池异常也会导致奇怪的响应：

  • 先重启对应的应用程序池，甚至重启整个IIS服务，看问题是否消失。
  • 检查应用程序池的“托管管道模式”，经典模式和集成模式下，处理程序的行为差异很大，说不定是模式配置导致的。

• 创建空白测试站点验证
  在同一个IIS服务器上新建一个空白站点，只放一个简单的test.ashx文件，测试请求它后返回正常响应，然后把文件改名再请求。如果新站点能正常返回404，说明问题出在原站点的某个配置上，而不是IIS全局的问题。

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