给个人博客申请 is-a.dev 域名：从 Fork、PR 到 GitHub Pages 配置

is-a.dev 为符合条件的个人及非商业开发相关网站提供子域名，申请和后续修改通过 GitHub Pull Request 审核。

这个博客也列出了 zjy.is-a.dev 地址。我的 register 仓库是 is-a-dev/register 的 Fork。申请成功以后，还要让域名指向网站，并在托管平台上完成绑定；这几个步骤缺一不可。

图 1：来自注册仓库的 is-a.dev 项目横幅。

先有一个内容完整的网站

官方 Quickstart 要求申请前已有基本完整、符合范围的网站。先阅读最新要求和服务条款，再决定是否适合申请。

申请规则可能调整，填写 JSON 和提交前以官方文档及上游仓库为准。

让申请可以被审核

基本流程是在上游注册仓库创建 Fork，在 domains/ 中添加对应 JSON 文件，再提交 PR。文件名表示希望申请的子域名。

保留官方 PR 模板，提供要求的网站信息，并持续查看审核意见。本地提交成功、推送到自己的 Fork，都不等于域名已经获批。

维护者会检查网站和配置，合并时间并不固定。逐项核对 JSON 字段与目标地址，收到修改意见后在同一个 PR 中更新。

以 GitHub Pages 为例准备 JSON

假设 GitHub 用户名是 yourname，想申请 yourname.is-a.dev。在自己的 Fork 中打开 domains/，新建 yourname.json。下面展示的是 GitHub Pages 官方配置示例的结构，用户名和目标都要替换成自己的实际信息：

1
2
3
4
5
6
7
8


{
  "owner": {
    "username": "yourname"
  },
  "records": {
    "CNAME": "yourname.github.io"
  }
}

文件名决定申请哪个子域名，owner.username 表示 GitHub 账号，records.CNAME 则是网站主机名。这三者的用途不同，不要把自己的文章链接放进 owner，也不要把仓库的 GitHub 页面地址当成站点主机名。JSON 要使用英文双引号，最后一个字段后面没有多余逗号，代码里也不能直接加入注释。

提交前查看上游是否已经存在同名文件，并读当前的命名要求；上面的 yourname 是占位符，不代表这个名字一定可用。目标网站应先能通过原始地址打开，内容、导航和主要页面都已经有了，再申请新的入口，审核者也更容易理解它的用途。

PR 应该提交到上游，而不是自己的 Fork

保存文件后，在 GitHub 中检查差异只包含自己要申请的 JSON，再使用 Contribute → Open pull request 等入口。创建页面要核对目标仓库是 is-a-dev/register，来源才是自己的 Fork；如果把目标也选成自己，提交成功仍不会进入上游审核。

保留模板并填写它要求的信息，附上网站链接和截图。截图应当让人看出这是一个已经可以使用的网站，不要只提供空白首页或建设中的占位图。所有提交都会公开，联系信息也应选择适合公开的内容，不要把凭据或无关私人资料贴进描述。

收到修改意见以后，在同一个分支更新 JSON，原来的 PR 会跟着更新。先检查反馈指向哪一行、哪个字段，再修改；不必为了一个小更正另外开一条申请。通过自动检查也只是满足格式等检查，域名是否被接受仍要等维护者审核并合并。

DNS 解析和 URL 跳转是两件事

DNS 记录帮助域名找到对应服务，通常不能把 /zh/ 这样的网页路径放进目标。CNAME 的目标是主机名，也不是带 https:// 的完整网址。

URL 跳转则让浏览器前往另一个地址，可以涉及路径。官方 FAQ 说明，is-a.dev 的 URL 选项属于自定义跳转机制，不是标准 DNS 记录。

例如想让 name.is-a.dev 直接显示 GitHub Pages 上的网站，就要走域名解析与 Pages 绑定；若只是希望访问者转到现有的 /zh/ 页面，则应研究官方的 URL 跳转选项。先选目标，再填写对应记录，才不会把网页路径误塞进 CNAME。

GitHub Pages 也需要配置

对于 GitHub Pages，官方平台指南给出了指向 github-username.github.io 这类主机名的 CNAME 方案。注册 PR 合并后，还要在网站发布仓库的 Pages 设置中填写自定义域名，并在可用后启用 HTTPS。如果网站由 Hugo 自动部署，也要把域名配置保留在源码或构建流程中，让下一次发布继续使用它。

域名所有权验证又是独立步骤，可能要求在验证主机名添加 TXT。不能因为托管平台要求验证，就把互不兼容的记录类型直接堆在同一个 CNAME 主机名上，应按平台指南处理。

Hugo 部署时，源码和发布结果要一起考虑

Hugo 项目的源码仓库与最终 GitHub Pages 发布仓库，可能不是同一个。填写 Pages 自定义域名时，应到实际发布网站的仓库；修改 Hugo 的站点地址时，则应到源码配置。先把“哪里写文章”和“哪里提供网站”分清，能避免在错误仓库里反复设置。

域名确定以后，检查 Hugo 的 baseURL 和部署流程怎样生成站点地址。如果需要随发布保留 CNAME 文件，应把它放到会进入最终输出的源码位置或构建步骤中，而不是只在一次构建的 public/ 里手动创建。具体做法要配合自己的 Pages 部署方式，不能只照抄另一个项目的目录。

改好以后进行一次正常构建，打开中英文首页、文章和图片，再检查语言切换与 RSS。只更改域名时，原来的文章路径可以继续使用；没有必要把已经分享过的 slug 也一起改掉。若发现部分链接还跳回旧域名，先追查配置或正文中的绝对链接，再决定改哪里。

分层检查是否成功

可以分别检查 PR 是否合并、DNS 是否解析、Pages 是否绑定、证书是否签发，以及页面实际返回什么。404、证书错误和重定向循环不是同一种问题，不宜只反复刷新首页。

以 name.is-a.dev 为例：如果 PR 还没合并，先回到审核页面处理意见；如果已经合并，却仍打不开，先核对提交的目标主机名，再查看 Pages 是否接受了这个自定义域名。能打开 HTTP、却不能使用 HTTPS 时，检查 Pages 的证书状态，而不是继续改文章链接。若打开后到了错误页面，再看站点构建出来的首页和重定向规则。每次只调整一层，比较容易找到问题。

双语博客还要打开两种语言路径，检查文章链接、RSS 和语言切换。首页能显示，不代表所有内部地址都正确。

确认新地址可用后，可以把它作为分享地址；原有的 github.io 地址仍值得保留作诊断入口。以后更换托管方式，也要同时检查注册仓库里的记录和新平台的自定义域名设置，单独改其中一处可能导致解析到了旧网站，或新网站拒绝这个域名。

后续更新或删除也要按注册流程处理。切换新域名时，保留原始托管地址，便于核对访问结果。博客整体 Hugo 结构可以看 Liquid Stack，服务最新要求则以官方文档为准。