在学校混了个网站开发赚点小钱，时不时就要面对几年前的老代码，好在代码还没传几手，修修补补继续用还是没问题的
寒假放一半老师突然戳我，网站挂了，淦
思路和过程
先F12看看响应，好家伙，直接没有响应，首先猜测是连接出了问题
然后ping了一通发现没有问题能连上，tracert也到了，排除解析问题。
ssh也连上了，防火墙也没有问题，就此排除服务器网络问题，这时候怀疑是Apache的问题了。
先检查配置文件，位于/etc/httpd/conf/httpd.conf，没有问题
然后检查Apache的log，位于/var/log/httpd/，把所有log都拉出来一看，都没问题。
虽然按照相应码没啥关联，但还是把网站的log也拉出来看了一眼，只有陈年的error，不过考虑到前几天的log也有相似的错误，而前几天并没有无法访问，而且直接没有响应也不太科学，于是基本就没有怀疑是网站本身的问题。
本来我的工作就到此为止了，剩下的部分就交给后台/运维了，但是对方是刚来的，也没搞明白问题。事情又比较紧急，只能让我这个半桶水在连网站后台架构和网络拓扑都不清楚的情况下破罐子破摔看看情况。
由于网站本身在内网，所以接手时也没多想，估计是走iptables那一套prerouting->forward->postrouting，一台有公网ip的机子当中转，然后本机反代。排除完前面的问题后，我开始怀疑是不是这台做nat的机子出了问题。
连入公网机器，在里面curl网站的内网ip：
curl 'xxx.xxx.xxx.xxx' <blablabla>
成功拿到了页面，说明应该是这台机器的问题跑不了了。
排除了各种可能的因素，终于开始检查防火墙：
iptables -nvL --line-number
iptables -nvL --line-number -t nat
结果发现nat表并没有相关规则。这时候我才明白，原来并没有什么nat，nginx是搭在公网鸡上的😭
检查端口后发现没有监听，ps了一下居然没看到nginx的进程，好家伙，原来是nginx挂了。于是把nginx重新拉了起来，网站成功恢复访问。
原因
问题解决了，但是nginx好好跑着莫名其妙就挂了，找了半天也没发现原因。这时候学弟找上了我，一问才知道，原来昨天他们重启了服务器…
问题又来了，学长是做了nginx的自启服务的。查了一下系统服务的状态发现还是failed，重新启动服务结果报配置文件没过检查，继续failed。明明手动nginx -t能过，可是服务拉起来就过不了检测…
最后发现是nginx目录下有个配置文件内配置的证书过期了，但是这个配置文件早就已经不使用了，也没有include进主配置文件内。不知道为什么，手动nginx -t和自启服务的检测机制不太一样，手动nginx -t只检测启用的配置文件，而且不会因为证书问题卡人，但是服务拉起来的话会检查得更加细致，会检查nginx目录下conf.d子目录内的所有配置文件，即使你没有include到它，而且也会对证书过期这样的问题报警。
查看nginx.service文件：
cat /usr/lib/systemd/system/nginx.service
发现配置文件检测是这么一段：
ExecStartPre=/usr/sbin/nginx -t
无论怎么看，服务和手动测试理论上也应该是一致的才对。但实际上结果却不一样，只能说非常神秘