这两天本来就有工作要忙，结果日常运维的两个服务器的各项服务都出现了影响较大的问题，特此记录一下。部分问题最后发现原因很简单，也一并记录，以免以后再犯低级错误。另外还包括一些未完全解决的问题。
由于部分内容涉及服务器安全，且当时排查过程较为紧急，留存图片较少，故本文附图较少，以文字叙述为主。

先放一张服务监控面板图，看着到处又黄又红的还是挺棘手的。

Nginx配置屏蔽网站素材

项目服务器上有一个静态网站，使用tomcat部署的，由Nginx做反向代理，该网站不是我写的，所以项目结构不太了解，但是收到甲方要求排查服务器上配置文件暴露的情况，而该tomcat的ROOT目录下正好就有WEB-INF内配置文件暴露，为方便起见，不影响原项目，遂直接在Nginx中屏蔽对于该目录下除index.html以外的访问。

结果可想而知，console里一堆的404，index.html索引的所有js、css、jpg素材等全都访问不到，现在从上帝视角来排查原因相对容易，这里记录一下当时的排查过程。

Tomcat

期初怀疑是Tomcat捣鬼，可能我不小心动了前辈的配置文件或项目结构，于是乎废了半天劲儿把备份的一份ROOT.zip拉了出来，当然也不会有效果。

回到Nginx

终于想到点子上了，把Nginx屏蔽网站素材的配置注释掉，终于是可以访问了；随后再对Tomcat进行配置防止配置文件被外网访问，完成甲方的要求。

但是出现了一个新问题：上一步怀疑Tomcat时拉了一个不知道什么时候版本的ROOT.zip，后面网站内容有了一些修改，遂回滚index.html

回滚完成后发现素材的使用基本一致，但是命名发生了变化，例如：原来的image1.jpg变成了image6.jpg，于是相应排查解决这些问题，最终实现正常访问。

经验教训

服务器所有操作都预留回滚方案，配置文件修改前先备份等等，这次还是挺有用的。
定期备份数据，万一服务器上数据被修改了，还能尽快恢复。
单个网站的一些小问题在网站内处理就好了，不用劳烦Nginx大哥了；另外Nginx熟了之后还是得多学习一下Tomcat，基础知识不够扎实。

GeoServer属性文件Not Found

应甲方要求，重启服务器上运行的各服务，其中重启GeoServer时遇到异常抛出：

字面意思很好理解，找不到文件了嘛，但是排查的过程就有意思了。（以下部分由我与同事共同完成）

属性文件缺失？

根据字面意思，怀疑是不是某个properties属性文件丢失了，看到路径里还带Temp的，更加怀疑是不是被某些监管软件或被人为当成是垃圾给删掉了，但是这个properties到底记录了什么呢？要去哪里找回这个properties呢？

查看目录

cd到报错提示的AppData\Local\Temp目录，发现里面只有两个随机文件名的txt文件，读者可能已经在此能想到问题所在了，但无奈我当时正着急下班，没有多想，继续想着找别的办法摸索一下看看。

前一个报错

留意到在此之前还有一个类似于Warning的提示

The GEOSERVER_DATA_DIR environment variable is not defined correctly.

于是去系统环境变量以及GeoServer的配置文件里面查找，发现环境变量里缺失没配置，但是GeoServer配置文件里有这一项配置，而且也是正确的，看来跟这个Warning关系不大。

查阅文档

后来去查阅了GeoServer的官方文档，翻了一些社区、论坛，大致搞清楚了这个文件不是我们的配置文件，而是GeoServer每次启动时会创建的一个随机的文件，所以文件名才会这么随机。那么，创建文件失败，提示NoSuchFileException，首先想到了权限问题。于是，我们又去逐一检查了服务器上的用户配置、权限设置和这个文件夹的权限设置等，均没发现问题。

缺个“2”

最后，还是我的脑子突然又恢复正常，综合上面的各种现象，就想着要不建个在Temp文件夹下建个名为“2”的文件夹试试看。一试，就解决问题了。

原来是Java新建文件时一定要在已有的目录下新建，Python当中亦是如此，长教训了。

BTW，GeoServer什么时候能改进一下这部分代码，没文件夹就自己建一个好了，别稍微缺个文件夹就崩。

复盘

有些报错真就是字面意思，没那么深奥，NotFound就是找不到，可能不用扯权限、环境变量之类的
复盘认为是服务器管理软件自动清理垃圾，平时运行时这些文件都处于被占用的状态，垃圾清理工具无法直接删除；但是重启过程中关停了服务，取消了占用，于是就被清理掉了。当然也不排除是有同事人为地认为Temp文件夹下是垃圾，直接删掉了。
平常写程序时多几个catch少几个throw，丁大点事儿就崩可不好。

输错IP？

前两个让人烦恼的问题，现在来一个笑话来调节一下。

起因

正如之前的文章中所说，我暑假期间完成了服务的迁移和自托管服务的部署，域名也相应地解析到了新的服务器。后来有点事儿，还需要在原服务器上搭点服务，整理一下服务器上的数据和资源。因原服务器上有部署1panel，遂直接通过公网ip访问，结果访问不通，Chrome的报错也是迷，时而ERR_CONNECTION_CLOSED，时而502 ERROR，时而ERR_CONNECTION_TIMEOUT。

排查

马上就ssh到了后台取消了1panel的域名访问限制、端口访问限制、安全路径等等，再按新的设置也没法访问；包括服务器上原来部署的其它服务也都无法访问，报错也类似。

接下来就去检查云服务商后台的防火墙策略，确认有放行相应端口。

之后就到了服务器防火墙，同样道理，检查一遍，确认目标端口均有放行。

这就让我很困惑了，无非就是取消了个域名解析，怎么就访问不了了，我也已经把"仅限域名访问"给取消掉了呀。

结局——笑话

原因很简单，目标主机的ip是8.134.65.26，而我一直输入、复制访问的IP都是8.134.6.26，那当然就不通了。

Cloudflare无法用Clash访问

服务器上已部署了OpenClash做DNS劫持，全局代理，但是突然从昨天开始就无法访问Cloudflare的域名了，ip直连倒是能通，但是人家cf不让这么干，啥也没动过土壤就神奇起来了。

关Clash

关掉Clash后，dns一通配置下来，折腾了好半天，终于是访问上Cloudflare了，试着在电脑本地挂Clash，又访问不上了，更甚者，甚至再次关掉Clash后仍然访问不上，怀疑是dns缓存的问题。本来是用lucky来做域名解析的，访问不了Cloudflare的api，也就导致所有服务同时下线。接入局域网后更是只要用上了Cloudflare CDN的网站都无法访问，不仅仅是我服务器上的那些，随后干脆卸载OpenClash，结果看到lucky上面仍然访问失败，重试了几次之后甚至导致了lucky启动失败，于是重装lucky，仍然启动失败，最后干脆重置系统，一番配置下来废了半天劲儿。