故小里第一次把自己买的域名绑到 GitHub Pages 时，我以为这就是去 DNS 后台加一条记录的事。结果那晚我一边盯着“DNS check unsuccessful”的红色提示，一边在域名服务商、GitHub 设置页和一个始终打不开的页面之间反复横跳，直到第二天早上网站才被正常访问。后来我才意识到，问题不是一个，而是三个叠在一起：CNAME 文件没有出现在正确的发布分支、A 记录被旧缓存拖住、证书签发状态还卡在排队中。
这篇就把 GitHub 绑定域名涉及的全链路拆开讲清楚。内容不光是“在哪个表单填什么”，还会解释仓库里的 CNAME 文件、DNS 里的 CNAME 记录、HTTPS 证书这三者之间的关系，以及为什么很多人配置明明看起来没问题，网站却依然打不开。适合正准备给 GitHub Pages 绑定个人域名的人，也适合绑过但被各种 HTTP 404、证书警告、强制跳转折腾过的朋友。
1. 先看懂整条链路：绑定域名不是在“解析面板”里办完的一件事
1.1 GitHub Pages 的默认域名到底是怎么工作的
在绑定自定义域名之前，先搞清楚 GitHub Pages 默认域名的工作方式。每个 GitHub 账号可以有一个用户站点，地址是 username.github.io；每个仓库还能发布项目站点，地址是 username.github.io/projectname。当你访问 username.github.io 时，GitHub 收到请求后会通过 HTTP 请求头里的 Host 字段来判断你要访问的是哪一个 Pages 站点。
这里的核心点在于：所有 GitHub Pages 站点共享同一组服务器 IP，GitHub 并不是靠 IP 区分站点，而是靠 Host 头。自定义域名做的事情，本质上就是让全世界的 DNS 都知道“myblog.com 这个域名解析到 GitHub Pages 的 IP”，同时还要让 GitHub 知道“当请求里的 Host 是 myblog.com 时，请返回某个特定仓库的内容”。
所以完整的请求链路是这样的：
- 浏览器输入 myblog.com，向本地 DNS 发起解析请求。
- 本地 DNS 沿着 DNS 体系找到你域名服务商那里的解析记录。
- 解析记录返回 GitHub Pages 的 IP 地址。
- 浏览器向该 IP 发起 HTTP 请求，请求头里带着
Host: myblog.com。 - GitHub 的边缘节点看到 Host 是 myblog.com，会去查找哪个 Pages 站点的发布内容里带有对应的身份标识。
- 找到后，返回该仓库的静态文件。
这六个环节里，第 3 步由域名服务商的 A 记录或 CNAME 记录决定，第 5 步由仓库里一个名为 CNAME 的文件决定。两件事都做对，域名才能真正打开。这就是为什么很多新手只改了 DNS，却在 GitHub 这边始终验证不过。
1.2 三件“同名不同物”的事：CNAME 文件、CNAME 记录、TLS 证书
绑定域名过程中最劝退新手的，是“CNAME”这个词出现了好几次，每次含义还都不一样。
第一是仓库根目录里的 CNAME 文件。它是一个没有扩展名的纯文本文件，内容是你要绑定的域名。GitHub Pages 发布站点时会把整个仓库的内容作为静态站点输出，CNAME 文件也会出现在站点根目录。它的作用是告诉 GitHub：“这个站点归属的用户，认可 myblog.com 这个域名。”
第二是 DNS 服务商面板里的 CNAME 记录。这是 DNS 体系里的一种记录类型，作用是把一个子域名指向另一个域名，例如把 www.myblog.com 指向 username.github.io。它解决的是“浏览器该访问哪个 IP”的问题。
第三是 TLS 证书。当你配置好自定义域名后，GitHub 会自动向公共 CA 申请该域名的证书，以保证 HTTPS 访问正常。证书签发的前提是 GitHub 能确认你确实控制这个域名，而确认方式就是看 D