YARP 反向代理入门：从 API 到前端页面

在开始这个实验之前，我先创建了两个简单的后端，都只添加了一个路由映射

work业务api-地址:https://localhost:7011

app.MapGet("/work", () =>
{
    return "Work Api Success";
});

user业务api-地址:https://localhost:7076

app.MapGet("/user", () =>
{
    return "User Api Success";
});

我们先直接运行访问这个后端：

运行截图：

这种方式，都带了业务API的具体端口（实际上是IP+端口，因为本地所以只变化了端口，下一期，我们上vps）。虽然这样可以正常访问接口，但客户端必须知道具体的服务地址和端口。当系统中的服务越来越多时，客户端需要维护大量地址信息，不利于统一管理。

因此通常会引入反向代理或网关作为统一入口，对后端服务进行隐藏和转发。而 YARP 还可以做为网关，做负载均衡、速率限制、身份验证和授权等等。

而我们要说的这个YARP就可以帮我们做反向代理，我们先安装Yarp.ReverseProxy这个包。

修改一下网关的端口：我这里改成了80，注意本地，需要使用管理员权限打开编辑器才能正常使用，还需要注意80端口有没有被占用

"profiles": {
  "http": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "launchUrl": "swagger",
    "applicationUrl": "http://localhost:80",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development"
    }
  },

然后在program中注册这个服务：

// 注册反向代理服务到DI容器 2026-6-16
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

//管道中间件注册
app.MapReverseProxy();

配置文件：

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "ReverseProxy": {
    "Routes": {
      "route2": {
        "ClusterId": "userCluster",
        "Match": {
          "Path": "/user"
        }
      },
      "route1": {
        "ClusterId": "login03",
        "Match": {
          "Path": "/login03/{**catch-all}"
        },
        "Transforms": [
          { "PathRemovePrefix": "/login03" }
        ]
      },
      "route3": {
        "ClusterId": "login",
        "Match": {
          "Path": "/login/{**catch-all}"
        }
      },
      "route4": {
        "ClusterId": "workCluster",
        "Match": {
          "Path": "/work"
        }
      }
    },
    "Clusters": {
      "userCluster": {
        "Destinations": {
          "destination1": {
            "Address": "https://localhost:7076/"
          }
        }
      },
      "workCluster": {
        "Destinations": {
          "destination1": {
            "Address": "https://localhost:7011/"
          }
        }
      },
      "login": {
        "Destinations": {
          "destination1": {
            "Address": "http://localhost:52011/"
          }
        }
      },
      "login03": {
        "Destinations": {
          "destination1": {
            "Address": "http://localhost:52011/"
          }
        }
      }
    }
  }
}

我们暂时先不看后面两个login的Cluster和路由1，3。

现在一个最简单的YARP的反向代理就注册完成了，我们来运行一下：

然后把另外两个业务API后端启动，启动后

我们分别使用这两个路由去访问

/user

/work

从结果来看，我们没有通过直接访问业务API的端口，就实现了访问，而这就是一个简单反向代理。

而这个是后端接口的路由访问，那如果换成前端页面，又该如何处理？

其实和处理后端是一样的

我们先在IIS创建一个网站，然后在网站的根目录中创建一个页面，然后在根目录中创建一个子目录（login文件夹），又再子目录中创建一个页面

C:\INETPUB\LOGINTEST
├── success.html
├── web.config
│
└── login/
    └── login.html

想一想我为什么要创建两个页面，区别是什么？

区别在于路径
这个网站的端口部署在52011
直接访问根目录页面：

访问login文件夹页面：

那YARP怎么代理这两种页面呢，一个带路径，一个不带

先看最简单的那个也就是带路径的页面（login文件夹）

相信大家，看上文的appsettings应该可以猜测出来这个带路径的页面的配置是路由3-“ClusterId”: “login”,

给大家看一下路由3的访问：

从结果看直接就从网关80转过去了。

为什么路由3能直接匹配？因为网关的 /login 路径和后端的 /login/login.html 路径是天然对应的，不需要做任何路径转换。

那另一个路由1（/login03）是做什么的？别忘了后端的根目录还有一个 success.html，它在后端的路径就是 /。但我们已经有 /user、/work、/login 这些路由了，需要一个额外的入口来访问这个根页面。于是用 /login03 作为网关入口，再用 PathRemovePrefix 把这个前缀去掉，转发到后端就是 /，自然就匹配到 success.html 了。

具体看一下配置，路由1与路由3相比多了一个什么？多了一个 Transforms，而这个 PathRemovePrefix 就是字面上的移除路径前缀，

看一下访问结果

一个容易忽略的问题

实验过程中曾遇到配置正确但页面无法访问的情况。最开始怀疑是 YARP 配置错误，但经过排查发现，问题出在协议不一致：

服务	协议
YARP 网关（前端访问）	https://localhost
后端 IIS 站点	http://localhost:52011

浏览器会因为 Mixed Content（混合内容） 策略阻止加载非 HTTPS 的资源，最终将后端改为 HTTPS 后恢复正常。

因此在开发中需要注意：

1. HTTP 与 HTTPS 是否一致
2. 浏览器控制台是否存在 Mixed Content 报错
3. Network 面板中请求是否真正发出

---

另外，YARP 的 Transforms 不只有 PathRemovePrefix，还有：

• PathPrefix — 在请求路径前添加前缀
• PathSet — 将请求路径替换为指定值
• PathPattern — 使用模板替换请求路径，支持 {plugin}、{**remainder} 等占位符参数

完整配置参考官方文档：YARP Transforms

---

总结

这篇我们从 API 和前端页面两个角度，走通了 YARP 反向代理的基本配置：

1. 通过 Routes + Clusters 的配置，将请求转发到不同的后端服务
2. 借助 PathRemovePrefix 等 Transforms 灵活处理路径映射
3. YARP 通过 Yarp.ReverseProxy NuGet 包即可集成到 ASP.NET Core 中，配置简洁、开箱即用

从这个实验可以发现，YARP 的核心并不仅仅是转发请求。对于客户端来说，它提供了统一入口；对于后端服务来说，它隐藏了真实地址和端口。当系统进一步扩展时，还可以在此基础上实现负载均衡、认证授权、请求限流等能力，而这些也正是 API Gateway 的核心价值所在。

下一篇将继续介绍 YARP 的负载均衡与集群配置。