我来帮你逐个解决这两个GitHub Pages的404问题，都是实际运维中踩过的常见坑，咱们一步步来：

这个问题通常是DNS配置、SSL模式或缓存干扰导致的，按以下步骤排查：

• 第一步：确认GitHub Pages的域名验证状态
  先打开你的个人站点仓库（比如username.github.io）的「Settings → Pages」，检查自定义域名是否已正确填写，并且旁边有绿色的验证通过标识。如果没验证，按照提示添加TXT记录到Cloudflare完成域名验证。

• 第二步：核对Cloudflare的DNS记录
  根据你用的域名类型调整：

  • 根域名（如example.com）：添加4条A记录，分别指向GitHub Pages官方IP：185.199.108.153、185.199.109.153、185.199.110.153、185.199.111.153，并且暂时关闭Cloudflare的橙色云（设为DNS only模式），等GitHub解析生效后再打开代理。
  • 子域名（如blog.example.com）：添加CNAME记录，目标指向username.github.io，橙色云可保持开启状态。

• 第三步：调整Cloudflare的SSL/TLS模式
  进入Cloudflare后台的「SSL/TLS → 概述」，把模式设置为**「完全（Full）」**：不要用「严格（Strict）」（GitHub Pages的SSL证书针对github.io，严格模式会触发证书不匹配），也不要关闭SSL（会导致HTTPS访问异常）。

• 第四步：清除缓存并测试
  去Cloudflare的「缓存 → 配置」选择「清除所有缓存」，如果还是404，暂时关闭所有DNS记录的代理（橙色云变灰），直接访问域名看是否正常。如果正常，再逐步打开代理并排查Cloudflare的页面规则是否冲突。

这个问题的核心是GitHub Pages的优先级规则：个人站点（username.github.io）的CNAME文件会覆盖同账号下所有其他项目的Pages请求——GitHub会把所有指向你账号的Pages流量（包括repo-b.github.io）都重定向到CNAME里的自定义域名，但Repo B并没有在这个域名下配置对应路径，所以返回404。

推荐两种解决方式：

场景A：给Repo B用子域名访问（最省心） #

比如个人站点用example.com，给Repo B配置project.example.com：

• 打开Repo B的「Settings → Pages」，在「自定义域名」栏填写project.example.com，点击保存后GitHub会自动生成CNAME文件（如果没自动生成，手动创建一个内容为project.example.com的文件提交）。
• 去Cloudflare添加一条CNAME记录：主机名填project，目标填username.github.io，橙色云保持开启。
• 等待DNS生效后，project.example.com就能正常访问Repo B的Pages了。

场景B：给Repo B用根域名的子路径访问（如example.com/repo-b） #

这种方式需要修改个人站点的配置：

• 先删除个人站点仓库里的CNAME文件，或者把自定义域名改成其他（比如blog.example.com），解除GitHub的全局重定向规则。
• 在个人站点仓库中，通过Git子模块（git submodule add https://github.com/your-username/repo-b.git repo-b）或手动复制的方式，把Repo B的内容放到repo-b目录下并提交。
• 等待个人站点重新构建后，访问example.com/repo-b就能看到Repo B的内容，但需要手动维护子路径的内容同步。

内容的提问来源于stack exchange，提问作者Alex Wang