以下是今天的折腾记录，给有同样需求的做个参考。

Vercel 不适配，转向 Zeabur

本来我想的是之前使用过 Vercel，干脆统一渠道，在资源站这里也使用 Vercel。但由于种种问题，我没有找到适配 AList 的 Vercel。

在这里，服务器我改选了 Zeabur，有一键部署的 AList 镜像，对个人博客来说免费额度够用了。

1. 首先是进入 Zeabur 网页(也可以选择国内版 Zeabur )，登录并进入控制台。

2. 接着 创建项目 -> 模板(选 AList) -> Deploy

   

   这里域名随便写，之后要改成自己的子域名。

3. 接着在服务状态这个页面中点击日志，在日志中找到 Successfully created the admin user and the initial password is 即初始管理员密码

4. 进入Zeabur 分配的域名中，并加入 /@manage 输入对应的管理员用户名和密码进入管理页面。

5. 最后在管理员页面点击 存储 -> 添加 -> 驱动选择123盘
   

123盘风控拦截，转向阿里云盘Open

由于我暂时还没有做域名备案，所有上一步我选择的时国际版的 Zeabur，所以同时只能选择国外的节点，这里123盘出现了风控的问题：

几经辗转，我选择了 阿里云盘Open。

1. 进入 AList 后台，在存储中点击添加，选择 阿里云盘Open。
2. 登录阿里云盘，选择对应文件夹并进入，在url中获取文件夹id https://www.alipan.com/drive/file/all/xxx，其中 xxx 就是文件id，天瑞对应的文件id并保存。
3. 在 zeabur 后台进入对应域名，检查是否成功

子域名设置 + Cloudflare 后台锁

子域名设置

由于第一步中我在 Zeabur 中是随便设置的域名，但是博客是独立域名indolyn.com。如果访客点击资源，但会“跳出”博客会显得这个非常业余，同时使用 Zeabur给的二级域名很容易被 DNS 污染，在这里要重新设置资源站的域名。

1. 首先是进入 Zeabur 的控制台并进入对应的项目，在网络分页中，点击 +自定域名。
2. 输入对应的子域名，次数 Zeabur 会给出一条 DNS 的的记录。在对应的域名解析中加入一条 DNS 记录即可。

Cloudflare 后台锁

实现玩域名修改我本以为后端已经万事大吉了，但是我注意到，我自己在调整网盘策略是就频繁登录后台。这显然是不安全的。

为了增加安全性，我使用了 Cloudflare 的 Zero Trust 为 AList 后台上了锁。这样，这个后台只有经过我的邮箱验证才能打开(前提是这个域名由 Cloudflare 托管)。

以下是配置步骤:

1. 登录 Cloudflare，点击左侧的 Zero Trust。如下图依次点击，这里我选择的是 Emails 策略，这样必须经过我的邮箱才能访问这个网站，同时由于之前设置的域名邮箱，这样我也没有暴露自己的真实邮箱，同时也不用担心被邮件轰炸。

2. 进入对应域名，左侧点击 Access，右侧点击启用 Zero Trust。
3. 进入页面后左侧依次点击 访问控制 -> 应用程序，右侧点击 添加应用程序，选择自托管。
4. 点击添加公共主机名，选择对应的子域名的路径(AList 这里是 @manage)，并应用第一步添加的策略。

到这里就大功告成了。

调整资源站样式

现在解决了资源站的域名问题，但资源站的样式是 AList 自带的样式，预我的博客样式不符

为了解决这个问题，我决定把 AList 的顶栏和页脚全部魔改，让它长得和我的 Butterfly 主题一模一样。

我的想法很简单：在 Hexo 里新建个页面，用 <iframe> 把 AList 网盘嵌进去。

结果折腾了一下午，心态崩了：

1. 无限弹窗：因为跨域限制，浏览器拦截了 Cookie，AList 就算登录了也一直弹窗让我重新登录。
2. 双重滚动条：博客有一个滚动条，网盘里又有一个，手机上体验极差。
3. 样式割裂：AList 自带的白色界面和我的博客风格完全不搭。

