如何以这样的方式配置DNS服务提供商,以便向两者请求www.example.com
并example.com
显示在GitHub Pages服务器上托管的网站?我的浏览器地址栏应包含example.com
网站打开时的内容.
我的DNS服务提供商是gandi.net
.它不支持ALIAS
DNS记录类型.
Jay*_*kov 101
步骤1:将新文件添加CNAME
到仅包含一行的GitHub页面存储库:您的顶级域名.
例如:
example.com
Run Code Online (Sandbox Code Playgroud)
第2步:[可选]但强烈推荐
2.1:A
从DNS配置中删除所有其他类型的顶级记录(带有@前缀).
2.2:删除CNAME
第二级域的记录(www
如果存在).
第3步:将这3个条目添加到DNS配置的最顶层:
@ A 192.30.252.153
@ A 192.30.252.154
www CNAME your_github_username.github.io.
Run Code Online (Sandbox Code Playgroud)
替换your_github_username
为您的实际GitHub用户名.
第4步:等待DNS更改传播.
DNS更改无法立即生效.它们可能需要一整天才能传播.
这个问题有两个方面.一个是DNS配置本身.另一个是GitHub Pages转发HTTP请求的方式.
我们需要了解一些事情,以了解GitHub在他们的文档中试图说些什么.
我们感兴趣的有两种类型的DNS记录:CNAME
和A
.
A
也被称为Apex
或有时被称为root entry
.它将请求转发到指定的固定 IP地址.CNAME
条目将请求转发到指定的URL(实际有效的纯文本URL,而不是IP地址).
GitHub有一个中心URL地址,它接受GitHub页面的所有DNS请求:http://username.github.io
.该URL根据您的地理位置解析为不同的IP地址.托管在GitHub上的页面的网站是一个简单的集合HTML
,CSS
和JS
文件.GitHub将这些文件分发到全球的不同服务器.因此,当您的浏览器从欧洲发送请求时,它会从欧洲的服务器接收数据.这同样适用于亚洲和美国的要求.
由于A
DNS中的记录必须包含IP地址,并且它们必须是192.30.252.153
或者192.30.252.154
,因此无法将请求转发到位于欧洲或亚洲某个地方的服务器.您在GitHub Pages上托管的网站将从中央GitHub Pages服务器下载.如果由于某种原因两个GitHub页面DNS服务器(x.x.x.153
和x.x.x.154
)都将关闭,则存在一个小风险,所有使用固定GitHub页面IP地址的自定义域将无法访问(其DNS请求将无法解析).
这就是为什么GitHub强烈建议为您的GitHub页面使用二级域名(例如blog.example.com
)或使用支持记录类型ALIAS
作为A
记录的DNS服务提供商,但转发请求到URL地址(例如username.github.io
)而不是固定IP地址.
在将DNS请求your_github_username.github.io.
解析为IP地址后,例如,192.30.252.153
您的浏览器使用HTTP标头向该服务器发送HTTP请求Host
.下面是curl
加载同一网站的示例(如果您在代理服务器后面,这些示例可能不起作用):
$> curl --header "Host: your_github_username.github.io" http://192.30.252.153/
$> curl --header "Host: www.example.com" http://192.30.252.153/
$> curl --header "Host: example.com" http://192.30.252.153/
Run Code Online (Sandbox Code Playgroud)
通过这种方式,GitHub Pages服务器可以知道要服务的用户网站.
如果您的
CNAME
文件包含example.com
但是www.example.com
被请求,GitHub Pages服务器将自动将HTTP请求重定向到顶级域.如果您的
CNAME
文件包含www.example.com
但Host
HTTP请求中的标头包含,则同样有效example.com
.
CNAME
接受顶级请求(@
)的记录条目?引自GitHub Pages文档:
警告:不要为自定义顶点域创建CNAME记录!这样做可能会导致该域上的其他服务(例如电子邮件)出现问题.