想让不同业务或服务用独立且易记的地址访问,子域名是常用手段,比如用 shop.example.com 放商城、用 docs.example.com 放文档。它的生效依赖 DNS 系统,配置本身并不复杂,难点在于理解记录类型和避开一些隐形陷阱。这篇指南会带你走完从原理到实操的全过程,并梳理出高频踩坑点。
浏览器输入子域名后,先由本地 DNS 递归查询,最终找到该域名所属的权威服务器。权限服务器上存放着主域名的“区域文件”,里面定义了所有子域名的解析规则。你需要的操作,就是在托管主域的 DNS 管理后台里,为指定前缀添加一条记录。
决定用哪条记录,是这一步的核心。最常见的两条必须分清:
注意:CNAME 规则和该子域名上的 MX 邮件记录或 TXT 验证记录存在冲突,无法共存。若碰上这种要兼顾的情况,优先改用 A 记录指向邮件服务器 IP。
别急着打开后台,先核对下面三点,能省去很多折返。
各服务商界面虽有差异,但核心字段和操作顺序一致。按以下步骤执行即可:
实际操作中,一半的问题出在“看起来配了但就是不通”。这里整理了几个常见原因与排查思路。
同一子域名下,CNAME 与 MX、TXT 记录无法共存。若既想收邮件又想用 CDN,可以尝试将主服务改用 A 记录,邮件服务则用子域名 mx.example.com 单独解析。这类问题在配置时后台通常有报错提示,第一时间查看即可。
部分用户在“主机记录”栏直接填写完整域名,比如填成 www.example.com。正确写法是去掉主域名部分,只写 @ 之外的前缀。另外,想为域名本身添加解析时用 @ 作为主机记录,而不是留空,这也会导致意外错误。
浏览器端有本地缓存,服务器端有递归缓存。配置完成后建议先用命令行工具 nslookup example.com 查询对外解析结果,确认返回的 IP 与预期一致。若返回正确但仍无法访问,问题通常不在 DNS,而是在服务器本身的 Nginx、防火墙或安全组配置上。
一个小技巧:配置完成后,可以在不同网络环境(如手机 4G 网络)下测试,这样可以有效排除本地缓存因素。
通常在几分钟到半小时内生效,受 TTL 值和上级节点刷新速度影响。若超过 24 小时仍未生效,建议检查记录值是否填写正确,或联系 DNS 服务商确认是否存在合规审查。
有稳定且唯一的公网 IP,优先选 A 记录,它更直接且不会与邮件记录冲突。当服务地址可能由平台动态变更,或需要接入多节点 CDN 时,选用 CNAME 会更适合,因为它无需关注目标 IP 变化。
在命令行执行 ping 命令或 nslookup 命令即可查看解析结果。若返回的 IP 与配置一致,说明 DNS 已生效。若返回不一致或超时,可尝试更换 DNS 服务器(如 119.29.29.29)再查一次,以排除本地运营商缓存干扰。
子域名解析本质上就是理解 A 与 CNAME 的区别,并规范填写主机记录和记录值。建议你在正式配置前,先在测试子域名上演练一遍,再应用到生产环境。养成每次变更后记录 TTL 和时间点的习惯,能让日后排障事半功倍