📍 WDQWDWQD987AAAAA:216.73.217.108
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bf4688fa00c1.html
📄

子域名解析：怎样确认配置实际生效

确认子域名解析生效，不能只看域名服务商控制台里显示“已保存”。真正要验证的是：递归DNS能否查到记录、返回的IP或目标是否与预期一致、目标服务器是否接受该子域名的请求。最直接的做法是用dig或nslookup查询，再结合本机解析和HTTP访问结果交叉判断。

先明确要验证的三层结果

子域名解析的“生效”至少包含三层含义，任何一层不通过，用户都可能打不开页面。

• 权威记录已发布：在子域名所属DNS区域中，A、AAAA或CNAME记录已经保存并处于启用状态。
• 递归解析可获取：公共递归DNS或你本机使用的DNS能查询到这条记录，且结果与权威记录一致。
• 目标端可响应：解析到的IP或CNAME目标上，有服务监听对应端口，并配置了该子域名的虚拟主机或证书。

只看到第一层，不能称为生效。只看到第二层，也不能保证访问成功。

用查询命令判断解析是否真正返回

以Linux或macOS为例，查询A记录：

dig sub.example.com A +short

如果返回一个或多个IP，说明递归DNS已经能拿到记录。若返回空，继续指定权威服务器查询：

dig sub.example.com A @ns1.example-dns.com +short

把ns1.example-dns.com替换为域名实际使用的权威DNS。如果权威服务器能返回、默认递归查询却返回空，问题更可能在缓存或递归链路，而不是记录本身。

查询CNAME时，把类型改为CNAME。需要注意，CNAME记录的目标主机名本身也必须能继续解析，否则整条链路仍然不通。

Windows下可用：

nslookup sub.example.com

若想指定DNS服务器：

nslookup sub.example.com 8.8.8.8

检查本机DNS缓存与解析顺序

公共查询正常、自己电脑却打不开，常见原因是本机缓存了旧结果，或系统使用了不同的DNS服务器。

• Windows可执行ipconfig /flushdns清理本机DNS缓存。
• macOS可执行sudo dscacheutil -flushcache，必要时再重启相关解析服务。
• Linux根据发行版和解析组件不同，常见做法是重启systemd-resolved，或直接查看/etc/resolv.conf确认当前使用的DNS地址。

清理后重新查询。如果结果立即变成预期值，说明是缓存问题；如果仍然返回旧IP，需要回到权威记录和TTL设置上排查。

把解析结果与访问结果对照

解析正确不等于访问正常。拿到IP后，继续检查目标端：

1. 用curl -I http://sub.example.com或curl -I https://sub.example.com查看返回状态码和响应头。
2. 如果连接被拒绝，检查目标服务器是否监听80或443端口，以及防火墙、安全组是否放行。
3. 如果返回默认站点或其他站点内容，检查Web服务器中该子域名的server_name或虚拟主机绑定是否配置正确。
4. 如果HTTPS报证书错误，检查证书是否包含该子域名，而不是只签了主域名。

这一步能区分“解析没生效”和“解析生效但服务没接住”。两者处理方向完全不同。

从交付结果倒推验收清单

假设你负责把一个子域名指向一台新服务器。要确认配置实际生效，验收时应同时满足以下条件：

• 权威DNS中存在该子域名的A、AAAA或CNAME记录，且值与目标一致。
• 至少两个公共递归DNS查询结果一致。
• 本机清理缓存后查询结果一致。
• 目标服务器对应端口可连通。
• HTTP或HTTPS请求返回预期内容，而不是默认页或错误页。

如果其中一项不满足，不要笼统地说“解析没生效”，而应记录具体是哪一层失败。例如“权威返回正确，但递归仍返回旧IP”，或“解析正确，但443端口连接超时”。这样下一步才有明确方向。

下一步：选一个你正在处理的子域名，先执行一次指定权威服务器的查询，再执行一次默认递归查询，把两次结果并排记录下来，再决定是继续等缓存过期，还是回到DNS记录或服务器配置上修改。