从 DNS 到 TLS：逐层定位一次 HTTPS 失败
把域名解析、TCP 连接、TLS 握手与 HTTP 响应分开检查，让每一步都回答一个具体问题。
浏览器里的“无法访问”可能来自不同层次。反复重启服务通常不能增加信息。更有效的方式是先写出请求经过的路径，再为每一层选择一个能证实或排除假设的检查。
先确认名字指向哪里
DNS 返回的是地址，不是服务状态。记录解析结果、查询使用的 DNS 服务器以及是否存在 AAAA 记录。双栈环境下，IPv4 正常而 IPv6 路径异常，也可能表现为间歇性失败。
resolvectl query example.org
dig +short A example.org
dig +short AAAA example.org如果修改过记录，先看 TTL 和本地缓存。不要把浏览器、操作系统和递归解析器的缓存当成同一个缓存；它们可能在不同时间更新。
保留域名，单独绕过 DNS
直接访问 IP 会改变 Host 和 TLS SNI，可能落到另一个虚拟主机。curl 的 --resolve 可以固定目标地址，同时保留 URL 中的域名。下面的文档示例地址需要替换成真实服务器地址。
curl --resolve example.org:443:192.0.2.10 \
--connect-timeout 5 --max-time 15 \
-o /dev/null -sS -w 'status=%{http_code} tls=%{ssl_verify_result}\n' \
https://example.org/这一步成功而正常访问失败时，优先调查解析或地址选择。连接超时则继续检查监听地址、路由和防火墙。Connection refused 与超时的含义不同，前者通常说明目标主动拒绝了连接。
最后看握手与应用响应
openssl s_client -connect example.org:443 \
-servername example.org -alpn h2,http/1.1 \
-verify_return_error < /dev/null核对证书域名、有效期、完整链和协商协议。TLS 成功之后，再判断 HTTP 状态和页面内容；404 证明已经获得了应用响应，却不一定说明路径正确。HEAD 与 GET 的路由也可能不同，检查登录页时应以实际 GET 为准。
留下一份能复现的记录
记录时间、目标地址、使用的命令、响应状态与一个结论，例如“固定地址后 TLS 校验通过，因此下一步查 DNS”。每次只改变一个条件，这份记录既能缩短排查，也能帮助下一位维护者接手。