既然“硬塞”进去不行，我换了个思路：直接用子域名部署 AList，然后通过 CSS 把它“易容”成我的博客。
在 AList 后台 设置 -> 全局 -> 自定义头部 里，我加了下面这段代码。
它的作用是：隐藏 AList 原生元素 + 注入一个高仿的博客导航栏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

<link rel="stylesheet" href="[https://npm.elemecdn.com/font-awesome@4.7.0/css/font-awesome.min.css](https://npm.elemecdn.com/font-awesome@4.7.0/css/font-awesome.min.css)">

<style>
    :root {
        --hope-colors-primary: #4A6FA5 !important;
        --hope-colors-background: #F8F9FB !important;
    }
    .footer { display: none !important; }
    .header-left { display: none !important; }
    .hope-c-PJLV-ijhzIfm-css { display: none !important; }
    .custom-nav {
        position: fixed; top: 0; left: 0; width: 100%; height: 60px;
        background: #4A6FA5;
        z-index: 9999;
        display: flex; align-items: center; padding: 0 20px;
        color: white;
        box-shadow: 0 2px 5px rgba(0,0,0,0.2);
    }
    #root { padding-top: 60px !important; }
    .header { top: 60px !important; background: transparent !important; box-shadow: none !important; }
    .custom-menu-item {
        color: white; text-decoration: none; margin-right: 20px;
        font-size: 14px; font-weight: bold;
    }
    .custom-logo { font-size: 18px; font-weight: bold; margin-right: 40px; }
</style>

<script>
window.onload = function() {
    var nav = document.createElement('div');
    nav.className = 'custom-nav';
    nav.innerHTML = `
        <div class="custom-logo">Indolyn's Blog</div>
        <a href="[https://www.indolyn.com](https://www.indolyn.com)" class="custom-menu-item"><i class="fa fa-home"></i> 首页</a>
        <a href="[https://www.indolyn.com/archives/](https://www.indolyn.com/archives/)" class="custom-menu-item"><i class="fa fa-archive"></i> 时间轴</a>
        <span class="custom-menu-item" style="opacity:0.6;"><i class="fa fa-cloud"></i> 资源库</span>
    `;
    document.body.insertBefore(nav, document.body.firstChild);
}
</script>

总结

到这里，博客折腾记基本完成了。这次主要是记录我从0开始搭建博客的过程(从仅用一个域名开始)。之后博客有相应的升级我也会在这个系列更新的。

既然换了新家，我就琢磨着把域名邮箱也重构一下。我的核心诉求很简单：对外使用专业域名邮箱，对内挂载到 Gmail 收发，且绝对不能暴露我真实的 Gmail 地址。

折腾了一圈，最后选定了 Cloudflare (收) + Brevo (发) + Gmail (端) 的免费组合。

1. 为什么这么折腾？

主要是爱折腾

• 身份隔离：不想在任何公开场合留下真实的 Gmail，防止被开盒或垃圾邮件轰炸。
• 规避备案：之前考虑过企业微信，但国内服务商对域名备案要求极严，海外域名还是走国际路线更省心。
• 零成本：Cloudflare Routing 和 Brevo 的 SMTP 额度对个人站长来说绰绰有余。

2. 踩坑实录

坑位一：Gmail SMTP 验证报错 535 5.7.8

我在 Gmail 里配置“别名发送”时，死活连不上 Brevo。

真正原因：
我习惯性地在“用户名”里填了我的 Email 地址。但在 Brevo 的体系里，SMTP 的用户名是一个专属的 Login ID（形如 12a3bc456@smtp-brevo.com）。

解决：

1. 去 Brevo 的 SMTP & API 页面找那个专门的 Login。
2. 密码填生成的 SMTP Key，而不是 Brevo 的登录密码。

坑位二：SPF 记录的“多胞胎”冲突

配置完发现，发给小号的邮件全进了垃圾桶。

原因：
为了让 Cloudflare 转发邮件，我配了它的 SPF；为了让 Brevo 发信，我又配了 Brevo 的 SPF。一个域名只能有一条 SPF 记录，多条记录会导致验证直接失效。

