【站长日志】“千里之堤，溃于蚁穴”：一个废弃的Nginx配置是怎么让我的网站完全停摆的？

本文使用ai辅助生成

最近把自己原本运行在阿里云轻量应用服务器上的网站迁移到了新的ECS上。迁移本身并没有出现什么特别离谱的问题，域名解析、网站文件、SSL 证书以及Nginx配置都陆续处理完成，网站也曾经正常访问。真正让我折腾了一晚上的问题，却出现在一次看起来再普通不过的服务器重启之后。

更有意思的是，最后找到的原因并不是 DNS，也不是阿里云网络，更不是 SSL 证书，而是一个已经暂时停用的qsl.bh7gul.top虚拟主机配置。它所指向的网站目录早已不存在，但Nginx配置文件却仍然留在加载目录中。其中一个proxy_cache_path配置要求Nginx在启动时创建缓存目录，而这个缓存目录的父目录已经不存在。最终，一个“已经不用的网站配置”，阻止了整个Nginx服务启动，进而让同一台服务器上的其他网站全部失去80/443端口服务。

写下这篇文章，也是想给大家提供一个排查的思路，当然，因为我本身不是计算机专业的，所以只能靠ai将我口语描述的东西转化为更正式语言后再呈现给大家。

一、背景：从“网站打不开”开始

这次故障其实有一个非常明确的背景——我之前将网站从阿里云轻量应用服务器迁移到了新的 ECS，域名解析也已经切换到了新的公网 IP。迁移完成以后，网站本身是能够正常工作的。

与此同时，我还在折腾自己的LiteQSL-Web项目。这个项目涉及 Python 环境、虚拟环境以及一系列依赖安装，过程中不断尝试不同的 Python 版本、venv、pip、pyenv 等方案。折腾到后面有些烦了，于是产生了一个非常朴素的想法：干脆把服务器重启一下，整理下思绪，从头再来。

于是我通过阿里云控制台主动重启了 ECS，这次重启本身完全是我主动进行的，并不是服务器突然宕机。服务器重新启动以后，我没有去注意网站访问的状态，转头开始仔细研究如何部署LiteQSL-Web到我的服务器上，随后重心就放在了研究如何部署上。却没有发现此时网站已经访问不了了，直到今天（9月11日）我逛街到某手机店里，试图“增加”我网站的访问量时，才发现网站无法访问。

最开始其实很容易往“服务器重启导致网络异常”“DNS 没生效”“SSL 证书有问题”这些方向想。但真正排查服务器故障时，最忌讳的就是一上来凭感觉猜原因。所以我按照网络服务最基本的层级，一层一层往下排。

二、初步诊断：DNS 没问题，问题还在服务器里面

首先检查域名解析，以 blog.bh7gul.top 为核心，我分别使用了不同的 DNS 服务进行查询：

nslookup blog.bh7gul.top 223.5.5.5
nslookup blog.bh7gul.top 8.8.8.8
nslookup blog.bh7gul.top 1.1.1.1

结果都指向新的 ECS 公网 IP：

47.xxx.xxx.xxx

这意味着至少从 DNS 层面来看，没有出现“域名还指向旧服务器公网IP”的问题。既然 DNS 没问题，那就继续往下一层排查，直接从我电脑测试服务器的 80 和 443 端口：

Test-NetConnection 47.xxx.xxx.xxx -Port 80
Test-NetConnection 47.xxx.xxx.xxx -Port 443

可结果却是：

警告: TCP connect to (47.xxx.xxx.xxx : 80) failed

ComputerName           : 47.xxx.xxx.xxx
RemoteAddress          : 47.xxx.xxx.xxx
RemotePort             : 80
InterfaceAlias         : WLAN
SourceAddress          : 192.168.78.8
PingSucceeded          : True
PingReplyDetails (RTT) : 23 ms
TcpTestSucceeded       : False

警告: TCP connect to (47.xxx.xxx.xxx : 443) failed

