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

什么是二级域名：怎样检查前后环节的依赖

二级域名是挂在主域名前面的子级名称，例如 blog.example.com 中的 blog。检查它的前后环节依赖，核心是确认三件事：解析是否指向正确主机、主机是否愿意响应这个主机名、页面内部与外部是否依赖这个主机名继续工作。只改其中一环，往往会在另一环暴露问题。

先观察：二级域名依赖分成哪几段

把一条访问链路拆开，可以看到四个前后相接的环节：

• DNS 解析：把 blog.example.com 解析到某个 IP 或 CNAME 目标。
• 服务器与证书：主机是否监听该域名，TLS 证书是否覆盖该主机名。
• 应用路由：Web 服务或框架是否把该主机名映射到正确站点目录或服务。
• 页面内引用：HTML、CSS、JS、图片、接口请求是否写死了旧主机名或相对路径。

这四段是串联关系。前一段正常不代表后一段正常，后一段报错也不一定是前一段造成的。

判断：用最小检查区分“可能原因”和“已定位原因”

不要一看到打不开就归因于 DNS。按下面顺序做，每一步只回答一个是非问题：

1. 用 dig blog.example.com 或 nslookup blog.example.com 查解析结果。有记录且指向预期目标，说明解析这一段大概率正常；无记录或指向旧 IP，就是已定位的解析问题。
2. 用 curl -I http://blog.example.com 和 curl -I https://blog.example.com 分别请求。返回 301、302、200 说明主机有响应；连接超时说明网络或监听可能有问题；证书报错说明证书覆盖范围可能不匹配。
3. 用 curl -I -H "Host: blog.example.com" http://目标IP 绕过 DNS 直接打主机。如果这样能返回正常状态，而用域名不能，问题更可能在解析或中间链路，而不是应用本身。
4. 打开页面后查看浏览器控制台和网络面板，确认 CSS、JS、图片、接口请求是否出现 404 或跨域错误。这类错误说明页面内引用这一环存在依赖断裂。

注意区分：可能原因是“证书可能不覆盖该子域”，已定位原因是“证书只签了主域名，浏览器明确报名称不匹配”。只有后者才能直接进入修复。

处理：两种常见方案的适用条件

遇到二级域名依赖问题时，常见两种处理方向，选择依据是依赖发生在哪一环。

方案一：修正指向，保留原主机名。适用于页面、外部链接、统计代码、API 调用都已经依赖 blog.example.com 的情况。做法是补 DNS 记录、补证书覆盖、在 Web 服务里增加该主机名的 server 配置。代价是每一环都要改到位，遗漏一环仍会失败。

方案二：改用其他主机名或路径，并做跳转。适用于该二级域名本身不再需要、或已有统一入口的情况。做法是在原主机名上保留 301 跳转到新地址。适用条件是你能控制原主机名的解析和响应；如果解析已经失效，跳转也无法生效。代价是外部已收录或已引用的旧地址需要时间过渡，且跳转链不宜过长。

判断依据可以概括为：外部依赖越多，越倾向保留原主机名并修正指向；外部依赖越少、且已有统一入口，越倾向跳转收敛。

复查：改完之后验证什么

修改后不要只看首页能否打开。按以下清单逐项确认：

• 解析：dig 结果与预期目标一致，且没有残留的旧记录。
• 协议：HTTP 与 HTTPS 都能返回预期状态码，证书覆盖该主机名。
• 跳转：如果做了跳转，确认是单次 301，而不是 301 套 302 的循环。
• 资源：页面内 CSS、JS、图片、接口请求没有 404，也没有混用 HTTP 与 HTTPS。
• 入口：站点地图、robots.txt、站内链接中出现的该主机名与实际一致。

需要单独说明：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。如果复查目标是搜索引擎表现，应把“能否抓取”和“是否被索引”分开核查，不同搜索引擎的支持情况需要分别确认。

下一步

选一个你实际在用的二级域名，按“解析 → 证书 → 应用路由 → 页面引用”的顺序各跑一条检查命令，把第一个失败的环节记下来，再决定是修正指向还是做跳转收敛。