解决：
必须把两条记录合并成一条：
v=spf1 include:_spf.mx.cloudflare.net include:spf.brevo.com ~all

坑位三：2025 年的“强制合规”

现在的 Google 和 Yahoo 对发件人极其挑剔。如果你的 Brevo 后台 DKIM 没绿，或者没有 DMARC 记录，基本就是“发一封丢一封”。

解决：

1. DKIM：必须在 Cloudflare 里配置好 Brevo 给的那几条 CNAME 记录，直到 Brevo 显示 Authenticated。
2. DMARC：哪怕是配个最简单的监控模式也行。
   v=DMARC1; p=none; rua=mailto:admin@indolyn.com;

这篇文章记录了，我是怎么从 Claude Code 报错，一路折腾到 Gemini CLI 认证失败，最后终于摸索出一套在 WindowsPowerShell、PowerShell 还有 Linux 上都能通用的代理方案。

1. 怎么 Claude Code 就用不了呢？

刚开始运行 Claude Code 的时候，终端一直转圈圈提示连接超时。

我当时的第一个反应是：难道这玩意儿非得充 Pro 账号才能用？ 于是我赶紧换了 Gemini CLI 试试，结果还是报错！这时候我才反应过来，根本不是账号的问题，而是我的代理根本没进到命令行里去。

2. 踩坑实录

坑位一：环境变量的“永久”大坑

为了图省事，我一开始用了 setx 想设个永久变量：
setx HTTP_PROXY "http://127.0.0.1:7897"

当我关掉梯子想搞本地调试的时候，命令行直接“断网”了！
因为 setx 会把设置写死在注册表里，工具找不到代理服务器就会硬生生地报错，根本不会自动切换到直连状态。

这里千万别用 setx！建议在 Shell 配置文件里写个小函数，随用随开，不用就关。

坑位二：Windows PowerShell vs PowerShell 7

我发现自己在 pwsh (PowerShell 7) 里写好的配置，换到旧版的 Windows PowerShell 竟然没法用，甚至还喷出了一堆莫名其妙的乱码（比如 浠ｇ悊宸插紑鍚）。

原因其实很简单：

1. 各走各的路：这两个 Shell 读取的是完全不同的配置文件。
2. 编码不和：旧版 PowerShell 对那种不带 BOM 的 UTF-8 文件特别不友好。
3. 协议不全：在 Windows 下，如果不配好 **ALL_PROXY**，很多走 SOCKS5 协议的 AI 工具根本就跑不起来！

坑位三：Gemini 认证

配置 Gemini CLI 的时候，网页端明明说认证成功了，结果命令行里却跳出一个 GOOGLE_CLOUD_PROJECT 找不到的错误。

原因：因为我用的是普通账号，Google 强制要求得关联一个云项目或者使用API，配置起来超级麻烦。
解决办法：直接换成个人 Pro 账号登录！个人账号自带配额，登上去就能用，完美避开了那些复杂的后台设置。

3. 代理方案

为了不让大家（还有未来的我）再掉进这些坑里，我整理了这套配置。

A. Windows：PowerShell 5.1 & pwsh 7

在两个环境里分别输入 notepad $PROFILE，把下面的代码贴进去就行（记得保存的时候选 带有 BOM 的 UTF-8 哦！）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function proxy {
    $env:HTTP_PROXY  = "http://127.0.0.1:7897"
    $env:HTTPS_PROXY = "http://127.0.0.1:7897"
    $env:ALL_PROXY   = "socks5://127.0.0.1:7897"
    Write-Host "Proxy On / 代理已开启！" -ForegroundColor Green
}

function unproxy {
    $env:HTTP_PROXY  = $null
    $env:HTTPS_PROXY = $null
    $env:ALL_PROXY   = $null
    Write-Host "Proxy Off / 代理已关闭！" -ForegroundColor Red
}

B. Linux / WSL (Bash/Zsh)