ComputerName           : 47.xxx.xxx.xxx
RemoteAddress          : 47.xxx.xxx.xxx
RemotePort             : 443
InterfaceAlias         : WLAN
SourceAddress          : 192.168.78.8
PingSucceeded          : True
PingReplyDetails (RTT) : 24 ms
TcpTestSucceeded       : False

TcpTestSucceeded : False，这意味着80 和 443 都无法建立 TCP 连接。

这时候问题的范围已经缩小了很多——如果 DNS 正常，而服务器的 80/443 都无法连接，那么就应该继续判断：究竟是阿里云安全组/防火墙拦截了，还是服务器根本没有程序监听这些端口。

于是我登录ECS后台，开始检查监听情况：

ss -lntp | grep -E ':80|:443'

结果没有任何输出，这其实是一个非常关键的转折点。服务器不是“网站程序响应异常”，而是连负责接收 HTTP/HTTPS 请求的服务都没有监听 80/443。因此，接下来就没有必要继续纠结 DNS、浏览器缓存或者 SSL 证书了。

问题应该已经进入服务器内部：为什么 Nginx 没有监听 80 和 443？

三、继续搜索：Nginx 没有监听

接下来检查 Nginx：

systemctl status nginx --no-pager -l

很快就看到了真正的错误：

nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)

这条报错非常关键，它告诉我，Nginx 在启动或者检查配置的时候，试图创建：

/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir

但是失败了，因为对应的路径不存在，于是进一步执行：

nginx -t

得到：

nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)
nginx: configuration file /www/server/nginx/conf/nginx.conf test failed

这里有一个很容易踩坑的地方，那就是很多人看到：

syntax is ok

可能会下意识认为“配置文件没有问题”，实际上并不是。这里的意思更接近于，Nginx 配置文件的语法本身没有问题，但在进一步初始化配置时发生了致命错误。也就是说：

语法正确
↓
开始初始化配置
↓
执行 proxy_cache_path
↓
尝试创建缓存目录
↓
父目录不存在
↓
mkdir() 失败
↓
nginx -t 整体失败

因此，nginx -t 最终仍然是失败的。

四、查明真相：一个暂时用不上的qsl.bh7gul.top

接下来需要知道，为什么 Nginx 会去处理 qsl.bh7gul.top。

检查 Nginx 的虚拟主机配置：

grep -R "qsl.bh7gul.top" /www/server/panel/vhost/nginx/ -n

找到： /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf

打开这个配置文件，可以看到最前面就是：

proxy_cache_path /www/wwwroot/qsl.bh7gul.top/proxy_cache_dir levels=1:2 keys_zone=qsl_bh7gul_top_cache:20m inactive=1d max_size=5g;

后面则还有这个站点对应的：

server_name qsl.bh7gul.top;
root /www/wwwroot/qsl.bh7gul.top;

问题一下子就串起来了——Nginx 仍然认为服务器上存在一个 qsl.bh7gul.top 网站，而且这个网站需要使用 /www/wwwroot/qsl.bh7gul.top/proxy_cache_dir 作为缓存目录。

但实际上服务器上的 /www/wwwroot 中根本没有：qsl.bh7gul.top 这个目录。

当时 /www/wwwroot 中实际存在的是：

bh7gul-main
default
panel_ssl_site

并没有 qsl.bh7gul.top 。更关键的是，目前 qsl.bh7gul.top 本来就没有打算开放。换句话说：网站文件已经不存在了，但 Nginx 的虚拟主机配置还活着。这就是典型的“配置残留”。

五、探究：一个不用的网站如何拖死能把整个 Nginx ？

如果只是普通的：

root /www/wwwroot/qsl.bh7gul.top;

而这个目录不存在，通常并不会直接让 Nginx 整个服务无法启动。访问这个虚拟主机的时候，可能出现 404、文件不存在等问题，但一般不会因为网站根目录不存在，就让 Nginx master 进程直接启动失败。

真正致命的是：

proxy_cache_path /www/wwwroot/qsl.bh7gul.top/proxy_cache_dir ...

proxy_cache_path 并不是一个单纯告诉 Nginx“以后文件放这里”的普通路径声明。Nginx 在初始化相关配置时，需要处理这个缓存路径。当目标路径的父目录不存在时，就可能直接触发：

