【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Ubuntu】【Gitlab】拉出内网 Web 服务：Gitlab 配置审视（三）
分析了 Gitlab 中关于 Nginx 的一些配置项（注意，这里的 Nginx 指的是 Gitlab 自带的 Nginx，不是系统安装的 Nginx，这块儿后面分析），并准备开始分析 Nginx 中的 server 配置块，下面继续
Nginx 配置审视
上篇 blog 里提到了 external_url 和 server_name 的区别，下面继续
首先是这个 external_url，可以看到，这个配置项并没有 Nginx 相关的关联（比如被命名成 nginx['external_url'] 之类的），所以说明和 Nginx 没有太大的关系，而上篇 blog 也介绍了，external_url 就表示的是 Gitlab 应用层的身份标识，也确实和 Nginx 没啥关系，主要是 Gitlab 的后端应用 Ruby on Rails 的相关配置，作用是告诉 Gitlab 用户是通过什么 URL 来访问的，紧接着，Gitlab 会用这个输入做一些事情：
- 生成所有页面中的链接 ：比如登录 Gitlab 后，点击顶部菜单 Projects，页面上会列出用户空间的项目，其中每个项目都有一个链接，这个链接不是写死的，而是 Gitlab 在渲染网页时按照
#{external_url}/#{namespace}/#{project}这样动态拼出来的，所以external_url决定了页面上所有超链接的根地址
- 构造 Git 克隆地址 ：在项目页面，可以看到 Git 克隆命令如下，这个 URL 也是 GitLab 根据
external_url自动生成的
简单来说，external_url 决定了 Gitlab 认为自己是谁，注意，即使不用 Nginx，也必须设置 external_url，因为这是 GitLab 应用本身的配置
OK，下面分析 server 块中的 server_name，server_name 是 Gitlab 自带 Nginx 层的虚拟主机匹配规则，当一个 HTTP 请求到达 Nginx 时，Nginx 会看请求头中的 Host 字段，然后根据 server_name 匹配的 server 块来处理请求 ，如果不匹配任何 server_name，Nginx 会使用默认 server 块
简单来说，server_name 会告诉 Nginx，哪些请求应该由这个 server 配置块来处理，注意，server_name 支持域名，IP，通配符（比如 *.example.com），甚至可以留空，也就是写成下面这个样子，这样就可以匹配任意 Host
bash
server {
listen *:80;
server_name ""; # 留空
# 其他配置...
}OK，上面提到了 Host 字段，下面分析下
Host 是 HTTP/1.1 协议中强制要求的请求头字段，用于告诉服务器，用户想访问的是这台机器上的哪个域名 ，早期一台服务器通常只托管一个网站，但随着虚拟主机（Virtual Hosting）技术普及，一台服务器可以托管多个网站（比如 siteA.com，siteB.org），这些网站可以共享同一个 IP 地址，具体流程如下
- 客户端（浏览器）通过 DNS 查到
siteA.com和siteB.org都指向127.0.0.1（也就是本机回环地址，以回环地址举例） - 当用户访问
http://siteA.com时，浏览器会向127.0.0.1发起 TCP 连接（通过端口映射，将连接请求转发到远程服务器上，之前 blog 【OS】【Nuttx】【周边】效果呈现方案解析：端口映射（一） 介绍过） - 对于远程服务器来说，为了区分用户是要访问
siteA.com还是siteB.org，此时就得靠 Host 请求头了，Host 字段会明确写该请求是siteA.com，还是siteB.org
可以看到，Host 字段可以在共享 IP 的情况下，区分同一个服务器上的不同站点，如果没有 Host 字段，服务器就无法知道该返回哪个网站的内容
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Ubuntu】【Gitlab】拉出内网 Web 服务：Gitlab 配置审视（五）