编辑 ~/.bashrc 或者 ~/.zshrc，加上这段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Linux 比较挑剔，大小写都要照顾到
proxy() {
    export http_proxy="http://127.0.0.1:7897"
    export HTTP_PROXY="http://127.0.0.1:7897"
    export https_proxy="http://127.0.0.1:7897"
    export HTTPS_PROXY="http://127.0.0.1:7897"
    export all_proxy="socks5://127.0.0.1:7897"
    export ALL_PROXY="socks5://127.0.0.1:7897"
    echo "Proxy On (代理已开启啦！)"
}

unproxy() {
    unset http_proxy HTTP_PROXY https_proxy HTTPS_PROXY all_proxy ALL_PROXY
    echo "Proxy Off (代理已关闭啦！)"
}

最后：在 Windows 上折腾代理，要是没配 ALL_PROXY，约等于没做！

以前为了省事，我把图片直接存本地。结果 Hexo 仓库越来越大，git clone 慢得像蜗牛。后来想搞图床，发现 GitHub 在国内访问不稳，商业云存储又要担心流量费。

经过两个小时的折腾（踩了不少坑），我终于摸索出了一套“终极方案”：
**Cloudflare R2 (存储) + PicList (上传工具) + VS Code / Typora (写作)**。

这套方案不仅完全免费、全球CDN加速，而且完美打通了我最常用的两个编辑器。

🔗 第一步：配置 Cloudflare R2

Cloudflare R2 提供了 10GB 存储 + 1000万次读取/月 的免费额度，对个人博客来说几乎是无限的。

1. 创建存储桶：在 Cloudflare R2 后台创建一个 Bucket（例如 blog-img）。
2. 绑定域名（关键）：
   • 在桶的 设置 -> 公开访问 里，绑定一个自定义域名（如 img.indolyn.com）。
   • 如果不绑域名，图片只能存不能看。
3. 获取 API 密钥：
   • 点击 Manage R2 API Tokens。
   • 避坑点：权限必须选 “对象读写 (Object Read & Write)”。
   • 记录下 Access Key ID、Secret Access Key 和 Endpoint。

🛠️ 第二步：配置 PicList (核心中枢)

为什么要用 PicList 而不是 PicGo？
因为 PicList 是 PicGo 的超强升级版，它原生支持 S3/R2，不需要像 PicGo 那样折腾插件环境（还要装 Node.js、Python，太容易报错了）。

1. 基础配置

下载安装 PicList 后，进入 图床 -> Amazon S3 -> 编辑配置：

• AccessKey / SecretKey：填入刚才获取的。
• Bucket：填你的桶名（如 blog-img）。
• Region：直接填 auto。
• Endpoint：填 https://xxxx.r2.cloudflarestorage.com (注意：不要带桶名和斜杠)。
• 自定义域名：填 https://img.indolyn.com。

2. 🚨 解决 404 问题的关键设置

配置好后我发现上传成功，但访问全是 404。
仔细一看，链接变成了 https://域名/桶名/文件名，多了一层桶名。

解决方法（如图）：
在 PicList 的 S3 设置下方：

1. ForcePathStyle：改为 No (关闭)。
2. 🔥 关键开关：找到 “开启 pathStyleAccess 时，是否要禁用最终生成URL中添加 bucket 前缀”，选 **Yes**。

(开启这个开关，链接路径就正常了)

💻 第三步：Typora 对接

Typora 是我写长文的首选，配合 PicList 可以实现完全无感的上传体验。

1. 找到 PicList 路径：
   找到 PicList 安装目录下的 PicList.exe 路径（例如 D:\tools\PicList\PicList.exe）。

2. 配置 Typora：
   打开 文件 -> 偏好设置 -> 图像：

   • 插入图片时：选择 上传图片 (Upload image)。
     • 建议：勾选“对本地位置的图片应用上述规则”，这样以前存本地的图片也能一键转上传。
   • 上传服务：选择 PicGo (app) (PicList 兼容 PicGo 接口)。
   • PicGo 路径：粘贴刚才复制的 PicList.exe 路径。

   参考配置

   

3. 验证：
   点击 “验证图片上传选项”，看到两个绿色对勾，说明配置成功！

   