mkdir() failed

于是整个 Nginx 配置测试失败。

而 Nginx 的虚拟主机并不是彼此完全隔离的独立服务。服务器上的多个站点，例如：

blog.bh7gul.top
qsl.bh7gul.top
其他站点

本质上都属于同一个 Nginx 服务，Nginx 启动时会读取整个配置体系。

因此，它不是：qsl.bh7gul.top 坏了 → 只有这个地址打不开。而是：qsl.bh7gul.top 配置有致命错误 → Nginx 整体无法启动 → 所有依赖这台 Nginx 的网站一起失去 HTTP/HTTPS 服务。

这也解释了为什么最后表现出来的是：80/443 端口没有监听。而不是单纯的 qsl.bh7gul.top 无法访问。

六、还原：这一切究竟是如何造成的？

到这里已经知道“为什么坏”，但还可以继续问一个问题：这个问题到底是什么时候发生的？这时候系统日志就非常有价值，日志进一步还原了故障发生的时间。

通过：

journalctl -u nginx --since "2026-09-09 00:00:00" --until "2026-09-10 13:30:00" --no-pager

查询到服务器重启之后，Nginx 在 2026-09-10 13:23:13 开始启动。

可紧接着：

2026-09-10 13:23:14
nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)

随后：

nginx.service: Control process exited, code=exited status=1
nginx.service: Failed with result 'exit-code'

也就是说，ECS 重启之后，Nginx 并没有成功恢复。服务器虽然起来了，但 Web 服务没有起来。这就是为什么从外部看起来像是：“服务器重启以后，网站突然没了。”但实际上，服务器本身并没有挂，真正挂掉的是 Nginx。

更有意思的是，问题其实在重启前就已经暴露过一次。

后来继续检查：

cat /www/wwwlogs/nginx_error.log

得到：

2026/09/10 13:21:56 [emerg] 291045#0: mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)

这个时间点非常关键，因为从系统日志来看，服务器大约在 13:21:55 已经开始进入关机流程。而 nginx_error.log 在 13:21:56 记录了这个错误。随后服务器在大约 13:22 开始重启。到 13:23 重新开机。

所以现在可以还原出一个更加完整的过程：

服务器重启之前，宝塔/Nginx 相关流程已经对配置进行过检测，并发现了这个问题；随后 ECS 完成重启。重新开机时，Nginx 又必须完整加载所有虚拟主机配置，于是在启动阶段再次撞上同一个错误，最终启动失败。

宝塔自己的任务日志也留下了类似记录。

通过：

grep -n -B3 -A3 "qsl.bh7gul.top/proxy_cache_dir" /www/server/panel/logs/jobs.log

可以看到同一个错误连续出现了三次：

[root@.......]# grep -n -B3 -A3 "qsl.bh7gul.top/proxy_cache_dir" /www/server/panel/logs/jobs.log
1------------------------------------测试nginx配置文件-----------------------------------
2-nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
3:nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)
4-nginx: configuration file /www/server/nginx/conf/nginx.conf test failed
5-------------------------------------------------------------------------------------------
6------------------------------------测试nginx配置文件-----------------------------------
7-nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
8:nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)
9-nginx: configuration file /www/server/nginx/conf/nginx.conf test failed
10-------------------------------------------------------------------------------------------
11------------------------------------测试nginx配置文件-----------------------------------
12-nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
13:nginx: [emerg] mkdir() "/www/wwwroot/qsl.bh7gul.top/proxy_cache_dir" failed (2: No such file or directory)
14-nginx: configuration file /www/server/nginx/conf/nginx.conf test failed
15-------------------------------------------------------------------------------------------
16-没有发现需要修复的配置文件

这进一步说明，这不是某个浏览器偶发访问失败，而是 Nginx 配置体系本身已经存在明确的问题。

七、“亡羊补牢”：修复存在的问题

既然已经确定 qsl.bh7gul.top 目前不需要开放，那么最合理的处理方式并不是重新创建一个空目录来“哄住” Nginx。

如果只是：

mkdir -p /www/wwwroot/qsl.bh7gul.top/proxy_cache_dir

