🧱 网站搭建全记录：从 Gitee 到 GitHub Pages 五个域名 · 踩坑· 自动化· SSH 切换

历时数天，绕过 Gitee 的认证与入口难题，在 GitHub Pages 上成功托管五个网站，并最终用 SSH 解决了网络稳定性问题。

📖 目录
1. 为什么放弃 Gitee Pages
2. GitHub Pages 完整配置流程（仓库、推送、域名绑定）
3. 自动化更新脚本设计（OpenClaw 集成）
4. SSH 切换的波折与根本原因
5. 当前稳定状态与后续建议

1️⃣ 为什么放弃 Gitee Pages

最初选择 Gitee Pages 是因为国内访问速度快、免费且支持自定义域名。但实际操作中遇到以下障碍：

❌ 入口找不到新建仓库并上传 index.html 后，“服务”菜单中始终不显示 “Gitee Pages” 选项。
❌ 实名认证卡关即使按照指引，也找不到实名认证入口，导致无法启用 Pages 服务。
❌ 根域名 CNAME 限制 DNS 解析时无法为根域名添加 CNAME 记录，只能使用 A 记录（但 GitHub Pages 推荐 CNAME），操作复杂且容易出错。
❌ 自动化部署门槛高 Gitee 免费版不支持 git push 自动触发更新，需要每次手动点击“更新”按钮，无法与 OpenClaw 的自动化流程无缝衔接。

结论：对于“长期0元 + 纯静态 + 全自动化”的需求，Gitee 的免费套餐存在较多限制，因此转向 GitHub Pages。

2️⃣ GitHub Pages 完整配置流程

GitHub Pages 对个人开发者非常友好，支持自动部署、自定义域名和免费 HTTPS，且与 Git 工作流天然集成。

2.1 创建 GitHub 仓库（五个域名各一个）

登录 GitHub，点击右上角 + → New repository。
Repository name 填写域名（如 dragonclaws.cn）。
选择 Public（公开）。
不要勾选 “Add a README file” 等初始化选项，保持仓库完全空。
点击 Create repository。重复此步骤创建其余四个域名仓库。

2.2 本地初始化并推送网站文件

以 dragonclaws.cn 为例（其他域名同理）：

# 进入本地网站目录

cd F:\website\dragonclaws.cn

# 初始化 Git 仓库

git init

# 添加所有文件并提交

git add .

git commit -m "首次提交网站文件"

# 关联远程仓库（替换 shuo65 为你的用户名）

git remote add origin https://github.com/shuo65/dragonclaws.cn.git

# 推送（注意分支名，GitHub 默认是 main）

git push -u origin main

如果遇到网络波动或远程已有初始文件，可先执行 git pull origin main --allow-unrelated-histories 合并后再推送。

2.3 在 GitHub 仓库启用 Pages 并绑定自定义域名

进入仓库 → Settings → 左侧 Pages。
在 Branch 处选择 main，目录选择 / (root)，点击 Save。
在 Custom domain 处填入 www.你的域名（例如 www.dragonclaws.cn），点击 Save。
稍等片刻，GitHub 会自动检测 DNS 并签发 HTTPS 证书。

为什么填 www 子域名？
因为大多数 DNS 服务商支持为子域名添加 CNAME 记录，而根域名通常不支持 CNAME（需要特殊配置）。使用 www 子域名可以避免根域名的复杂设置，且 GitHub 会自动为 www 子域名签发证书。如果希望根域名也能访问，可通过 DNS 的 URL 转发实现（非必须）。

2.4 DNS 解析配置（以阿里云 DNS 为例）

为每个域名添加一条 CNAME 记录：

主机记录：www

记录类型：CNAME

记录值：shuo65.github.io

TTL：默认 600

添加后等待 DNS 生效（通常几分钟到几小时）。GitHub Pages 页面会显示 “DNS check successful”。

3️⃣ 自动化更新脚本设计（OpenClaw 集成）

为了让 AI 能够根据用户要求自动修改网站内容并部署，设计了一套基于 PowerShell 脚本的更新流程。

3.1 核心脚本：`update-site.ps1`

脚本位于 F:\website\update-site.ps1，主要功能：

接收域名、文件路径、可选内容参数。
修改本地文件（如果提供了内容）。
自动提交并推送至 GitHub，内置重试机制（网络不稳定时自动等待）。
推送后验证 GitHub Pages 默认地址（https://shuo65.github.io/域名）是否返回 200，确保部署成功。

# 调用示例（已修改文件后仅提交推送）

powershell -ExecutionPolicy Bypass -File "F:\website\update-site.ps1" -Domain "dragonclaws.cn" -FilePath "index.html"

# 同时修改文件并推送

powershell -ExecutionPolicy Bypass -File "F:\website\update-site.ps1" -Domain "dragonclaws.cn" -FilePath "index.html" -Content "新内容"

3.2 让 AI 学会使用该脚本

在主模型的 AGENTS.md 中加入提示词，告知本地目录结构和调用方式，AI 便能根据自然语言指令自动修改并上传网站。

4️⃣ SSH 切换的波折与根本原因

虽然 HTTPS 推送在重试后最终成功，但国内网络下偶尔出现 Failed to connect、Recv failure 等错误。切换到 SSH 可以极大提升稳定性，但过程中遇到了意想不到的障碍。

4.1 症状

执行 git remote set-url origin git@github.com:shuo65/域名.git 后，再运行 git remote -v 看到的仍然是 HTTPS 地址，仿佛命令没有生效。

4.2 错误尝试

多次重复执行 git remote set-url，无效。
手动修改 .git/config，但保存后又被改回 HTTPS。
怀疑是 Git 版本问题、环境变量或权限问题，逐一排查无果。

4.3 最终发现根本原因

经过细致排查，发现 全局 Git 配置中存在一条 URL 重写规则：

url.https://github.com/.insteadof git@github.com:

这条规则会将所有 git@github.com: 开头的 SSH 地址自动改写为 HTTPS 地址。这是之前为了解决 HTTPS 不稳定而添加的（可能是当时建议的临时方案），但之后没有清理，导致 SSH 切换反复失败。

4.4 解决方案

# 删除该全局规则

git config --global --unset url.https://github.com/.insteadof

# 重新设置 SSH 地址

cd F:\website\dragonclaws.cn

git remote set-url origin git@github.com:shuo65/dragonclaws.cn.git

git remote -v

# 现在应显示 SSH 格式

对其他四个仓库重复上述操作，并测试推送，SSH 立即稳定工作。

⚠️ 经验教训：临时添加的 Git 全局配置（如 insteadOf）可能会长期影响后续操作，排查时应优先检查全局配置。

5️⃣ 当前稳定状态与后续建议

✅ 五个网站已全部上线，可通过 https://www.域名 访问（如 https://www.dragonclaws.cn）。
✅ GitHub Pages 工作流稳定，每次推送后自动部署。
✅ 已切换到 SSH 协议，推送速度快且极少出现网络错误。
✅ 自动化脚本 update-site.ps1 已就绪，AI 可自主完成修改→上传→验证的闭环。
✅ 全局 Git 配置已清理，不再干扰 SSH。

后续可优化方向

为根域名添加 URL 转发（使 https://域名 也能访问）。
在脚本中加入对自定义域名的验证（如访问 https://www.域名）。
将多个域名的批量更新封装成一个更智能的 AI 技能。