上周三下午运营同学在群里甩过来一句“新活动页要单独挂个三级域名今天下班前能上线吗”我打开解析控制台看了一眼发现域名列表里已经躺着七八条长得差不多的记录主机记录那一栏有的填着a有的填着完整的a.example.com还有一条是*。这就是三级域名这件事最真实的现场概念上人人都会说真到设置三级域名这一步填错一个字段就能让你排查一下午。这篇就把这块拆开讲透——域名层级到底怎么数、什么场景下值得开一个三级域名、解析控制台里每一栏到底填什么、解析通了之后还有哪些坑在等着以及不生效时该按什么顺序去查。不管你是刚接手域名管理的新手还是已经配过几十条记录但偶尔还会被“生效慢”折磨的老手下面这些内容都能直接拿去用。1. 域名层级到底怎么数从右往左一个点一层1.1 “三级域名”真正的判定规则想搞清楚三级域名是什么得先接受一个事实域名的层级是从右往左读的每个点代表往下走一层。example.com里com是最右边的一层example是它下面的一层。再往下加a变成a.example.com这个a就是又一层。严格按 DNS 的标签层级去数a.example.com已经是第三层了。但麻烦在于行业里同时流行着两套数法。一套是“严格 DNS 数法”从最右边的顶级域开始数第一层另一套是“建站圈习惯数法”把你自己花钱注册的那个example.com当成“一级域名”或者叫“主域名”它下面挂的www.example.com、api.example.com统统叫“二级域名”再往下一层的b.a.example.com才叫“三级域名”。这两套数法整整差了一层于是同样一句“给我开个三级域名”两个人脑子里想的可能完全不是同一个东西。我的处理办法很土但极其有效永远不要用“几级”来沟通直接让对方写出完整的域名。“我要v2.api.example.com”这句话没有任何歧义“我要个三级域名”这句话需要再问三轮。这个习惯帮我省掉的返工时间比任何工具都多。1.2 www 到底算不算三级域名这件老事www.example.com是最容易引发争论的一个。按严格 DNS 数法它确实是三层按建站圈习惯它是标准的“二级域名”。这个争论没有意义因为实际工作中没人在乎它叫什么大家在乎的是它是一条独立的主机记录需要在解析控制台单独配服务器需要单独识别证书需要能覆盖它。真正需要留意的是另一个细节——很多人以为“域名解析里默认就有www”其实并没有。example.com能打开不代表www.example.com能打开这两条记录是彼此独立的。新建站点时如果只配了没配www用户手动敲上www就会打不开而这个错误在移动端浏览器里因为会自动补全或隐藏前缀往往被藏得很好直到有人从电脑上访问才发现。提示接手一个陌生域名时第一件事是把、www和现有的通配记录都列一遍看清楚哪些是显式配置的、哪些是靠泛解析兜住的这比看任何文档都快。1.3 顶级域、主域、子域这几个词的口语混用再补一层概念上的澄清能省掉很多沟通成本。com、net这类叫顶级域这个没有争议。你注册的example.com通常被叫作主域名、根域名或者裸域口语里也常被叫成“一级域名”。它下面派生出来的所有东西都是子域。“子域”是个相对概念而不是绝对概念对example.com来说api.example.com是子域对api.example.com来说v2.api.example.com也是子域。所以在技术语境里“子域”这个词永远要跟着一个参照物。而“三级域名”这个词本身在口语中往往只是“我要在主域下面再开一个独立入口”的代名词跟它到底是第几层关系不大。理解到这一层你在跟产品、运营、客户对接时就不会被名词绕进去能直接把话题拉回到“完整域名是什么、指向哪个地址、要不要独立证书”这三个真问题上。2. 什么情况下真的值得开一个三级域名2.1 独立项目但不想再买域名最常见的动机就是这个一个新项目、一个新活动页、一套给客户演示的独立环境域名是现成的直接在主域下面切一块出来用成本为零配置只要两分钟。相比之下重新注册一个域名要花钱、要重新做解析、要重新签证书、还要重新积累信任度对小项目来说完全不划算。但“能省”不等于“该省”。判断标准其实很简单这个东西要不要长期独立存在、要不要独立品推、要不要独立于主站做安全隔离。如果答案是肯定的尤其是涉及对外品牌露出或者需要独立做安全策略比如让搜索引擎只收录主站、不让子站参与那还是老老实实注册一个独立域名更省心。子域和主域共享同一个注册主体和同一套解析权限一旦主域的解析账号出问题所有子域一起受影响这个耦合关系在小项目上无所谓在关键业务上就是风险。2.2 分环境、分区域、分租户的命名需求真正把三级域名用出价值的场景是用命名表达结构。典型的几种玩法分环境dev.example.com、staging.example.com、pre.example.com一套代码三套环境靠域名区分比在路径里塞/dev/干净得多。分服务api.example.com、static.example.com、img.example.com静态资源单独走一个子域方便单独配缓存策略和 CDN。分租户client-a.example.com、client-b.example.com多租户系统里给每个客户一个入口客户看到的地址自带品牌感。分地域cn.example.com、sg.example.com配合就近接入做调度。这些场景有一个共同点每一个子域在浏览器眼里都是一个完全独立的站点。这句话是理解后面所有坑的钥匙——Cookie 不共享、localStorage 不共享、CORS 要额外配、证书要能覆盖、缓存要各管各的。你在享受“独立”带来的好处时也在承担“独立”带来的割裂成本。2.3 什么时候该止步子域、独立域名与路径的取舍三种做法各有适用边界我用一张表把它摆清楚比讲一堆道理直观方案成本隔离性适合的场景主要代价同一域名下的路径/project最低无内部工具、临时页面Cookie 全站共享无法独立部署主域下的子域p.example.com低中等独立项目、独立环境、静态资源证书、CORS、收录需单独处理独立域名project.com高高对外品牌、需要独立信任体系注册、解析、证书全套重来我踩过最典型的一次坑是在一个需要完全隔离登录态的演示环境上偷懒用了子域。结果主站的登录 Cookie 是设在.example.com上的演示环境一打开用户就是已登录状态演示数据直接被主站身份带出来了。那次之后我给所有“要给外部看”的环境都换成了独立域名省下的那点成本远不够填坑。3. 把三级域名解析出来控制台上到底填什么3.1 主机记录这一栏的填法与原理解释解析控制台里最容易填错的一栏中文通常叫“主机记录”英文叫 Host 或者 Record Name。这一栏填的不是完整域名而是相对于当前域名的那一段前缀。这是所有错误的源头。规则如下填指向example.com本身。填www指向www.example.com。填a指向a.example.com。填b.a指向b.a.example.com。注意绝大多数解析服务商支持在主机记录里写多级前缀用点分隔。我见过的最惨烈的一次事故是有人在主机记录里填了b.a.example.com平台没有做严格校验最终生成了一条b.a.example.com.example.com的记录。现象是“解析怎么都不生效”因为那条记录确实生效了只是它生效在了一个根本没人访问的名字上。所以填完之后一定要回到记录列表看一眼平台拼出来的“完整域名”预览那一行小字比什么都可靠。3.2 A、CNAME、AAAA 到底怎么选记录类型选错是第二高频问题。三句话记住判断标准A 记录指向一个 IPv4 地址。目标服务器有固定 IP 时用它最直接、查询链最短。AAAA 记录指向一个 IPv6 地址。只有在你确实需要 IPv6 访问时才配配错了不会报错只会让部分用户的访问走不通。CNAME 记录指向另一个域名由那个域名再继续解析。适合目标地址会变的情况比如指向某个加速服务商分配的域名、指向另一个已有域名。CNAME 有两个必须知道的约束。第一同一条主机记录上不能既有 CNAME 又有其他记录这是协议层面的限制不是平台刁难。第二根域配 CNAME 在标准上是不被推荐的虽然部分平台提供了别名方案来绕开但子域完全没这个顾虑——a.example.com这类三级域名反而是最适合用 CNAME 的因为它的目标地址很可能由上游服务商动态分配写死 IP 就是给自己埋雷。3.3 泛解析与批量下发方便与风险并存泛解析就是那条*记录。配上之后任何未被显式定义的主机名都会命中它。好处很明显给每个客户开client-x.example.com时不用一条条加省事。坏处同样明显它会把所有拼错的、扫描器随机生成的、恶意构造的主机名全部接住你的服务器日志里会突然出现大量莫名其妙的 Host 头证书申请也容易因为域名验证打到错误的地方。泛解析还有两个容易误解的细节值得单独拎出来通配符只匹配一层。*.example.com能匹配a.example.com但匹配不到b.a.example.com。想让第三层也被兜住得单独再配一条*.a.example.com。这个点我见过至少三个人栽在上面现象是“我明明配了泛解析为什么这个域名还是不通”。显式记录优先级高于通配符。有了*.example.com之后再单独加一条api.example.com指向新地址是可以正常覆盖的不需要删掉通配记录。这条特性在做灰度切换时特别好用。我的实际做法是泛解析只在确实需要动态生成子域的场景多租户、客户自助建站打开其余情况一律显式配置。多打几条记录的麻烦远小于泛解析带来的日志噪音和误接入风险。3.4 TTL 该给多少以及生效节奏的心理预期TTL 是这条记录在递归解析器里能被缓存多久单位秒。填得太长改完要等很久填得太短每次访问都要回源查询解析压力大。我的经验值是这样的稳定运行的业务记录600 到 3600 秒够用且省查询。即将做迁移或切换的记录提前一天改成 60 到 120 秒切换当天就能快速生效。切换完成、稳定运行一周后再调回正常值。需要提醒的是TTL 改小只对之后的新查询生效已经缓存了旧记录的人还是得等旧 TTL 到期。所以正确的操作顺序是“先改小 TTL等一个旧 TTL 周期过去再改目标地址”而不是反过来。反过来做的话你会经历一段“一半用户访问新地址、一半访问旧地址”的混乱期而且这段时间的长度完全不受你控制。4. 解析通了之后才是真活证书、跨域与作用域4.1 通配符证书覆盖不到的那一层证书这块的坑极其隐蔽因为它的表现是“浏览器报警告”而不是“打不开”很多人会误以为是配置没生效。核心规则只有一条一张*.example.com的通配符证书只覆盖一层子域。具体来说*.example.com能覆盖a.example.com、www.example.com、api.example.com但覆盖不到b.a.example.com。如果你的三级域名是这种两层嵌套的形式要么单独给它签一张证书要么再签一张*.a.example.com的通配符。我在一个多租户项目上就吃过这个亏租户域名是t1.client.example.com这种三层结构上线当天全量报警最后是临时给每个租户单独签发才顶过去的事后补了一套自动签发的流程。提示证书的域名匹配是精确到标签的字符串比对不做任何模糊匹配。申请之前把完整域名写下来对着证书的覆盖范围逐字对一遍比事后看浏览器报错快得多。4.2 同源策略会怎么拦住你a.example.com和b.example.com在浏览器眼里是两个完全不同的源哪怕它们指向同一台服务器、同一个 IP、同一个端口。所以下面这几件事都会出问题页面在a.example.com接口在api.example.com跨域请求会被拦需要在服务端返回正确的跨域响应头。跨域请求如果要带 Cookie服务端的响应头里必须明确允许携带凭证且前端请求也要显式打开对应选项两边都得写少一边都不行。预检请求会额外多一次往返对首屏性能有实际影响接口拆分得越细这个成本越明显。所以“要不要把接口拆到独立子域”这个问题答案不是看架构图上好不好看而是看你能不能接受这套跨域成本。同域路径下的接口调用没有任何跨域问题拆成子域之后每一处调用都要多一层配置。小项目上这个成本经常被低估。4.3 Cookie 与本地存储的作用域边界Cookie 的作用域由 Domain 属性决定。设置在.example.com上的 Cookie会被a.example.com、b.a.example.com一起带上设置在a.example.com上的 Cookie只在a.example.com生效兄弟子域拿不到。这个特性可以用来做隔离也可以用来制造事故。需要特别注意三点主站如果把 Cookie 设在.example.com上很多老项目为了省事都这么干那么所有子域都会自动带上包括你并不想让它带上的那些。这个 Cookie 的体积会计入每一次子域请求的头部白白增加流量。localStorage 和 sessionStorage 是按源隔离且完全不共享的子域之间没有任何办法互读只能靠 postMessage 之类的机制通信用之前要想清楚。早期靠设置document.domain来实现跨子域互通的方案现在在多数现代浏览器里已经不可靠了不要再用。新项目一律走正规的跨域配置。5. 不生效的时候按这个顺序查一条完整的排错链路5.1 从本地到权威的四级验证“域名配了但不生效”是最高频的问题我的固定动作是四级验证从近到远一层层排除本地缓存先在命令行查一次解析结果。如果本地结果和预期不符别急着下结论因为本机可能缓存了旧结果。换一个递归解析器把查询指向一个公共递归服务如果结果变了说明是缓存问题如果结果一样继续往下。直接问权威服务器从域名信息里查出该域名的权威服务器地址直接向它查询。这一步拿到的是“最真实”的配置如果权威返回是对的说明配置本身没问题问题出在传播和缓存上。看完整链路用逐级追踪的方式把整条解析路径打出来能看到每一层是谁在回答、卡在哪一步。这四步走完问题基本就定位了是记录没配上、还是配上了没传播、还是传播了但本地缓存没刷新。绝大多数“解析不生效”其实是第二步就解决的问题只是没换解析器验证而已。5.2 缓存这一层藏着的连环坑缓存不止一层而且长度各不相同这是很多人忽略的地方。第一层是浏览器自己的 DNS 缓存第二层是本机系统的缓存第三层是运营商或公共递归解析器的缓存第四层才是权威服务器。你改的是第四层前三层全都在按旧值回答。还有一个更隐蔽的缓存层如果前面挂了内容分发网络那么节点上缓存的是整个响应内容而不只是解析结果改了源站配置节点不刷新照样看不到变化。这种情况要显式做一次缓存刷新别指望它自己过期。排查时的实用技巧在请求命令里强制指定解析地址绕过所有 DNS 缓存直接验证服务器端的配置对不对。这一步能瞬间把“解析问题”和“服务端问题”切开curl -I --resolve a.example.com:443:203.0.113.10 https://a.example.com/如果这条命令能拿到正常的响应头而直接访问域名不行那问题百分百在解析链路上服务器配置是无辜的。反过来如果这条也失败那就别在解析上耗时间了去看服务器。5.3 解析对了但页面打不开的几种情况解析通了、ping有响应、但页面还是不正常通常是下面这几类原因按出现频率排服务器没配这个域名。一台服务器上跑了多个站点靠请求头里的主机名区分。如果新的三级域名没有加进站点的域名列表请求会落到默认站点看到的可能是别人的页面或者一个默认欢迎页。这是“解析对但内容不对”的最常见原因。端口和协议不匹配。解析只负责把名字翻译成地址不管端口。名字对了但服务没在那监听照样连不上。证书域名不匹配。前面说过的那条规则表现是证书告警页面其实能打开。重定向死循环。源站把 HTTP 重定向到 HTTPS而前置的代理又把 HTTPS 重定向回 HTTP用户在两个地址之间反复跳转最后浏览器报错。防火墙或安全策略没放行新域名。有些环境按域名做白名单新域名没加进去就是不通。用curl看响应头是定位这类问题最快的手段重点看三样东西状态码、Location头、以及返回内容里的站点标识。这三个信息足以判断请求最终打到了哪台机器、哪个站点上。6. 把三级域名当资产管命名规约与后续维护6.1 提前定一套命名规则能救后面三年三级域名开得越多命名越容易失控。我现在的做法是项目一开始就把规则写死写进团队文档里环境前缀固定用dev、staging、pre不用test、uat、beta这类含义模糊的词避免同一个东西三个叫法。功能前缀用业务语义不用人名、不用缩写简写。report比rpt好report-v2比report2好。全小写、只允许字母数字和连字符不用下划线。这不是洁癖下划线在某些解析和证书校验场景下会出问题。一次性活动的域名带上时间标记比如act-2025-spring到期就删避免列表里堆一堆不知道谁在用、谁也不敢删的记录。命名规则这件事的价值在于可预测性。当所有人都能根据规则猜出某个环境的域名时沟通成本会断崖式下降也不会出现“这个域名到底是谁建的”这种灵魂拷问。6.2 收录、抓取与重复内容的处理从对外站点的角度有一个容易被忽略的事实搜索引擎把每个子域当成一个独立站点。这意味着每站的抓取配额是分开算的子域越多单个子域能分到的抓取资源越少。站点地图不继承。主站的站点地图里列的地址对子站没有任何作用需要单独提交。robots.txt不跨主机名继承。你在example.com/robots.txt里写的规则对a.example.com/robots.txt完全没有约束力。这是个经典误解很多人以为配一次就全站生效。内容重复会被判重。同样的内容同时出现在主域和子域上容易造成互相稀释。所以给对外可见的子域做规划时要提前想清楚它是“要给搜索引擎看的”还是“只给人看的”。后者最简单直接整站禁止抓取省掉所有麻烦。6.3 交接与下线没人清理的域名是最贵的负债最后一个话题有点反直觉三级域名的成本不在开的时候在关的时候。开一条记录两分钟但一条没人管的记录可能会一直挂着指向一台早就下线的服务器、一张早就过期的证书、或者一个不知道谁在用的旧接口。我现在的习惯是给每条记录打个标记记录三件事负责人、用途、预计到期时间。到期前一个月做一次巡检确认还在用就延期不用就下线。下线动作也要完整先摘掉解析观察一周确认没有流量再回收服务器和证书。提示删解析之前一定要先看访问日志。我见过不止一次“确认没人用”的域名删完之后被投诉因为那是个只在大促时才被调用的备用入口平时日志干干净净一到大促就出事。这套流程麻烦是麻烦但它能把“域名列表”从一堆历史遗留物变成一个能说清楚的资产清单。我个人在实际操作中的体会是域名管理的混乱从来不是因为技术难而是因为没人愿意在开头多花十分钟把规则定下来也没人愿意在结尾多花十分钟把东西清干净。前面那十分钟省的是后面无数次的猜测和返工。