www.example.com和example.com时均可显示托管在GitHub Pages上的网站，并且当打开网站时，我的浏览器地址栏应该包含example.com。我的DNS服务提供商是gandi.net，它不支持ALIAS DNS记录类型。步骤1：向您的 GitHub Pages 存储库添加一个名为 CNAME 的新文件，只包含一行：您的顶级域名。
例如：
example.com
步骤2：[可选]但强烈推荐
2.1：从您的DNS配置中删除所有其他类型为A的顶级记录（前缀为@）。
2.2：如果存在第二级域名www的CNAME记录，则删除它。
步骤3：将以下5个条目添加到您的DNS配置的最顶部：
@ A 185.199.108.153
@ A 185.199.109.153
@ A 185.199.110.153
@ A 185.199.111.153
www CNAME your_github_username.github.io.
将your_github_username替换为您的实际GitHub用户名。
第四步：等待DNS更改传播。
DNS更改不会立即生效，可能需要一整天的时间来传播。
这个问题有两个方面。一个是DNS配置本身，另一个是GitHub Pages转发HTTP请求的方式。
我们需要了解一些信息才能理解GitHub在他们的文档中要表达什么。
我们感兴趣的DNS记录有两种类型：CNAME和A。
A也被称为Apex或者有时称为根目录入口。它将请求转发到指定的固定IP地址。CNAME条目将请求转发到指定的URL（实际有效的纯文本URL，而不是IP地址）。
GitHub有一个中心URL地址，接受GitHub Pages的所有DNS请求：http://username.github.io。该URL根据您所在的地理位置解析为不同的IP地址。GitHub Pages托管的网站是由简单的HTML、CSS和JS文件组成的。GitHub将这些文件分发到全球不同的服务器上。因此，当您的浏览器从欧洲发送请求时，它会从欧洲的服务器接收数据。对于来自亚洲和美国的请求也是如此。
由于DNS中的A记录必须包含IP地址，并且它们必须是185.199.108.153或185.199.109.153或185.199.110.153或185.199.111.153中的一个，因此没有办法将请求转发到位于欧洲或亚洲某处的服务器。托管在GitHub Pages上的您的网站将从中央GitHub Pages服务器下载。如果GitHub Pages DNS服务器（x.x.x.153）由于某种原因停机，那么所有使用固定GitHub Pages IP地址的自定义域都将无法访问（它们的DNS请求将无法解析）存在一定的风险。
这就是为什么GitHub强烈建议使用二级域名作为您的GitHub Pages（例如blog.example.com），或者使用支持将请求转发到URL地址（例如username.github.io）而不是固定IP地址的记录类型ALIAS的DNS服务提供商。
当your_github_username.github.io.的DNS请求被解析为IP地址（例如185.199.108.153）后，您的浏览器会向该服务器发送一个HTTP请求，并带有HTTP头部Host。以下是加载相同网站的curl示例（如果您在代理服务器后面，则这些示例可能无效）：
$> curl --header "Host: your_github_username.github.io" http://185.199.108.153/
$> curl --header "Host: www.example.com" http://185.199.108.153/
$> curl --header "Host: example.com" http://185.199.108.153/
这样GitHub Pages服务器就知道哪个用户的网站需要服务。
如果您的
CNAME文件包含example.com，但是请求的是www.example.com，GitHub Pages服务器将自动重定向HTTP请求到顶级域名。如果您的
CNAME文件包含www.example.com，但是HTTP请求头中的Host包含example.com，同样有效。
@）的CNAME记录条目？引用来自GitHub Pages文档：
警告：请不要为自定义顶级域名创建CNAME记录！ 这样做可能会导致该域上的其他服务（例如电子邮件）出现问题。