Nginx引发的惨案
尘封三年的项目突然重新启动，当初的研发人员也早已不见踪影，留给我的只是一个不能访问的页面。
既然当初的项目能正常访问，说明代码是正常的，如今访问不了了，只可能是部署出现了问题。
我看了一下Apollo配置中心配置的注册中心的地址，登录到eureka的管理界面，发现相关的服务都已下线。
于是我进入到Gitlab的CI-CD界面，重新部署了服务，然后使用xshell连接到部署的物理机器上，docker ps查看所有服务都已启动，再进入到eureka界面确认所有服务都已注册成功。
本来以为着大功告成，结果挑战才刚刚开始。
前端页面能正常出来，但是后端接口却毫无反应。
我打开本地的hosts文件看了一下域名对应的ip地址，连接到对应的物理机器上，发现正是Nginx所在的机器。
ps -ef | grep nginx 检查nginx正常启动着。
nginx -t 查找nginx的配置文件地址。
打开主配置文件发现使用include命令包含了众多子配置文件，然后寻找对应的子配置文件。
grep -H ‘www.study.com’ * 查看所有子配置文件并过滤出包含www.study.com的文件名，找到对应server_name为www.study.com的子配置文件即为要寻找的子配置文件A。
打开子配置文件A，发现配置如下：
location /Prestudy{
proxy_pass "http://www.learn.com";
}
location /study/web{
rewrite ^(/study/web/.*)$ $1 break;
proxy_pass "http://www.learn.com";
proxy_connect_timeout 60s; # 连接超时
proxy_send_timeout 60s; # 发送超时
proxy_read_timeout 60s; # 读取超时
}
发现又转发到了www.learn.com，于是继续grep -H ‘www.learn.com’ *，找到最终的配置文件B。配置如下
server {
listen 80;
server_name www.learn.com;
root /var/opt/www.learn.com/dist;
access_log logs/www.learn.com.access.log;
error_log logs/www.learn