一次典型的小站排查：端口、进程、DNS 为什么要一起看

从现象回推，不要一上来就改配置

站点无法访问时，很多人的第一反应是重新启动服务，或者立刻改配置文件。这样做并不总是错，但很容易把原始状态抹掉，反而更难定位问题。

更稳妥的方式，是按一条固定链路检查：

• 域名解析到哪里
• 服务器上有没有监听目标端口
• 监听端口的进程是谁
• Web 服务日志有没有报错
• 证书申请是否成功

只要这条链路完整，问题通常都会暴露出来。

端口没监听，说明问题还在本机

如果 80 或 443 根本没有被任何进程监听，那么问题大概率还停留在应用或服务管理层。这个时候应该优先检查：

• 服务有没有启动成功
• systemd 配置是否正确
• 启动后是否马上退出
• 是否被其他残留进程占用

解析正确但访问失败，优先看外层

如果域名已经指向当前机器，且本机端口也在监听，但外部还是无法访问，就要把视角切到网络外层：

• 云厂商安全组
• 本机防火墙
• 证书申请过程是否被拦截

这类问题经常不是应用错误，而是边界策略没放开。

给自己留一条标准化检查路径

我现在会把常用的检查命令固定下来，减少临场乱想：

dig +short example.com
ss -ltnp
systemctl status web.service
journalctl -u web.service --no-pager | tail -n 50
curl -I http://example.com
curl -I https://example.com

固定流程最大的好处，是每次都能快速判断问题大概落在哪一层。

结语

排障不是比谁记得更多命令，而是比谁更能把问题切成几层去验证。端口、进程、DNS 和证书一起看，往往比在某一个配置文件里盲目翻半天更有效。