确实有可能让 Nginx 暂时启动起来，但这只是把问题藏起来。因为真正的问题是这个虚拟主机现在根本不应该处于 Nginx 的加载状态。所以我先备份原配置：

cp /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf \
   /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf.bak

然后建立一个专门存放停用配置的目录：

mkdir -p /www/server/panel/vhost/nginx/disabled

最后把这个虚拟主机配置移出去：

mv /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf \
   /www/server/panel/vhost/nginx/disabled/

这里没有直接删除，而是保留了一份备份，这样以后如果真的需要重新启用 QSL 网站，还可以恢复配置。然后重新检查：

nginx -t

这一次终于得到：

nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /www/server/nginx/conf/nginx.conf test is successful

再启动 Nginx：

systemctl start nginx

检查服务：

systemctl status nginx --no-pager -l

得到：

● nginx.service - LSB: starts the nginx web server
   Loaded: loaded (/etc/rc.d/init.d/nginx; generated)
   Active: active (running) since Fri 2026-09-11 22:58:47 CST; 1h 42min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 20106 ExecStart=/etc/rc.d/init.d/nginx start (code=exited, status=0/SUCCESS)
    Tasks: 4 (limit: 11714)
   Memory: 73.9M
   CGroup: /system.slice/nginx.service
           ├─20118 nginx: master process /www/server/nginx/sbin/nginx -c /www/server/nginx/conf/nginx.conf
           ├─20119 nginx: worker process
           ├─20120 nginx: worker process
           └─20121 nginx: cache manager process

Sep 11 22:58:47 iZwz97zewacoav1kkzgzdrZ systemd[1]: Starting LSB: starts the nginx web server...
Sep 11 22:58:47 iZwz97zewacoav1kkzgzdrZ nginx[20106]: Starting nginx...  done
Sep 11 22:58:47 iZwz97zewacoav1kkzgzdrZ systemd[1]: Started LSB: starts the nginx web server.

确认 Nginx 已经处于 active (running)

随后再次检查：

ss -lntp | grep -E ':80|:443'

得到：

LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=20120,fd=14),("nginx",pid=20119,fd=14),("nginx",pid=20118,fd=14))
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*    users:(("nginx",pid=20120,fd=15),("nginx",pid=20119,fd=15),("nginx",pid=20118,fd=15))

这一次可以看到 Nginx 已经重新监听：0.0.0.0:80 / 0.0.0.0:443

最后从 Windows 客户端测试：

Test-NetConnection 47.xxx.xxx.xxx -Port 80
Test-NetConnection 47.xxx.xxx.xxx -Port 443

最后得到：

ComputerName     : 47.xxx.xxx.xxx
RemoteAddress    : 47.xxx.xxx.xxx
RemotePort       : 80
InterfaceAlias   : WLAN
SourceAddress    : 192.168.78.8
TcpTestSucceeded : True

ComputerName     : 47.xxx.xxx.xxx
RemoteAddress    : 47.xxx.xxx.xxx
RemotePort       : 443
InterfaceAlias   : WLAN
SourceAddress    : 192.168.78.8
TcpTestSucceeded : True

两项重新变成：TcpTestSucceeded : True，直接通过浏览器访问网站，网站恢复访问。至此，网站恢复，整个故障终于闭环。

八、“劫后余思”：深入反思、总结经验、吸取教训

回头看整个过程，如果只把它概括成“服务器重启以后 Nginx 挂了。”其实是不准确的，服务器重启只是触发条件。真正的问题早就潜伏在服务器里面：

已经不存在的网站目录
        +
仍然存在的 Nginx 虚拟主机配置
        +
proxy_cache_path 指向不存在的路径
        =
Nginx 无法通过配置初始化

而服务器重启做的事情，只不过是让 Nginx 重新从零加载这些配置。所以这次事故最准确的因果关系应该是：

直接原因：qsl.bh7gul.top.conf 中的 proxy_cache_path 指向了不存在的父目录，导致 Nginx 初始化时 mkdir() 失败。