现在的体验：在 Typora 里截图 -> Ctrl+V -> 图片自动变红（上传中） -> 变蓝（上传完成），链接自动替换为 R2 链接。

⌨️ 第四步：VS Code 配置

如果你习惯在 VS Code 里写 Hexo，配置更简单。

1. 在 VS Code 扩展商店安装 vs-piclist 插件（作者是 Kuingsmile）。
2. 确保 PicList 软件在后台运行（它会开启 36677 端口）。
3. 不需要改任何配置文件，插件会自动连接 PicList。
4. 快捷键：
   • 截图后按下 Ctrl + Alt + U (Win) / Cmd + Opt + U (Mac)。
   • 图片链接自动插入 Markdown。

这篇文章记录一下我从 GitHub Pages 迁移到 Cloudflare Pages，并配置 Waline 评论系统的全过程。本以为只是简单的配置，结果踩了一下午的坑，特此记录，希望能帮到后来人（也防止自己以后忘了）。

1. 为什么迁移？

我原来的博客是托管在 GitHub Pages 上的，但有两个痛点：

1. 隐私问题：GitHub Pages 强制要求仓库公开（Public），但我希望把博客源码放在私有仓库里。
2. 速度问题：Cloudflare Pages 的节点速度在全球范围内通常比 GitHub Pages 更快且稳。

于是决定：源码放 GitHub 私有仓库 -> Cloudflare Pages 自动拉取构建 -> 绑定自定义域名。

2. 踩坑实录

坑位一：Cloudflare 构建失败 hexo: not found

刚把仓库连上 Cloudflare，第一次构建就红了。
报错：/bin/sh: 1: hexo: not found

原因：Cloudflare 的构建环境是纯净的，没有全局安装 Hexo CLI。
解决：
修改 Cloudflare 的 Build Command（构建命令）：

• 原命令：hexo g
• 修改为：npx hexo g

坑位二：DNS 解析 Error 1016

配置域名 indolyn.com 时，访问网站直接报错 Error 1016 Origin DNS error。

原因：DNS 设置里的 CNAME 配置错了。
我在 Cloudflare 后台添加记录时，Name（名称）一栏填了 indolyn.com，导致实际解析变成了 indolyn.com.indolyn.com。

解决：

• 根域名（example.com）：Name 栏必须填 **@**。
• 子域名（www）：Name 栏填 www。

坑位三：Waline 评论系统 401 Unauthorized

这是最折磨的一步。Waline 部署在 Vercel 上，数据库用的 LeanCloud 国际版。
网页上一直报错 401 Unauthorized，后台日志显示 Client network socket disconnected。我一开始以为是跨域（CORS）问题，改了半天 CORS_ORIGIN 也没用。

真正原因：
我使用的是 LeanCloud 国际版，且没有绑定自定义域名。在 Vercel 环境中，Waline 无法自动找到 LeanCloud 的 API 服务器地址。

解决：

1. 去 LeanCloud 后台找到 AppID。
2. 在 Vercel 的环境变量（Environment Variables）中，手动添加 **LEAN_SERVER**。
3. 值填写：https://[AppID前8位].api.lncldglobal.com
4. 关键一步：修改完变量必须 Redeploy（重新部署） 才会生效！

坑位四：CORS 跨域报错

解决了 401 后，浏览器还是报 CORS 红色错误。

解决：
在 Vercel 环境变量中设置 CORS_ORIGIN。
为了安全起见，不要用 *，建议设置为：

1

[https://indolyn.com](https://indolyn.com),[https://www.indolyn.com](https://www.indolyn.com),http://localhost:4000

这就允许了线上域名和本地预览环境的访问。

3. 总结

虽然过程有点曲折，但看到评论区跑通的那一刻还是很爽的。
现在的架构：

• 博客：Hexo (Local) -> GitHub (Private) -> Cloudflare Pages
• 评论：Waline (Vercel) -> LeanCloud (International)

这样既保证了源码隐私，又有了极速的访问体验，评论系统也完全掌握在自己手里。