GitHub Pages 自定义域名配置顺序错了可能造成域名接管，先验证域名再动 DNS 是硬规则。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
GitHub Pages 自定义域名看起来只是加一条 DNS 记录，但顺序错了可能造成域名接管。GitHub 官方明确建议先验证域名，再把自定义域名添加到仓库，最后才配置 DNS；如果站点被禁用或删除而 DNS 仍指向 GitHub，别人就可能用你的子域名发布自己的内容。下面这套流程按验证、仓库设置、DNS、HTTPS 和下线的顺序排。
适用场景
- 你要把个人、组织或项目静态站从 github.io 切换到自有域名。
- 你管理多个 Pages 站点，需要防止离职或账号变更后域名被接管。
- 你想同时支持 example.com 和 www.example.com，并让 HTTPS 自动生效。
- 你准备停用某个 Pages 站点，需要安全移除 DNS 记录。
不适用场景
- 你只是临时测试 github.io 子域名，不需要自定义域名。
- 你使用企业或第三方托管服务，不适用 GitHub Pages 的 DNS 要求。
- 你无法控制 DNS 注册商或 Cloudflare 等托管商，验证和下线都做不了。
- 你的站点依赖数据库或服务端脚本，不适合静态 Pages。
准备材料
- GitHub 账号，以及目标 Pages 仓库的 Admin 权限。
- 域名注册商或 DNS 托管商的登录权限。
- 能运行 dig 或 Resolve-DnsName 的终端。
- 记录旧 DNS、旧站点和重定向目标的清单。
- 一个测试浏览器，用于验证最终页面和证书。
步骤一：先验证域名，再动 DNS
官方验证流程要求你在账户设置里添加自定义域名，系统会给出形如 `_github-pages-challenge-USERNAME.example.com` 的 TXT 记录。验证成功后，只有你的个人账号或组织才能把该域名或其直接子域名用于 Pages。这样即使仓库被删除或站点被禁用，别人也不能直接接管。
- 进入 GitHub 账号 Settings 的 Verified domains。
- 添加你的域名，并复制系统生成的 TXT 记录。
- 到 DNS 托管商添加该 TXT 记录。
- 用 dig 确认记录可见，再点击 Verify。
- 保留 TXT 记录，不要验证完就删除。
步骤二：在仓库设置里添加自定义域名
官方文档提醒，必须先把自定义域名添加到 GitHub Pages 仓库，再配置 DNS。先配置 DNS 会让域名在别人仓库上可被接管。添加后，GitHub 会生成或更新仓库根目录的 CNAME 文件。
- 进入 Pages 仓库 Settings 的 Pages 区域。
- 在 Custom domain 输入 example.com 或 blog.example.com。
- 确认页面提示域名已被验证。
- 检查仓库根目录是否出现 CNAME 文件，内容应只有你的域名。
- 不要把 CNAME 文件写成 github.io 地址。
步骤三：按 apex 或子域名配置正确 DNS
官方记录表区分 apex 和 www/子域名。apex 域 example.com 可以使用 ALIAS、ANAME 或 GitHub Pages 的四个 A 记录；www.example.com 或 blog.example.com 使用 CNAME 指向 `USERNAME.github.io` 或 `ORGANIZATION.github.io`，不要包含仓库名。把 www 也配置好，可以让 GitHub 自动处理主域名和 www 的跳转。
# apex A 记录
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
# www CNAME
www.example.com CNAME USERNAME.github.io
如果你使用 ALIAS/ANAME，只需要指向 `USERNAME.github.io`。IPv6 可以额外添加四个 AAAA 记录，但不要只依赖 AAAA。
步骤四：用 dig 验证 DNS 与 CNAME 一致性
官方建议使用 dig 检查配置。对子域名，`dig www.example.com CNAME` 应返回 `USERNAME.github.io`。对 apex，`dig example.com A` 应返回 GitHub Pages 的 IP。如果 DNS 结果指向旧主机或通配记录，要立即修正。
dig example.com A +noall +answer
dig www.example.com CNAME +noall +answer
dig _github-pages-challenge-USERNAME.example.com TXT +noall +answer
步骤五：启用并验证 Enforce HTTPS
GitHub 官方建议开启 Enforce HTTPS，为你的自定义域名提供自动证书。证书签发可能不是立即完成，需要等待几分钟到几十小时。启用后，访问 http 应跳转到 https，页面不应出现证书警告。
- 在 Pages 设置中勾选 Enforce HTTPS。
- 等待页面不再显示证书签发中。
- 用无痕浏览器访问 https://example.com 和 https://www.example.com。
- 检查 www 与 apex 是否按预期 301 跳转。
- 如果证书一直不生效，先确认 DNS 只指向 GitHub，不指向旧托管商。
步骤六：避免通配 DNS，并写清下线流程
官方警告通配符 DNS 记录即使域名已验证也有接管风险。例如你验证了 example.com，`b.a.example.com` 仍可能被通配记录影响。停用 Pages 时，先禁用自定义域名或删除 DNS 记录，再删除仓库；如果域名不再使用，应在 DNS 托管商删除 A/CNAME/ALIAS 和验证 TXT。
- 不要为 Pages 使用 `*.example.com` 通配记录。
- 站点下线前先删除或修改 DNS 记录，避免悬空解析。
- 删除仓库后检查 DNS 是否仍返回 GitHub Pages IP。
- 域名不再使用时，把验证 TXT 记录也删除。
- 在 DNS 台账里记录每个域名对应的仓库和负责人。
可复制检查表
域名：\n仓库：\n账户类型：个人 / 组织\nTXT 验证记录：\n验证状态：\n仓库 CNAME：\napex 记录：A / ALIAS / ANAME\nwww 记录：CNAME / 无\nAAAA 记录：\ndig A 结果：\ndig CNAME 结果：\nEnforce HTTPS：\nhttps://apex 状态：\nhttps://www 状态：\n通配 DNS：有 / 无\n下线负责人：实际例子：组织站点迁移时避免域名悬空
一个开源组织要把 `docs.example.org` 从旧静态托管迁到 GitHub Pages。团队先验证了 example.org，再在组织 Pages 仓库添加 `docs.example.org`，随后把 CNAME 从旧托管改为 `ORGANIZATION.github.io`。dig 确认 CNAME 后启用 Enforce HTTPS。一个月后项目归档，他们先删除 DNS CNAME，再停用 Pages，最后删除验证 TXT，DNS 不再指向 GitHub。
验收清单
- 域名已在 GitHub 账户级验证，TXT 保留。
- 自定义域名已先添加到 Pages 仓库。
- apex 使用 A/ALIAS/ANAME，www 使用 CNAME。
- dig 结果只指向 GitHub Pages。
- 没有通配 DNS 覆盖该域名。
- Enforce HTTPS 已启用，两个域名都能用 https 访问。
- 下线流程已写清，DNS 删除顺序明确。
常见坑
- 先配 DNS 再添加仓库域名，让域名暂时可以被接管。
- CNAME 指向仓库路径，例如 USER.github.io/repo。
- 只配 apex 不配 www，用户访问 www 时拿到旧页面。
- 验证 TXT 验证完就删，之后仓库删除会失去保护。
- 使用通配 DNS，子域名出现悬空。
- 删除仓库后忘记删除 DNS，域名仍解析到 GitHub Pages。
排错路径
- 自定义域名没生效：先查 CNAME 文件、仓库域名和 DNS 是否一致。
- Enforce HTTPS 一直等待：确认 apex 不指向旧主机，CNAME 不指向 apex，并等待证书签发。
- www 不跳转：给 www 添加正确 CNAME，让 GitHub 自动处理重定向。
- 验证一直失败：用 dig 查 TXT，确认记录名没有多写或少写后缀。
- 域名被其他人使用：检查仓库是否已停用，DNS 是否仍悬空，并尽快删除记录。
后续维护建议
更新日期：2026-08-16。建议每季度检查一次所有 Pages 域名的 DNS 台账、TXT 验证状态和 HTTPS 证书。仓库改名、组织转移或 DNS 托管商变更后都要重新跑一遍本清单。只要域名还指向 GitHub，即使站点暂时停用，也要保留验证记录并定期确认没有悬空解析。