GitHub CNAME 的作用

内容来源

• Github CNAME 的作用（Deepseek）

GitHub仓库里的CNAME文件，核心作用是告诉GitHub Pages服务器，当用户通过你的自定义域名（比如 www.example.com）访问时，应该展示哪个仓库的网站内容。

你可以把它理解为在GitHub内部为你的域名和特定仓库建立的一个“认领”和“关联”关系。它需要在你的域名解析服务商（如阿里云、Cloudflare）设置的DNS解析配合下才能正常工作。

⚙️ 如何工作

当用户在浏览器输入你的自定义域名（如 www.example.com）并访问时，流程如下：

1. DNS解析：用户的请求首先会去DNS服务器查询www.example.com指向哪里。你需要在DNS服务商那里添加一条 CNAME记录，将 www.example.com 指向 你的用户名.github.io。这一步把域名指向了GitHub的服务器。
2. 请求到达GitHub：请求到达GitHub的服务器后，服务器需要知道这个请求是给哪个仓库的。
3. 读取CNAME文件：此时，GitHub会检查所有启用了Pages的仓库，寻找根目录下名为CNAME（必须大写）的文件。
4. 匹配与响应：当GitHub在你的仓库里找到的CNAME文件内容（例如www.example.com），与用户请求的域名完全匹配时，它就知道要把这个仓库的网站内容返回给用户了。

🌐 仓库和服务商 CNAME 比较

两者的关系：分工明确的“钥匙”与“路标”。这两者缺一不可，它们共同完成从“自定义域名”到“具体 GitHub 仓库”的映射。

📌 重要补充

• 安全与唯一性：这个文件也是一种安全机制，确保只有你（仓库所有者）能决定哪个域名可以访问你的网站。如果一个域名已经被某个仓库的CNAME文件“占用”了，其他仓库就无法再使用该域名，除非你将其删除。
• 避免使用通配符：切记不要在你的DNS服务商处为GitHub Pages设置通配符记录（如 *.example.com）。因为任何GitHub用户都可以在自己的仓库里创建一个指向你任意子域名的CNAME文件，从而可能“劫持”你的子域名来托管他们的内容。
• 多域名支持：一个CNAME文件中只能包含一个域名。如果你想把多个域名都指向同一个网站，可以通过你的DNS服务商设置URL转发或使用其他DNS记录来实现。
• 静态站点生成器注意事项：如果你使用Hexo、Hugo等静态站点生成器，建议将CNAME文件放在项目的源文件夹（如source目录）下。这样每次部署时，它就会被自动复制到生成的public文件夹并推送到GitHub，避免每次部署后CNAME文件丢失的问题。
• Apex 根域名：需要注意，对于 example.com 这样的根域名（也叫 Apex 域），由于 DNS 规范限制，不能使用 CNAME 记录。你需要配置 A 记录，将其指向 GitHub 的固定 IP 地址（185.199.108.153 等四个 IP），才能实现根域名的访问。不过，这并不影响在仓库中依然需要一个内容为 example.com 的 CNAME 文件来完成授权。