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