详解ASP.NET Core 反向代理部署知多少

引言

最近在折腾统一认证中心,看到开源项目IdentityServer4.Admin集成了IdentityServer4和管理面板,就直接拿过来用了。在尝试Nginx部署时遇到了诸如虚拟目录映射,请求头超长、基础路径映射有误等问题,简单记录,以供后人参考。

Nginx 配置路由转发

首先来看下IdentityServer4.Admin的项目结构:

IdentityServer4.Admin /
├── Id4.Admin.Api         # 用于提供访问Id4资源的WebApi项目
├── Id4.Admin           # 用于提供管理Id4资源的Web管理面板
├── Id4.STS.Identity        # 用于提供 STS 服务的Web项目

作为三个独立的项目,分开部署很简单,但为了统一入口管理,我倾向于将Id4.AdminId4.STS.Identity 部署在一个域名之下,Id4.Admin.API项目部署到网关中去。也就是通过http://auth.xxx.com访问Id4.STS.Identity,通过http://auth.xxx.com/admin访问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 http://id4.sts.identity: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 http://id4.admin: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 http://id4.sts.identity:80; }
  • location /admin/ { proxy_pass http://id4.admin:80/; }

主要的不同点是 location /admin/ 节点下proxy_pass http://id4.admin:80/结尾包含一个左斜杠 /。(如果没有这个左斜杠,所有的请求都会被路由到根节点。)比如有个请求http://auth.xxx.com/admin/dashboard,那么nginx根据以上配置会将请求路由到http://id4.admin: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 中间件

使用反向代理还有一个问题要注意,那就是反向代理会模糊一些请求信息:

  1. 通过HTTP代理HTTPS请求时,原始传输协议(HTTPS)丢失,必须在请求头中转发。
  2. 由于应用程序是从代理服务器收到请求的,而不是真正的请求来源,因此原始客户端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"));

有一点必须注意,依赖于传输协议的任何组件,例如身份验证,链接生成,重定向和地理位置,都必须在请求头转发中间件之后启用。通常,除了诊断和错误处理中间件外,请求头转发中间件应先于其他中间件运行。

配置完成后,重新部署,对于一般的项目,应该可以正常运行了。但也可能遭遇:

解除 Nginx 请求头转发大小限制

针对这种错误当然要查Nginx错误日志了,如果Nginx服务器部署在Linux服务器,那么默认日志文件在/var/log/nginx/error.log,日志如下:17677925 upstream sent too big header while reading response header from upstream。简单翻译就是请求头数据过大。那我们就来看看转发的请求头到底会有多大,从下图来看请求头中携带的Cookie最大的有3K多。

nginx添加下面的配置即可:

proxy_buffer_size     128k;
proxy_buffers       4 256k;
proxy_busy_buffers_size  256k

重新加载Nginx 配置,访问成功。

Is All Set? No!

修复基础路径错误

当我尝试点击Admin管理面板的链接时,得到无情的404,因为链接地址为:http://auth.xxx.com/configruaion/clients,正确的链接地址应该是http://auth.xxx.com/admin/configruaion/clients。也就是Razor TagHelper 渲染的<a asp-controller="Configruaion" asp-action="Clients">Manage Client</a>,并没有帮按照UsePathBase指定的路径生成a标签链接。咱们只能看看源码一探究竟了Microsoft.AspNetCore.Mvc.TagHelpers/AnchorTagHelper.cs,最终在拼接Herf属性时使用的是var pathBase = ActionContext.HttpContext.Request.PathBase;来拼接基础路径。也就是说说TagHelper根据Http请求上下文中获取基础路径。因此如果采用location /admin/ { proxy_pass http://id4.admin:80/;这种路由映射,最终会丢失原始路由的基础路径,也就是/admin/ 路由部分。所以,我们还是乖乖把基础路径补充上,也就是proxy_pass http://id4.admin:80/admin/;
至此完成反向代理的单域名多站点部署。

最后

一波三折,但最终不负期望。最后完整Nginx配置放出,以供参考:

server {
  listen 80;
  listen [::]:80;
  server_name mysite;

  location / {
    proxy_pass http://id4.sts.identity: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 http://id4.admin:80/admin/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffer_size     128k;
    proxy_buffers       4 256k;
    proxy_busy_buffers_size  256k;
  }
}

参考资料:

Configure ASP.NET Core to work with proxy servers and load balancers

GitHub Issue: Deploy to subdirectory #15464

ASP.Net Core 3 App Running under a Subdirectory on Nginx

到此这篇关于详解ASP.NET Core 反向代理部署知多少的文章就介绍到这了,更多相关ASP.NET Core 反向代理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 利用.net core实现反向代理中间件的方法

    最近在将一些项目的rest api迁移到.net core中,最开始是用的Nginx做反向代理,将已经完成切换的部分切入系统,如下图所示: 由于迁移过程中也在进行代码重构,需要经常比较频繁的测试,以保证能及时发现引入的问题.从而导致我们每迁移一部分都需要配置一次nginx的路由映射,保证迁移的功能能切入系统测试. 进行了一段时间后,发现经常配置Nginx一来比较麻烦,二来容易配错:便想将这个反向代理的功能放在.net core程序中去,实现如下的功能: Rest请求直接发往.net core程序

  • 详解ASP.NET Core 反向代理部署知多少

    引言 最近在折腾统一认证中心,看到开源项目IdentityServer4.Admin集成了IdentityServer4和管理面板,就直接拿过来用了.在尝试Nginx部署时遇到了诸如虚拟目录映射,请求头超长.基础路径映射有误等问题,简单记录,以供后人参考. Nginx 配置路由转发 首先来看下IdentityServer4.Admin的项目结构: IdentityServer4.Admin / ├── Id4.Admin.Api # 用于提供访问Id4资源的WebApi项目 ├── Id4.Ad

  • 详解Asp.Net Core 发布和部署( MacOS + Linux + Nginx )

    前言 在上篇文章中,主要介绍了 Dotnet Core Run 命令,这篇文章主要是讲解如何在Linux中,对 Asp.Net Core 的程序进行发布和部署. 目录 新建一个 WebApp 项目 发布到 Linux,Mac OS 使用 Nginx 进行反向代理 新建一个 WebApp 项目 在 Asp.Net Core 项目中,我们使用 dotnet new -t WebApp 命令和创建一个新的空的 Web 应用程序. 以下是我在 Mac 中的截图: 主要是用以下几个命令: mkdir He

  • 详解Asp.Net Core 2.1+的视图缓存(响应缓存)

    响应缓存Razor 页与 ASP.NET 核心 2.0 中不支持. 此功能将支持ASP.NET 核心 2.1 版本. 在老的版本的MVC里面,有一种可以缓存视图的特性(OutputCache),可以保持同一个参数的请求,在N段时间内,直接从mvc的缓存中读取,不去走视图的逻辑. [OutputCache(Duration =20)]//设置过期时间为20秒 public ActionResult ExampleCacheAction() { var time=DateTime.Now.ToStr

  • 详解ASP.NET Core中配置监听URLs的五种方式

    默认情况下,ASP. NET Core应用会监听一下2个Url: http://localhost:5000 https://localhost:5001 在本篇博文中,我将展示如何使用五种不同的方式改变应用监听的URLs. 在ASP.NET Core项目启动时,有多种配置监听Url的方式,在我之前的一篇博客中,已经展示了在ASP.NET Core 1.0中如何应用不同的方式配置,在ASP.NET Core 3.x中,大部分方式还是一样的. UseUrls() - 在Program.cs配置程序

  • 详解asp.net core 依赖注入

    前言 好久没有写微博了,因为前段时间由于家庭原因决定从工作了3年多的北京转移到上海去.依赖注入在学习net core的时候也有写过类似的东西,只是实践的较少,结果来到上海新公司系统框架涉及到了这块知识点,所以在了解完自己的项目之后决定做一些相关的总结.接下来就让我们先来了解hewi依赖注入. 什么是依赖注入 依赖注入,全称是"依赖注入到容器", 容器(IOC容器)是一个设计模式,它也是个对象,你把某个类(不管有多少依赖关系)放入这个容器中,可以"解析"出这个类的实例

  • Nginx配置参数中文说明详解(负载均衡与反向代理)

    PS:最近在看<<高性能Linux服务器构建实战>>的Nginx章节,对其nginx介绍的非常详细,现把经常用到的Nginx配置参数中文说明摘录和nginx做负载均衡的本人真实演示实例抄录下来以便以后查看! Nginx配置参数中文详细说明 #定义Nginx运行的用户和用户组 user www www; # #nginx进程数,建议设置为等于CPU总核心数. worker_processes 8; # #全局错误日志定义类型,[ debug | info | notice | war

  • 详解ASP.NET Core端点路由的作用原理

    端点路由(Endpoint Routing)最早出现在ASP.NET Core2.2,在ASP.NET Core3.0提升为一等公民. Endpoint Routing的动机 在端点路由出现之前,我们一般在请求处理管道的末尾,定义MVC中间件解析路由.这种方式意味着在处理管道中,MVC中间件之前的中间件将无法获得路由信息. 路由信息对于某些中间件非常有用,比如CORS.认证中间件(认证过程可能会用到路由信息). 同时端点路由提炼出端点概念,解耦路由匹配逻辑.请求分发. Endpoint Rout

  • 详解ASP.NET Core Web Api之JWT刷新Token

    前言 如题,本节我们进入JWT最后一节内容,JWT本质上就是从身份认证服务器获取访问令牌,继而对于用户后续可访问受保护资源,但是关键问题是:访问令牌的生命周期到底设置成多久呢?见过一些使用JWT的童鞋会将JWT过期时间设置成很长,有的几个小时,有的一天,有的甚至一个月,这么做当然存在问题,如果被恶意获得访问令牌,那么可在整个生命周期中使用访问令牌,也就是说存在冒充用户身份,此时身份认证服务器当然也就是始终信任该冒牌访问令牌,若要使得冒牌访问令牌无效,唯一的方案则是修改密钥,但是如果我们这么做了,

  • 详解ASP.NET Core部署项目到Ubuntu Server

    基于上一篇成功安装Ubuntu Server 16.10的基础上,接下来继续我们ASP.NET Core项目的部署之旅! 只是对于这些年整天和Windows打交道的我,初次使用Linux确实有点费劲. 但是为了.NET Core跨平台的这一重大特性,即使再多的坑,也还是要硬着头皮上的. 不然会有人怀着诧异的眼神问你:你的.NET Core项目还部署到Windows上? 废话不多说,预祝你在十步之内成功部署!<( ̄︶ ̄)[GO!] 一.安装.NET Core SDK 依次输入以下命令即可完成安装,

  • 详解ASP.NET Core Docker部署

    前言 在前面文章中,介绍了 ASP.NET Core在 macOS,Linux 上基于Nginx和Jexus的发布和部署,本篇文章主要是如何在Docker容器中运行ASP.NET Core应用程序. ASP.NET Nginx 发布和部署 :http://www.cnblogs.com/savorboard/p/dotnet-core-publish-nginx.html. Asp.Net Jexus 发布和部署:http://www.cnblogs.com/savorboard/p/dot-n

随机推荐