IIS搭配iisnode使用URL Rewrite时PUT/DELETE请求404、URL未重写的问题

• 这不是iisnode本身的已知bug，拦截发生在IIS请求管线的最前置环节，和iisnode、URL重写的配置逻辑无关。请求根本没走到重写和iisnode的处理节点，所以会出现重写规则不生效、app.js完全没被调用的现象。
• 触发这类404的核心原因是IIS内置模块对HTTP谓词的默认拦截规则：
  • 请求筛选模块默认会拦截未显式允许的HTTP方法，这也是你调整后PUT请求能正常运行、但DELETE请求仍返回404的原因。
  • 服务器开启WebDAV发布功能时，WebDAV模块会优先拦截DELETE、PUT这类写操作请求，优先级高于URL重写和iisnode的处理逻辑。

• 在web.config的<system.webServer>节点下添加放开DELETE谓词的请求筛选规则：

  <security>
    <requestFiltering>
      <verbs applyToWebDAV="false">
        <add verb="DELETE" allowed="true" />
      </verbs>
    </requestFiltering>
  </security>
  

• 移除站点级别的WebDAV模块绑定，避免其提前截断DELETE请求：

  <modules>
    <remove name="WebDAVModule" />
  </modules>
  

• 校验iisnode处理程序的绑定权限：你当前配置里的verb="*"本身可以覆盖所有HTTP方法，需要确认站点没有其他上层处理程序规则覆盖iisnode配置——可在IIS管理器的「处理程序映射」界面查看iisnode对应规则的允许谓词列表，确认DELETE在允许范围内。
• 调整URL重写规则的执行顺序：你当前用通配符匹配的重写规则，必须排在所有静态文件处理规则之前，避免请求路径匹配到静态文件逻辑后，绕过Node应用的重写流程。

• 你目前用PUT做临时绕开的方案能生效，本质是PUT请求没有被前置拦截模块截断，顺利进入了iisnode处理管线。
• 配置调整完成后不需要重启iisnode进程，回收对应应用池、在IIS管理器中同步站点配置即可生效。

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