触发条件：我因为 LiteQSL-Web 环境折腾而主动重启 ECS，使 Nginx 经历完整的冷启动。

深层原因：已经不再使用的 QSL 网站配置没有同步清理，造成“网站文件已经不存在，但 Nginx 配置仍然存在”的状态不一致。

这三个层次分开之后，整个故障就非常清楚了。

这次经历让我以后处理服务器问题时，会更加重视“配置状态”而不仅仅是“文件状态”。删除一个网站，绝对不能简单理解成删除网站目录。

如果这个网站还对应着 Nginx 虚拟主机配置、反向代理、缓存目录、SSL 证书、定时任务或者其他服务，那么真正完整的“删除网站”应该包括对这些依赖关系进行检查。否则就很容易出现一种很危险的状态——“网站没了配置还在”。平时可能什么事情都没有，一旦 Nginx 重载、服务器重启或者宝塔重新生成配置，那个已经被遗忘的配置突然就可能跳出来。

这也是为什么服务器迁移之后，除了检查网站文件和数据库之外，还应该检查：

Nginx 虚拟主机配置
SSL 配置
反向代理
缓存路径
定时任务
systemd 服务
防火墙/安全组
DNS

尤其是在准备重启 Nginx 或服务器之前，最好形成一个非常简单的习惯：

nginx -t

如果失败，就不要急着：

systemctl restart nginx

更不要想着“重启一下说不定就好了”，应该先把错误解决，再重启，因为 restart 不会修复错误配置，它只会让错误配置重新执行一次。

而这次事故还有一个非常现实的教训：排查 Web 服务时，不要一开始就把所有问题都归结到“网络”。一个网站无法访问，可以按照非常朴素的层次往下排：

域名解析
   ↓
公网 IP
   ↓
云安全组 / 防火墙
   ↓
80 / 443 是否开放
   ↓
服务器是否监听端口
   ↓
Nginx 是否运行
   ↓
Nginx 配置是否正确
   ↓
反向代理 / PHP / FastAPI / 其他后端
   ↓
具体应用

这一层一层往下排，实际上比“到处重启服务”有效得多，这次故障就是一个很典型的例子。

DNS 是好的、公网 IP 是好的、云侧端口也是好的，但服务器内部根本没有程序监听 80/443。继续往下查，才发现 Nginx 没起来。继续查 Nginx，才发现是一个已经不用的虚拟主机配置阻止了整个 Nginx 启动。如果一开始就盯着“网站打不开”这五个字，很容易在 DNS、SSL、浏览器缓存这些地方兜圈子。而从网络层一路往服务层走，反而很快就能把范围缩小。

这次故障表面上看，只是一个非常普通的“服务器重启后网站打不开”。但真正排完以后，它其实是一个相当典型的服务器运维事故：一个早已失去业务用途的配置残留在系统里，一个已经不存在的目录被配置引用，一个平时看起来没什么问题的状态，在服务器重启时突然变成了致命错误。

它也让我重新理解了“迁移服务器”这件事。迁移并不只是把网站文件、数据库、域名、SSL这些从旧服务器搬到新服务器。真正迁移的是一整套运行环境，以及这套环境中长期积累下来的各种状态。而那些平时没人注意的旧配置、旧域名、旧缓存目录、旧反向代理，才往往是最容易留下隐患的地方。

这次我算是比较幸运。

网站没有数据损坏，数据库没有损坏，DNS 没有问题，SSL 也不是根因。最后真正修复它，只是移动了一个不再使用的 Nginx 配置文件。

但也正因为如此，这次经历反而值得记录下来。以后再遇到类似问题，我大概会记得：

不要看到网站打不开就先怀疑 DNS。
不要看到服务器重启就认为是重启把网站搞坏了。
更不要看到一个不用的网站，就认为它与当前网站无关。
在 Linux 服务器里，真正决定服务能不能起来的，有时候恰恰是那个你已经忘记它存在的配置文件。

而这一次，真正把整个网站“送走”的，甚至不是正在运行的程序，是一个已经不用的 qsl.bh7gul.top，它什么都没做，只是还在那里。

附录：相关时间线

