为何先注册的自定义中间件被UseRewrite中间件优先执行？

核心结论 #

UseRewriter 本身没有强制插队到中间件队列最前端的特殊机制，你遇到的问题本质是重写规则的终止逻辑和中间件注册顺序共同导致的。

问题原因分析 #

1. 中间件执行顺序规则
   ASP.NET Core 中间件严格按照注册顺序处理请求：请求到达时，先执行先注册的中间件；响应返回时，反向执行。但如果某个中间件处理请求时终止了管道（比如调用重定向并结束响应），后续中间件就不会再执行请求阶段的逻辑。

2. URL重写规则的终止配置
   你的 url-rewrite.xml 中匹配 /vanity 的规则很可能设置了 stopProcessing="true" 属性。这个属性会让 RewriteMiddleware 在执行完该规则后，直接终止请求管道，不再将请求传递给后续注册的中间件——这就是你的自定义 VanityRedirectMiddleware 逻辑从未触发的直接原因。

3. RewriteMiddleware 的内部逻辑
   UseRewriter 注册的 RewriteMiddleware 会遍历所有配置的重写规则，找到第一个匹配的规则执行。如果规则带 stopProcessing="true"，它会立即停止后续规则的处理，同时也不会调用下一个中间件的 Invoke 方法。

解决方案 #

1. 修改重写规则的终止配置
   打开 url-rewrite.xml，找到匹配 /vanity 的规则，移除或设置 stopProcessing="false"。示例：

<rule name="Vanity Rule" stopProcessing="false">
  <match url="vanity" />
  <!-- 其他规则配置 -->
</rule>

这样 RewriteMiddleware 执行完该规则后，会继续将请求传递给你的自定义中间件。

2. 确认中间件注册顺序
   确保自定义中间件的注册在 UseRewriter 之前，保证请求先经过你的逻辑再进入重写处理：

// 先注册自定义中间件
app.UseMiddleware<VanityRedirectMiddleware>();
// 再注册重写中间件
var rewriteOptions = new RewriteOptions().AddIISUrlRewrite(env.ContentRootFileProvider, "url-rewrite.xml");
app.UseRewriter(rewriteOptions);

3. 自定义中间件优先拦截特定路径
   如果需要让自定义逻辑优先处理 /vanity 路径，可以在自定义中间件中主动判断路径，处理后终止管道，避免后续重写规则干扰：

public class VanityRedirectMiddleware
{
    private readonly RequestDelegate _next;

    public VanityRedirectMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (context.Request.Path.StartsWithSegments("/vanity"))
        {
            // 执行你的自定义重定向逻辑
            context.Response.Redirect("/target-url", permanent: true);
            return; // 终止管道，不再传递给后续中间件
        }

        // 其他路径交给后续中间件处理
        await _next(context);
    }
}

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