最近在折腾统一认证中心，看到开源项目IdentityServer4.Admin集成了IdentityServer4和管理面板，就直接拿过来用了。在尝试Nginx部署时遇到了诸如虚拟目录映射，请求头超长、基础路径映射有误等问题，简单记录，以供后人参考。
Nginx 配置路由转发
首先来看下IdentityServer4.Admin的项目结构：
IdentityServer4.Admin / ├── Id4.Admin.Api # 用于提供访问Id4资源的WebApi项目 ├── Id4.Admin # 用于提供管理Id4资源的Web管理面板 ├── Id4.STS.Identity # 用于提供 STS 服务的Web项目
作为三个独立的项目，分开部署很简单，但为了统一入口管理，我倾向于将Id4.Admin和Id4.STS.Identity 部署在一个域名之下，Id4.Admin.API项目部署到网关中去。也就是通过访问Id4.STS.Identity，通过访问Id4.Admin。
这也就是遇到的第一个问题如何借助Nginx实现单域名多站点部署！
Kestrel作为一个边缘web服务器部署时，其将独占一个IP和端口。在没有反向代理服务器的情况下，用作边缘服务器的Kestrel不支持在多个进程之间共享相同的IP和端口。当将Kestrel配置为在端口上侦听时，Kestrel将处理该端口的所有网络通信，并且忽略请求头中指定的Host请求头，也就意味着Kestrel 不会负责请求转发。
因此为了进行端口共享，我们需借助反向代理将唯一的IP和端口上将请求转发给Kestrel。也就是下面这张图。
根据Nginx 官方配置文档，通过配置Location就可以实现指定路径路由转发。
server { listen 80; listen [::]:80; server_name mysite; location / { proxy_pass :80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /admin/ { proxy_pass :80/; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }
我们 比较下两个proxy_pass的配置：
location / { proxy_pass :80; }
location /admin/ { proxy_pass :80/; }
主要的不同点是 location /admin/ 节点下proxy_pass :80/结尾包含一个左斜杠 /。（如果没有这个左斜杠，所有的请求都会被路由到根节点。）比如有个请求，那么nginx根据以上配置会将请求路由到:80/dashboard。也就是最后一个左斜杠会将替换掉 location 指定的路由规则，也就是这里的/admin。
但这样就OK了吗？Absolutely no！执行nginx -s reload 你将会得到一个大大的404。
启用 UsePathBase 中间件
这时就要用到UsePathBase中间件了，其作用就是设置站点请求基础路径。在Web项目中添加UsePathBase 中间件很简单，首先在appsettings.json中添加一个配置项PATHBASE，然后Startup的Config中启用就好。
appsettings.json { "PATHBASE":"/admin" } ----- public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; } private IConfiguration Configuration { get; } // ... public void Configure(...) { // ... app.UsePathBase(Configuration.GetValue<string>("PATHBASE"));
启用 UseForwardedHeaders 中间件
使用反向代理还有一个问题要注意，那就是反向代理会模糊一些请求信息：
通过HTTP代理HTTPS请求时，原始传输协议（HTTPS）丢失，必须在请求头中转发。
由于应用程序是从代理服务器收到请求的，而不是真正的请求来源，因此原始客户端IP地址也必须在请求头中转发。
这也就是为什么上面的Nginx 配置，会默认包含以下两项配置的原因。
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
Nginx已经默认配置转发了以上信息，那么自然要显式告知ASP.NET Core Web 应用要从请求头中取回真实的请求信息。配置很简单，需要安`Microsoft.AspNetCore.HttpOverrides NuGet包，然后在Startup的Config中启用中间件。
public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; } private IConfiguration Configuration { get; } // ... public void Configure(...) { // ... app.UseForwardedHeaders(new ForwardedHeadersOptions{ ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto }); app.UsePathBase(Configuration.GetValue<string>("PATHBASE"));