最后把这次事故按照目前已经掌握的证据完整串起来，大概是这样：

时间	事件
2026-08-03 22:54	ECS 启动，此后连续运行约 37 天。
2026-08-04	`qsl.bh7gul.top` 的 Nginx 日志文件已经存在，但访问日志和错误日志均为 0 字节；无法据此确定配置的创建时间。
2026-09-09 12:23–12:33	最后一次故障前 SSH 维护，期间正在持续折腾 LiteQSL-Web、Python、pyenv、虚拟环境及依赖安装。
2026-09-10 13:21:55	宝塔相关服务开始进入停止流程。
13:21:56	`nginx_error.log` 记录 `qsl.bh7gul.top/proxy_cache_dir` 创建失败。
约 13:22	用户主动通过阿里云控制台重启 ECS，原因是 LiteQSL-Web 环境折腾较为繁琐，希望重启服务器重新开始。
13:23 左右	ECS 完成重新启动。
13:23:13	systemd 开始启动 Nginx。
13:23:14	Nginx 再次因为 `qsl.bh7gul.top` 的 `proxy_cache_path` 报错，启动失败。
随后	Nginx 未运行，80/443 没有监听，网站无法通过 HTTP/HTTPS 访问。
2026-09-11 22:51:40	开始逐层排查 DNS、IP、端口和 Nginx 服务状态。确认 DNS 正确解析至 `47.106.38.131`，但服务器没有监听 80/443。
22:51:51	`nginx -t` 定位到 `qsl.bh7gul.top/proxy_cache_dir`。
22:52~22:53	确认 `/www/wwwroot/qsl.bh7gul.top` 已不存在，而对应 Nginx 虚拟主机配置仍然存在。
22:53～22:58	备份 `qsl.bh7gul.top.conf`，将其移出 Nginx 加载目录。
22:58	`nginx -t` 成功通过。
22:59	Nginx 成功启动并重新监听 80/443。
23:00	Windows `Test-NetConnection` 对 80、443 均返回 `TcpTestSucceeded : True`，网站恢复访问。

具体操作为：

  107  2026-09-11 22:51:40 ss -lntp | grep -E ':80|:443'
  108  2026-09-11 22:51:40 systemctl status nginx --no-pager -l
  109  2026-09-11 22:51:51 nginx -t
  110  2026-09-11 22:52:59 ls -ld /www
  111  2026-09-11 22:52:59 ls -ld /www/wwwroot
  112  2026-09-11 22:53:01 ls -ld /www/wwwroot/qsl.bh7gul.top
  113  2026-09-11 22:53:22 ls -la /www/wwwroot/
  114  2026-09-11 22:53:31 grep -R "proxy_cache_dir" /www/server/nginx/conf/ -n
  115  2026-09-11 22:54:50 grep -R "qsl.bh7gul.top" /www/server/nginx/conf/ -n
  116  2026-09-11 22:54:58 grep -R "proxy_cache_dir" /www/server/nginx/ -n
  117  2026-09-11 22:55:06 grep -R "include" /www/server/nginx/conf/nginx.conf
  118  2026-09-11 22:55:14 cat /www/server/nginx/conf/proxy.conf
  119  2026-09-11 22:56:40 grep -R "qsl.bh7gul.top" /www/server/panel/vhost/nginx/ -n
  120  2026-09-11 22:56:48 grep -R "proxy_cache" /www/server/panel/vhost/nginx/ -n
  121  2026-09-11 22:57:36 cp /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf    /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf.bak
  122  2026-09-11 22:57:52 mkdir -p /www/server/panel/vhost/nginx/disabled
  123  2026-09-11 22:58:02 mv /www/server/panel/vhost/nginx/qsl.bh7gul.top.conf    /www/server/panel/vhost/nginx/disabled/
  124  2026-09-11 22:58:12 nginx -t
  125  2026-09-11 22:58:47 systemctl start nginx
  126  2026-09-11 22:58:54 systemctl status nginx --no-pager -l
  127  2026-09-11 22:59:02 ss -lntp | grep -E ':80|:443

2026 年 10 月
一	二	三	四	五	六	日
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31