Hexo独立域名绑定，核心是“两步走”：先将域名解析指向你的博客托管平台（如GitHub Pages、Vercel），再在Hexo博客的source目录放一个只含域名的CNAME文件，重新部署后等待解析生效即可。
很多新手把域名买回来,折腾了半天打不开,问题大多出在解析和CNAME配置上，这篇文章直接从实操角度拆解整个过程,照着做就能完成绑定。
开始之前：明确你是否具备以下三个条件
绑定域名不是单独在Hexo里改个配置就行,它需要几个环节配合。
- 一个已注册的域名：国内外服务商均可，但国内域名需要完成ICP备案才能使用80/443端口访问。
- 一个Hexo博客部署的目标平台：目前主流是GitHub Pages、Vercel、Netlify，本文以GitHub Pages为例,Vercel流程类似。
- 一个可正常访问的Hexo博客：如果你还没有部署成功,先解决部署问题再绑定域名。
第一步：解析域名到GitHub Pages
解析的作用是把你的域名“指向”存放博客的服务器，GitHub Pages的IP地址是公开且固定的，无论你的博客仓库名称是什么,都指向同一组IP。
如何添加解析记录
登录你的域名管理后台，找到“DNS解析”或“域名解析”功能，这里需要添加两条A记录,以及一条CNAME记录供某些子域名使用。
| 记录类型 | 主机记录（Name） | 记录值（Value） | TTL |
|---|---|---|---|
| A | @（或留空） | 199.108.153 | 600 |
| A | @（或留空） | 199.109.153 | 600 |
| A | @（或留空） | 199.110.153 | 600 |
| A | @（或留空） | 199.111.153 | 600 |
| CNAME | www | 你的用户名.github.io | 600 |
这里有一个关键细节：如果你希望访问“你的域名.com”和“www.你的域名.com”都能打开博客，那需要同时配置A记录和CNAME记录，如果只希望裸域名（不带www）访问,只配A记录即可。
解析时容易犯的错
- 把记录值写成“你的仓库名.github.io”，这是错误的,A记录必须写IP。
- 漏掉了四条A记录中的一条，GitHub官方要求四条都填，实际使用中少填一条也能访问,但稳定性略差。
- TTL设置过大，导致修改后长时间不生效，新手建议设置成600秒（10分钟）。
这里不需要等24小时，现在主流DNS服务商对A记录的生效时间通常在几分钟到几小时之间,你可以切换DNS查询工具确认解析状态。
第二步：在Hexo博客中创建CNAME文件
这是最容易被忽略的一步，很多人解析完域名就在浏览器输入域名，结果打不开，原因就是GitHub Pages不知道你绑定了这个域名。
具体操作路径
在Hexo博客的 source 目录下新建一个文件，文件名必须是 CNAME（无后缀名）,文件内只写入你的域名。
请确认你的目录路径如下,不要放错位置：
你的Hexo博客根目录/
├── source/
│ ├── _posts/
│ ├── CNAME ← 放在这里
│ └── ...
└── _config.ymlCNAME文件内容格式：只写一行，
www.yourdomain.com或
yourdomain.com任选一种，GitHub Pages会自行处理跳转关系，但如果你想保留统一的域名形式，建议写带www的完整域名,然后利用DNS的URL转发把裸域名转向www。
使用指令完成部署
CNAME文件创建好之后，回到Hexo根目录,依次执行以下命令：
hexo clean hexo g hexo d
部署完成后，进入你的GitHub仓库，打开 Settings → Pages，此时你会看到“Custom domain”一栏自动出现了你填写的域名，如果没出现，可以手动填一次，点击保存，同时勾选“Enforce HTTPS”强制启用HTTPS。
为什么CNAME文件总是不生效
- 文件名写错：有人会写成“cname.txt”或者“CNAME.txt”,GitHub不识别。
- 路径放置错误：放在了public目录下，部署后会被覆盖，中包含了http://或https://：CNAME文件只要裸域名,任何协议头都会导致解析失败。
第三步：配置Hexo博客根目录的_config.yml
这一步不是必需的，但推荐操作,目的是让Hexo生成站点地图和资源时可以正确识别你的新域名。
打开根目录下的 _config.yml 文件,修改url和root配置：
url: https://www.yourdomain.com root: /
如果你的博客之前部署在“https://用户名.github.io”下，这一步容易遗漏，漏掉之后，站内链接、绝对路径资源、sitemap里的URL都会指向旧的GitHub Pages地址。
修改后重新执行部署命令，用浏览器的“清除缓存并硬性重新加载”功能访问你的域名,检查是否正常。
hexo域名解析到github的操作后，如何验证是否生效
解析和部署都做完了，不能只看浏览器，要进行验证，直接在浏览器输入域名，如果出现博客首页，那说明绑定成功,但更严谨的方法是用命令行验证。
使用Ping命令测试
打开终端（Windows下是CMD或PowerShell）,输入以下命令：
ping www.yourdomain.com
如果返回的IP地址在GitHub Pages的IP段（185.199.108.153 至 185.199.111.153）,说明解析方向正确。
使用DNS查询工具测试
访问公共DNS查询网站，输入你的域名，查看A记录和CNAME记录是否与解析设置一致，不同DNS服务商之间的生效时间可能有差异，如果发现某地DNS还没有返回新记录,可以等待1小时再查。
用curl检查HTTP响应头
这个方式可以直接判断请求是否到达GitHub服务器,在终端执行：
curl -I https://www.yourdomain.com
返回状态码200，并在响应头中看到“server: GitHub.com”字段，即表示请求已被GitHub处理，如果返回404，则说明CNAME文件没有正确配置,或仓库的Pages设置未生效。
hexo博客域名绑定不生效的原因排查
大多数情况下，绑定过程不会一次成功，经常遇到的问题是能打开但样式丢失，或者彻底打不开,按照优先级排查：
页面能打开但CSS/图片全部丢失
这是路径问题,按顺序检查：
- 站点配置的url是否正确改成新域名。
- 页面源代码中的资源链接，是否由“绝对路径”构造成新域名下的路径。
- 主题配置中是否有独立的资源路径设置。
多数情况下，把 _config.yml 中的url改成新域名，root保持为“/”，重新构建部署,样式问题就能解决。
页面能直接打开但www子域名打不开
这是因为没有添加CNAME记录，GitHub Pages要求解析A记录到固定IP，然后额外添加CNAME指向你的GitHub Pages地址，如果你没有添加这条CNAME记录，www.你的域名.com则不会工作，回到DNS设置中,检查是否添加了：
CNAME www → 你的用户名.github.io注意主机记录用中文拼音打“www”，不要打成“@”，记录值不能带http协议，直接写“用户名.github.io”。
部署正常但始终出现证书错误
GitHub Pages支持自动颁发SSL证书，但需要一定时间，开启“Enforce HTTPS”后，证书的生成时间从几分钟到几小时不等，如果超过24小时仍提示证书错误，请检查CNAME文件是否同时被放置在GitHub仓库根目录和Hexo的source目录下,确保两者一致。
DNS解析已被运营商缓存导致滞留
国内部分宽带运营商对DNS缓存的时间较长，修改解析后旧IP可能持续存在一段时间，这种情况下，可以先将本机DNS改成公共DNS（如114.114.114.114或8.8.8.8），然后重新请求域名，移动网络和联通网络下的解析结果可能不一致,遇到时建议换网络测试。
使用CDN加速场景下的额外配置
如果你打算将域名的访问指向由Cloudflare等CDN加速服务托管,需要注意两点：
- 暂不能开启Cloudflare的橙色云朵代理，需先让DNS纯解析生效,确认网页能访问后再开启代理。
- 如果开启了CDN，GitHub无法自动可签发SSL证书，请先在_proxy云朵代理关闭状态下，等GitHub的证书签发成功,再开启CDN代理。
使用Hexo进行独立域名绑定需要注意的备案相关问题
如果你选择将GitHub Pages换成国内服务器，或买的是国内服务商的域名，并且博客面向中国大陆用户提供访问服务，域名必须完成ICP备案，未备案的域名在国内服务器上无法解析,强行使用会被拦截。
- 国内域名但部署在GitHub Pages：不需要备案,因为服务器在海外。
- 使用Coding Pages或Gitee Pages等国内平台：需要备案,通常涉及个人网站备案流程。
- 购买国内服务器+宝塔面板部署Hexo：必须备案,且备案期间域名不能解析到该服务器IP。
近年来，国内对个人网站的备案审查严格程度有所提升，云服务商在备案信息真实性核验环节处理时间不等，若时间紧张，可优先考虑使用海外服务器或者GitHub Pages,省去备案这一环节。
Hexo与WordPress建站绑定域名的流程差异
很多站长在换系统前会对比域名绑定难度，这里做一个简明的比较,帮你判断哪个更省心。
| 对比维度 | Hexo | WordPress |
|---|---|---|
| 建站难度 | 中，需要有命令行基础 | 低，后台界面操作 |
| 域名解析绑定复杂度 | 需要改文件名和仓库设置，手动为主 | 后台面板里直接填写域名，自动绑定生成证书 |
| 绑定后的迁移性 | 绑定配置跟随仓库，换电脑需重新部署 | 配置在数据库里，换空间后需重新调整 |
| 适合人群 | 开发者、技术博客作者 | 内容运营个人站长 |
看着WordPress省事，但一旦涉及到换服务器、换空间，需要迁移数据库和整站文件，对新手反而是个负担，Hexo的部署方式决定了它的绑定逻辑：静态文件在哪托管，域名就指向哪里，而且CNAME文件本身就起到“身份标识”的作用。
常见问答：针对购买域名后的高频问题
域名解析完成后，博客无法访问的原因是什么？
DNS缓存仍未更新，建议先清除本机DNS缓存（Windows下执行“ipconfig /flushdns”命令），二、GitHub仓库中没有CNAME文件，检查source目录和仓库根目录，三、GitHub Pages开启强制HTTPS后证书尚在申请中，排除以上三个原因后,基本可正常访问。
hexo、github pages域名设置重复修改后页面不更新，怎么处理？
重复修改域名可能引发GitHub Pages构建问题，到GitHub仓库的Settings里，将Custom domain清空，点击保存，然后再重新填入你的域名，保存后等待几分钟，同时本地仓库中重新执行hexo clean再部署一次，旧域名的跳转关系会随之移除，新域名会恢复可用状态，GitHub对同一个仓库的Pages绑定变更，有较宽的处理窗口，尤其同时开启CDN加速的场景下,不要在短时间内连续修改域名记录。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/632502.html
