Linux 域名访问失败：分清 DNS、网络和 HTTPS 问题

浏览器打不开网站，不一定是服务器宕机。域名解析、TCP 连接和 TLS 握手都可能失败，直接改 DNS 或重启网络，反而容易打断现有连接。下面用只读诊断命令逐层缩小范围，适用于常见 Linux 主机。示例命令采用保留示例用途的域名；排查时换成实际目标；命令输出可能包含内部地址，分享前先脱敏。

一、先看系统实际解析到什么

getent ahosts example.com

getent 按系统配置的名称服务顺序查询，可能读取 /etc/hosts，也可能请求 DNS，比只看某个 DNS 查询工具更贴近普通程序的解析路径。输出中同一个地址重复出现，可能只是对应不同套接字类型，不代表配置重复。没有结果时，先检查本地覆盖和解析配置，不要立刻换公共 DNS：企业内部域名可能只能通过内网解析。

cat /etc/resolv.conf
cat /etc/nsswitch.conf

重点看 nameserver 和 hosts 行。若 nameserver 是 127.0.0.53，通常表示使用本地解析代理，并非直接写了上游 DNS 地址。不要覆盖这个可能由系统自动管理的文件。

二、使用 systemd-resolved 时核对上游

resolvectl status
resolvectl query example.com

这些命令只适用于已安装并启用 systemd-resolved 的系统。status 可以查看各网卡的 DNS 和域名路由配置；query 用来观察该服务的查询结果。若命令不存在，不必为了排障安装或启用新服务。若它与 getent 的结果不同，应继续检查 hosts、本地缓存和名称服务配置，而不是认定其中一个必然错误。

三、把解析失败与连接失败分开

curl -v --connect-timeout 5 --max-time 15 -o /dev/null https://example.com/

无法解析主机名，优先查解析链路；连接超时，检查路由、防火墙和目标监听；证书错误，则检查证书域名、信任链及本机时间。收到 HTTP 403 或 500，说明已进入 HTTP 层，不能再简单归因于 DNS。若同时返回 IPv4 和 IPv6，可分别给 curl 增加 -4 或 -6 做对照；仅一个协议族失败时，应核对对应路由和出口能力。ping 不通不能证明网站不可用，因为目标可能禁止 ICMP，而 HTTPS 仍然正常。详细输出可能带请求头，不要直接公开整段日志。

四、指定已确认的地址做对照

若已从可信配置拿到目标 IPv4，可使用下面模板，把 TARGET_IP 替换成真实地址：

curl --noproxy '*' --resolve example.com:443:TARGET_IP \
  --connect-timeout 5 --max-time 15 -o /dev/null -v https://example.com/

该命令仅对这次请求指定地址，仍保留域名用于 HTTPS 校验，不修改系统 DNS。它还绕过代理，只应在允许直连的环境使用；普通请求若走代理，两次结果不能直接等同。不要加 -k 跳过证书检查，也不要把临时测试地址写死到 hosts。先保存错误类型和对照结果，再决定调整哪一层。

排查记录至少保留目标域名、执行时间、解析地址、是否经过代理以及 curl 的错误信息。每次只改变一个条件，才能判断变化来自哪里。整个流程不要求重启服务，适合先收集证据，再由维护人员实施必要的配置修改。