二级域名是主域名左侧的那一段，例如 api.ipipp.com 中的 api 就是一个二级域名。它通常用来区分不同的服务、环境或业务模块，比如 api 提供接口、cdn 提供静态资源、admin 提供后台管理。很多人把 www 也当作二级域名，但从域名层级来看，www 只是 ipipp.com 的一个主机记录，而 api.ipipp.com 这种形式才是典型的二级域名用法。命名的随意性会直接影响证书签发、跨子域 Cookie、SEO 收录以及运维排查效率，因此值得提前定好规范。
本文会先梳理二级域名的命名规则，再给出 DNS、Web 服务器和本地开发环境的配置示例，最后说明常见问题与注意事项。你可以根据自身项目类型选择合适的子域命名方式，避免后期因为名称混乱而付出额外迁移成本。
二级域名命名的基本规则
域名系统的每个标签都有长度限制，二级域名也不例外。单个标签最多 63 个字符，完整域名总长度不超过 253 个字符。实际使用中，二级域名不建议超过 20 个字符，否则在证书展示、监控面板、命令行输入时都会带来不便。例如 api-gateway-production 这种写法虽然合法，但过长且容易拼错；推荐使用 api-gw-prod 或 api.prod 这种更短的形式。
允许使用的字符包括小写字母 a 到 z、数字 0 到 9 和连字符 -，但不允许连字符出现在标签开头或结尾。像 -api 或 api- 都是不合法的。下划线虽然在过去的部分 DNS 服务商那里可以被解析，但很多证书机构和云平台并不认可，因此新项目不要使用下划线。大小写方面 DNS 不区分，但建议统一使用小写，避免不同系统对大小写敏感性不一致导致日志检索困难。
语义化是二级域名命名中最实用的原则。推荐使用 api、cdn、static、img、m、admin、portal、test、staging 等前缀，能让人一眼看出用途。避免使用含义模糊的 server1、server2 或过渡性词汇 temp、old、new，这些名称在项目交接时会造成理解成本。国际域名如果需要中文子域，会被转换为 punycode 编码，例如中文前缀会变成 xn-- 开头的一串字符，这会增加维护复杂度，所以一般业务不建议使用。
设置二级域名的规范做法
设置二级域名通常需要在 DNS 控制台添加解析记录。A 记录指向服务器的 IPv4 地址，CNAME 记录指向另一个域名。例如 api.ipipp.com 需要解析到 203.0.113.10，可以在 DNS 服务商处添加一条 A 记录；如果使用 CDN 或对象存储，则把 cdn.ipipp.com 通过 CNAME 指向厂商提供的域名。配置完成后可以使用 dig 或 nslookup 验证解析是否生效。
# 添加 A 记录示例 api.ipipp.com. 3600 IN A 203.0.113.10 # 添加 CNAME 记录示例 cdn.ipipp.com. 3600 IN CNAME cdn-provider.example.net.
解析记录生效后，还需要在 Web 服务器中配置虚拟主机。以 Nginx 为例，通过 server_name 指定二级域名，并在 location 中把请求反向代理到后端服务。下面的配置片段展示了 api.ipipp.com 的代理设置，同时关闭了服务器版本信息暴露。
server {
listen 80;
server_name api.ipipp.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
本地开发环境经常需要模拟二级域名。可以修改 hosts 文件，把 127.0.0.1 映射到 api.ipipp.com，然后让应用监听对应端口。如果需要任意二级域名都指向本地，可以使用 dnsmasq 或配置本地 DNS，但注意不要和真实外部域名冲突，以免测试请求泄漏到公网。证书方面，通配符证书可以覆盖 *.ipipp.com 下的所有一级子域，适合多个子域共用一个证书的场景，但申请时需要 DNS 验证。
常见问题与注意事项
很多人第一次配置子域时，会遇到 CNAME 与其他记录冲突的问题。DNS 规范规定，同一个主机记录不能同时存在 CNAME 和其他类型的记录。如果 api.ipipp.com 已经设置了 CNAME 指向网关，就不能再为它添加 A 记录或 MX 邮件记录。根域 ipipp.com 也不能设置 CNAME，因为它本身需要 SOA 和 NS 记录来维持域名的正常解析。遇到这种情况，可以把子域指向一个 A 记录，再由网关层做转发，而不是直接把子域 CNAME 到别的域名。
证书匹配范围也容易产生误解。通配符证书 *.ipipp.com 只能匹配 api.ipipp.com、cdn.ipipp.com 这一级子域，并不能匹配 a.b.ipipp.com 这种多级子域。如果业务中需要用到多级子域，要么为每一级单独申请证书，要么使用 SAN 证书把所有需要的主机名列进去。例如 certbot 申请通配符证书时，同时写入 -d ipipp.com -d *.ipipp.com 可以覆盖主域和一级子域，但多级子域仍需额外配置。
跨子域 Cookie 是身份认证里经常踩坑的地方。如果登录成功后希望所有子域共享会话，可以在设置 Cookie 时把 Domain 属性写成 ipipp.com，这样 api.ipipp.com 和 admin.ipipp.com 都能读取同一个会话。但要注意，这种方式会让会话暴露给所有子域，如果某个子域被攻破，攻击者可能拿到主域会话。安全要求较高的系统应尽量避免跨子域共享高权限 Cookie，可以改用 OAuth2 或独立会话，并通过 API 网关统一鉴权。
最后，SEO 方面子域和子目录的选择也值得提前想清楚。搜索引擎通常把子域视为相对独立的站点，子目录则继承主域权重。如果内容是主站的一部分，比如博客文章，建议使用 ipipp.com/blog 而不是 blog.ipipp.com；如果是独立的用户系统、支付后台或 API 服务，使用子域更合适。内部团队还应维护一份子域命名文档，记录每个二级域名的用途、负责人和环境，避免出现 test1、test2 这类无人认领的孤儿子域。