引言

已经有很久没更新了，挤出些许的时间来写这篇实属不易。当然，如果是之前来过我站的老朋友也许能意识到少了点文章啥的，当然我写的估计也是无聊空话，只是有感而发写出来的，文笔较差

该篇我会分两部分，第一部分便是记录在近期处理bug的过程，同时也会说明博客（包括但不限于博客）出现的意外和处理结果，第二部分便是记录下近月的个人状况。

Fix logging

ZeroSSL HTTP验证

以前部署在服务器的v2走ws协议被GFW封了之后就再也没有管过了，到9月因某些原因才再一次连ssh去更换到ws+tls协议，但走tls需要ssl证书（跳过证书验证也行）否则返回The remote server returned an error：（503）service unavailable
由于服务器还有web需要占用443端口，故先打算用caddy解决该问题。但证书一直没有申请下来，刚开始也没想那么多以为是申请次数太多回被ban了，等待一段时间后发现还是没有申请下来，查看证书目录发现生成了一个json文件

{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/17P1pUSDO--HqwdVdaHJmQ","status":"pending","token":"ANwxAOVjp9XSDH7VkacTOnf-RsbMbKbPOxGkNDs-AB4","keyAuthorization":"ANwxAOVjp9XSDH7VkacTOnf-RsbMbKbPOxGkNDs-AB4.SSDckGgWueFhRjQYIqJ3TkFoYXIlJczskvLCq5DJfGg","identifier":{"type":"dns","value":"申请的域名"}}

显然，我需要验证域名的所属权（那时候我还没有意识到要验证）我需要这个域名的web根目录下创建.well-known/acme-challenge目录，并且以返回的token为文件名在该目录中创建一个文件，记录值为Key Authorization。完成后重新申请即可。

不过没那么顺利，caddy实现非标准HTTPS后却无法连接，尝试了换端口关firewall也无济于事，只好选择备用方案：nginx反向代理

Nginx反向代理

曾经用ssr的时候是真美好

以前更多都是接触正向代理，反向代理也只是稍稍了解。

Nginx反向代理的基本原理是将客户端的请求代理到后端服务器上，并将后端服务器的响应再返回给客户端。这样客户端并不直接访问后端服务器，而是通过Nginx作为中间层来访问。
简单来说，Nginx作为中间人，让客户端的请求在它和后端服务器之间流转，从而实现了请求的分发、管理和优化，这里提供一篇CSDN的文章以供参考

综上所述，只需要把v2的端口用nginx进行反代即可，配置如下:

server {
        listen 1234 ssl; #此为转发端口
        server_name skyfuture.cc; # 将 skyfuture.cc 修改成你的域名
        ssl_certificate /path/to/ssl.pem; # 证书
        ssl_certificate_key /path/to/ssl.key; # 密钥
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers HIGH:!aNULL:!MD5;

        location / {
            proxy_pass http://localhost:5678; # 5678 为V2端口
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    }
}

不过nginx需要我手动续签证书，而caddy自动续签，我也懒得搞auto
上传配置后重启nginx即可，至此节点重启恢复。其实看上去也没有那么复杂，更多是因为我是懒癌患者吧

不备份文件是大忌

如果你是以前来过博客的熟客应该能发现少了些什么

2024/10/27，也就是加速节点重启没多久，想着把这次遇到的bug拿来水几篇，结果打不开站点了。
因为我动过nginx的config，第一反应就是nginx出问题了，提前将备份好的old config上传也无济于事，http状态码404 Not Found，检查web根目录发现博客源码全没了，不止是博客炸了，监控站和lp官网源码也全部丢失，访问全部为404状态码。这一切来得太突然了

第一时间检查备份情况，其实备份我在本地保留了一份但却丢失了，服务器上也备份但不知道为什么也没了……博客数据库显示存在备份但找不到该目录，现在说起来真可笑

于是我连接ssh，并尝试通过extundelete来恢复数据
如果你的服务器使用的是ext3/ext4文件系统，可以使用extundelete工具恢复被删除的文件。

sudo yum install extundelete  #安装extundelete
sudo umount /dev/sdX1  # 卸载文件系统
sudo extundelete /dev/sdX1 --restore-all  # 恢复所有文件

令人遗憾的是，被删除的文件已经被覆盖或者扇区被复用，恢复的可能性几乎为0%。不过幸运的是在我检查更目录时找到了自动备份，第一时间把自动备份导出并检查，可备份的源码基本上碎片化且不全，利用率较低
更不幸的是并非博客数据文件没了，而是整个sql都损毁，只能sql重装

不过事情发展并没有那么坏的彻底
首先自动备份里有着较为老的完整数据库备份，这也是为什么现在你看到博客缺少动态/文章的原因（个别几篇文章过期就不修复了）其次本身wordpress就是开源的，使用的主题也是开源的，这就有了恢复的可能性。监控站也是我用开源的加以修改而成，正好可以利用下自动备份。lp官网由我的挚友开发，可惜当天他已返校，只能堵一把他手上有备份，幸运的是他在云端上有保存。至于其他站点，demo站html有完整备份且本身也是基于开源修改，只需要重新下载回资源再花较多的时间就可以恢复，不过使用率较低就不打算折磨自己了

监控站在事发后不久就上传源码后再一次上线，2024/11/10 0:11 博客和lp web均已恢复上线，这件事就算告一段落了。截至完稿时我都没搞清楚是什么原因导致（我误删也有可能）但无论如何，不定时备份文件甚至不备份文件是大忌，认识到错误就要改，接受批评。至此告一段落

关于笔者近月的状况

失败是人生的主旋律，不如意是人生的常态

其实没什么好说的，更多是在于“有感而发”罢了。
近三个月来，我的状态一直不断都下坡路，其实和生活对线就是这样，现在想想倒也没什么。

有时候也会责怪以前的自己不够努力，坐公交回家经过繁华商都时总是倍感万千，平日的苦涩在他们看来也只是幼稚无聊，他们用自己的方式读着我的故事，却未必理解我的每一字一句。也许我实在是太无聊了，早已不是一路人，却指望他们能读懂

写到这里，我自己都有点觉得无聊干涩，倒不如说我这渣笔承载不了我的情感
我也不太愿意和那几个同学拉扯了，但某人说的话一针见血

“我看你是中病毒了。”
“我看你是精神不正常了。”

城市的晚上灯火通明，形影相吊，尽管没有那么悲观，人生的履历也在不断复写
可惜我现在没啥动力，但路要靠自己走，至少我也找到了前进的目的，那就是在夜之城走下去，尽所能地活下去。

感谢你能看完整篇文章，如果文章有误欢迎指出。北方的冬天没什么印象，但如果你是南方人那记得多备几件衣服，凛冬将至，别把自己冷到了。最后请欣赏——