有一点必须注意，依赖于传输协议的任何组件，例如身份验证，链接生成，重定向和地理位置，都必须在请求头转发中间件之后启用。通常，除了诊断和错误处理中间件外，请求头转发中间件应先于其他中间件运行。
配置完成后，重新部署，对于一般的项目，应该可以正常运行了。但也可能遭遇：
解除 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，因为链接地址为：，正确的链接地址应该是。也就是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 :80/;这种路由映射，最终会丢失原始路由的基础路径，也就是/admin/ 路由部分。所以，我们还是乖乖把基础路径补充上，也就是proxy_pass :80/admin/;
至此完成反向代理的单域名多站点部署。
最后
一波三折，但最终不负期望。最后完整Nginx配置放出，以供参考：
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/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; } }
参考资料：
GitHub Issue: Deploy to subdirectory #15464
ASP.Net Core 3 App Running under a Subdirectory on Nginx
到此这篇关于详解ASP.NET Core 反向代理部署知多少的文章就介绍到这了,更多相关ASP.NET Core 反向代理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
您可能感兴趣的文章: