Cloudflare 接 GitHub Pages 时 HTTPS 怎么配：A、CNAME 和 SSL/TLS 模式

把 GitHub Pages 绑定到自己的域名，再让 Cloudflare 接管 DNS 和 HTTPS，看起来只是填几条记录，但实际最容易卡在三个地方：根域名和 www 怎么分工、Cloudflare 的代理小云朵要不要开、SSL/TLS 模式到底选 Flexible、Full 还是 Full (strict)。

我的理解是：先把 DNS 和 GitHub Pages 绑定跑通，再决定 Cloudflare 是否代理；HTTPS 能端到端就不要退回半截加密。

先分清根域名和 www

假设域名是：

example.com
www.example.com

example.com 是根域名，也叫 apex domain；www.example.com 是子域名。

GitHub Pages 自定义域名通常有两类配置：

• 根域名用 A 记录指向 GitHub Pages 官方公布的 IPv4 地址。
• www 这类子域名用 CNAME 指向 <username>.github.io。

截至我这次核对官方文档，GitHub Pages 根域名的 A 记录是这四个：

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

如果要配 IPv6，还可以按 GitHub Pages 文档继续加 AAAA 记录。不要从旧截图里抄 IP，真正上线前最好重新打开官方文档确认一遍。

仓库里还需要 CNAME 文件

DNS 只是告诉外界域名解析到哪里。GitHub Pages 还需要知道这个 Host 应该落到哪个 Pages 站点。

所以仓库里通常要有一个 CNAME 文件，内容只写你的自定义域名，例如：

www.example.com

或者：

example.com

这个文件也可以通过 GitHub Pages 设置页面生成。关键是：DNS 记录和 GitHub Pages 后台里的 custom domain 要一致，不要 DNS 指向 www，仓库里却写根域名，自己把自己绕晕。

Cloudflare 代理开关先按目标判断

Cloudflare DNS 记录旁边的小云朵有两种状态：

• DNS only：只做解析，不经过 Cloudflare 代理。
• Proxied：流量经过 Cloudflare，浏览器看到的是 Cloudflare 边缘节点。

刚开始排查时，我更喜欢先用 DNS only 把 GitHub Pages 绑定确认跑通。等 GitHub Pages 里 custom domain、DNS check、页面访问都正常，再打开 Proxied。

这样有一个好处：如果打不开，可以先判断是 GitHub Pages 绑定问题，还是 Cloudflare 代理和证书模式问题。

SSL/TLS 模式不要乱选 Flexible

Cloudflare 的 SSL/TLS 模式大致可以先这样理解：

• Flexible：浏览器到 Cloudflare 是 HTTPS，Cloudflare 到源站是 HTTP。
• Full：浏览器到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，但源站证书可以不是公开可信证书。
• Full (strict)：浏览器到 Cloudflare 是 HTTPS，Cloudflare 到源站也是 HTTPS，并且源站证书必须有效、未过期、域名匹配。

如果源站本身支持 HTTPS，优先考虑 Full 或 Full (strict)。Flexible 看起来省事，但它会让 Cloudflare 到源站这一段退回 HTTP，容易引出重定向循环、资源协议混乱、后台地址判断错误等问题。

GitHub Pages 本身支持 HTTPS。正常情况下，如果 GitHub Pages 的自定义域名证书已经签发成功，Cloudflare 这边更应该往 Full 或 Full (strict) 方向收敛，而不是默认选 Flexible。

两种常见配置思路

第一种是保守排障流程：

1. Cloudflare 记录先用 DNS only。
2. GitHub Pages 设置 custom domain。
3. 等 DNS check 正常。
4. 在 GitHub Pages 里启用 Enforce HTTPS。
5. 访问 https://你的域名，确认页面和资源都正常。
6. 再把 Cloudflare 记录切到 Proxied。
7. Cloudflare SSL/TLS 选择 Full 或 Full (strict)。

这种方式慢一点，但每一步都能判断问题在哪。

第二种是直接走 Cloudflare 代理：

1. Cloudflare 里先配好 A / CNAME。
2. 记录开启 Proxied。
3. GitHub Pages 里绑定同一个 custom domain。
4. 等 GitHub Pages 证书状态正常。
5. Cloudflare SSL/TLS 使用 Full 或 Full (strict)。

这种方式适合你已经熟悉 GitHub Pages 和 Cloudflare 的状态提示。新手不建议一上来就把所有开关都打开，否则排错时变量太多。

根域名和 www 最好统一入口

不要让 example.com 和 www.example.com 长期显示两套入口。

常见做法是二选一：

• 根域名作为主入口，www 跳转到根域名。
• www 作为主入口，根域名跳转到 www。

GitHub Pages 后台 custom domain 一般只配置一个主域名。另一个域名如果也要访问，最好让它重定向过去，避免搜索引擎看到两个重复站点。

如果用 Cloudflare，可以用 Redirect Rules 做统一跳转。这样 SEO、分享链接和缓存都会干净一些。

出现 HTTPS 问题时按这个顺序排

如果访问异常，不要来回乱改 DNS。可以按顺序看：

1. Cloudflare 当前 NS 是否已经生效。
2. 根域名 A 记录是否是 GitHub Pages 官方当前 IP。
3. www 的 CNAME 是否指向 <username>.github.io。
4. GitHub Pages 设置页 custom domain 是否和你要访问的域名一致。
5. GitHub Pages 的 DNS check 和证书状态是否正常。
6. Cloudflare 小云朵是 DNS only 还是 Proxied。
7. Cloudflare SSL/TLS 模式是不是误用了 Flexible。
8. 浏览器报错是证书错误、重定向循环，还是页面 404。

这几步比“看到打不开就换模式”靠谱得多。

一个推荐默认值

如果只是个人静态博客或文档站，我现在会这样配：

• 根域名：A 记录指向 GitHub Pages 官方 IP。
• www：CNAME 指向 <username>.github.io。
• GitHub Pages：配置一个明确的 custom domain，并启用 HTTPS。
• Cloudflare：先 DNS only 跑通，再考虑 Proxied。
• SSL/TLS：优先 Full 或 Full (strict)，不要默认 Flexible。
• 入口：根域名和 www 只保留一个主入口，另一个做跳转。

这套思路的重点不是背某个后台截图，而是把链路拆开：DNS 负责解析，GitHub Pages 负责站点绑定和源站 HTTPS，Cloudflare 负责代理、边缘 HTTPS 和跳转规则。每一层做自己该做的事，问题就会少很多。

参考链接

• GitHub Pages 官方文档
• Cloudflare SSL/TLS 模式说明