【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Ubuntu】【Gitlab】拉出内网 Web 服务：Gitlab 配置审视（八）
分析完了 server 块中的 location 配置
Nginx 配置审视
至此，Gitlab 的 Nginx 配置基本审视完毕，回顾之前 blog 【Ubuntu】【GitLab】局域网用 Ubuntu 搭建 GitLab，主要存在两点冗余：
其一，如果是作为个人搭建的 Gitlab 仓库使用，没必要在外面再安装一次 Nginx，因为 Gitlab 自带 Nginx，在终端输入
bash
ps aux | grep nginx
可以看到有两个 Nginx 在工作，其中一个是 /usr/sbin/nginx，就是之前 blog 手动安装的那个，另一个 Nginx 是 /var/opt/gitlab/nginx，这个就是 Gitlab 自带的 Nginx，所以如果只搭建 Gitlab 服务的话，用 Gitlab 自带 Nginx 就够了，当然，不是说手动安装的那个 Nginx 就没用了，如果想启用二级代理（同一个机器支持多个站点）的话，手动安装的 Nginx 也是有用的，使用场景如下
其二，下面这里的 server 块也是可以不用配置的，因为之前分析过了，当没有合适的 server 块匹配时，Nginx 将匹配默认的 default_server，如果 default_server 也没有，就匹配第一个 server 块
首先，如果做完这个 server 块的配置，按照如下步骤，查看 /var/opt/gitlab/nginx/conf/nginx.conf 生成文件，应该可以看到 server 块在最下方
可以看到，通过 nginx['custom_nginx_config'] 配置的 server 块被放到了生成文件的最下方
但是需要注意的是，在 84 行，有个 Gitlab 默认的 server 配置块 var/opt/gitlab/nginx/conf/gitlab-http.conf，查看该文件内容，可以发现里面的 server 块指向的是 Gitlab-Workhorse
之前说过，当 server 块匹配不到对应的 Host 时，就会默认将第一个 server 块拿来使用，这里 Gitlab 将 var/opt/gitlab/nginx/conf/gitlab-http.conf 配置提到了 nginx['custom_nginx_config'] 配置前面，当匹配不到合适的 server_name 时，自然会选择这里的 gitlab-http.conf 作为站点，而且可以看到，之前配置的 server_name 是个局域网 IP，如果局域网 IP 更新了，那就基本上不会匹配上，进而转向 gitlab-http.conf，将信息转发到 Workhorse，也就是 Gitlab 默认架构
此外，这个 server 块最大的问题，其实还是绕过了 Workhorse，直接将内容送到 8080 端口，终端输入
bash
sudo lsof -i :8080查看谁在监听 8080 端口，可以看到，正是 Puma 服务在监听使用 8080 端口
相当于如果 nginx['custom_nginx_config'] 配置的 server 块如果匹配上，就会将流量请求直接送到 Puma 服务，绕过了 Workhorse 处理
之前 blog 【Ubuntu】【Gitlab】拉出内网 Web 服务：Gitlab 配置审视（一） 说过，Workhosre 可以帮 Puma 处理很多事情，比如提供静态文件服务，大文件上传，Git HTTP(S) 操作，CI Job Logs 流式处理，请求预处理 等等，如果绕过了 Puma 操作，可能导致性能下降，页面加载都不完整，比如下面这种情况
只能加载出零星的文字信息，综上，这就是之前 blog 【Ubuntu】【GitLab】局域网用 Ubuntu 搭建 GitLab 里存在的两个问题
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Ubuntu】【Hugo】搭建私人博客（一）