Waline 评论加速与自定义域名：一次 DNS 踩坑全记录#
一、问题：“评论怎么这么慢？”#
网站接入 Waline 评论系统后，有个问题一直困扰我——评论和点赞响应特别慢。发一条评论要转圈 2-4 秒才有反应，体验很差。
当时凭直觉想：Supabase 数据库部署在日本，我在国内访问，是不是跨国延迟导致的？
这个猜测只对了一半。
二、一次请求到底走了多远？#
先梳理一下 Waline 的架构：
用户浏览器（中国）
↓ ① 加载 JS
Netlify（托管前端页面）
↓ ② Waline.init()，发评论/点赞请求
Vercel（Waline 后端 API）
↓ ③ 读写数据库
Supabase（PostgreSQL 数据库）我分别查了这三个服务的地理位置：
| 组件 | 部署位置 | 到中国延迟 |
|---|---|---|
| Netlify | 全球 CDN | ~30ms（有亚洲节点） |
| Vercel | 🚩 美东 iad1（默认） | ~250-400ms |
| Supabase | 🇯🇵 日本东京 | ~100-150ms |
一次请求的完整链路：
中国 → 美国 Vercel → 日本 Supabase → 美国 Vercel → 中国
↑ 跨太平洋 2 次 ↑单程 250-400ms，来回四跳，再加上 Vercel 免费版 Serverless 的冷启动（函数一段时间不用会休眠，下次唤醒来多 1-3 秒），2-4 秒的延迟就是这么来的。
💡 冷启动：Vercel 免费版的函数如果几分钟没被调用就会”休眠”。下一个请求来了，容器从睡眠到就绪需要额外时间。Pro 版才支持常驻实例。
三、优化第一步：Vercel 区域迁移#
找到主因后，第一个优化很直接——把 Vercel 函数区域从美东迁到日本，和 Supabase 放同一个区。
操作：Vercel 项目 → Settings → Functions → Function Region → 改为 HND（ap-northeast-1）。
为什么不选香港？
Vercel 亚洲有两个区域可选：
| 选项 | 到中国延迟 | 到 Supabase（日本）延迟 | 总链路 |
|---|---|---|---|
🇯🇵 东京 hnd1 | ~50-100ms | 同区，~1ms | 中国→日本→日本→中国 |
🇭🇰 香港 hkg1 | ~30-60ms | 跨区，~50ms | 中国→香港→日本→中国 |
选日本是因为 Supabase 就在日本——应用和数据库同区域部署，内部网络延迟几乎为零。选香港虽然离中国近了 20ms，但香港到日本多了 50ms，得不偿失。
改完后重新部署，链路变成：
中国 → 日本 Vercel → 日本 Supabase → 日本 Vercel → 中国
↑ 只在亚洲兜一圈 ↑但这只是第一步。还有一个问题没解决——域名。
四、优化第二步：绑自定义域名#
Waline 后端默认用的是 Vercel 分配的域名 knowlage-gallary-waline.vercel.app。
*.vercel.app 是共享域名——成千上万个项目共用。在国内网络环境下，这类共享域名可能面临间歇性访问异常。
更好的做法是：用自己的 glinfei.space 开一个子域名（如 waline.glinfei.space），指向 Vercel。
为什么自己的域名更稳定？
glinfei.space 是你独立持有的域名，它只是一个普通的 .space 个人网站。相比共享域名，被牵连干扰的概率低得多。
怎么做？一句话原理：
在 DNS 里加一条 CNAME 记录，把
waline.glinfei.space指向 Vercel 分配的项目接入地址。然后在 Vercel 项目设置里加上这个域名，Vercel 会自动签发 SSL 证书。
于是我开始实操——先去了腾讯云（因为域名是在腾讯云买的）。
五、踩坑：在腾讯云配了半天，发现 DNS 根本不在那#
5.1 操作过程#
登录腾讯云 → DNS 解析 → glinfei.space → 添加记录：
| 主机记录 | 记录类型 | 记录值 |
|---|---|---|
waline | CNAME | e24754726155fc79.vercel-dns-017.com |
保存、等待、检测……半小时过去了，waline.glinfei.space 仍然解析失败。
再到 Vercel 那边一看，也显示 Invalid Configuration——检测不到这条 DNS 记录。
Vercel：你的 DNS 里没有这条 CNAME，配置无效
我： 我明明加了啊？5.2 根因：DNS 管辖权早就移交了#
查了一下 glinfei.space 的 NS 记录（Name Server，决定谁来回答这个域名的 DNS 查询）：
glinfei.space nameserver = dns1.p04.nsone.net.
glinfei.space nameserver = dns2.p04.nsone.net.
glinfei.space nameserver = dns3.p04.nsone.net.
glinfei.space nameserver = dns4.p04.nsone.net.nsone.net 是 Netlify DNS。原来当初把网站部署到 Netlify 并绑自定义域名时，Netlify 让改了 Nameserver，整个 glinfei.space 的 DNS 管辖权已经从腾讯云移交给了 Netlify。
我：在腾讯云加 CNAME → 全球 DNS 查询都去 Netlify → 腾讯云的记录根本没人看解决方案：去 Netlify 的域名管理页面添加同样的 CNAME 记录。保存后两分钟，Vercel 立刻识别成功，SSL 证书自动签发，https://waline.glinfei.space 可以正常访问了。
最后把 site.config.ts 里 Waline 的 server 地址一改：
- server: 'https://knowlage-gallary-waline.vercel.app',
+ server: 'https://waline.glinfei.space',重新部署，搞定。
六、效果#
优化完成后，评论体验改善明显：
- 改动前：发评论转圈 2-4 秒，不开 VPN 经常失败
- 改动后：不开 VPN 也能流畅使用，响应在 1 秒以内
回顾整个过程：
改动前:
中国 → 美国 Vercel → 日本 Supabase → 美国 Vercel → 中国
域名: *.vercel.app（共享域名）
改动后:
中国 → 日本 Vercel → 日本 Supabase → 日本 Vercel → 中国
域名: waline.glinfei.space（独立域名）七、DNS 小课堂：这次用到的概念#
这节整理一下配置过程中涉及的 DNS 概念，给同样踩坑的朋友做个参考。
7.1 域名层级#
你访问 waline.glinfei.space，实际上是这样一个结构：
waline . glinfei . space . ← 末尾还有个隐形的"根"
↑ ↑ ↑ ↑
子域名 主域名 顶级域 根域就像快递地址从大到小：地球 → 中国 → 广东 → 深圳 → 某小区。DNS 的查询也是从根逐级往下查。
7.2 Nameserver（NS 记录）：谁说了算？#
NS 记录决定了谁来回答你域名的所有 DNS 查询。
打个比方：DNS 就像全国的电话黄页，NS 记录指定了”你家的电话号码本由谁来维护”。
一开始在腾讯云买域名 → NS 默认指向腾讯云的服务器（dnspod.net）
绑定 Netlify 时改了 NS → NS 指向 Netlify（nsone.net）这就是为什么我在腾讯云加记录无效——电话本已经交给 Netlify 了，你在腾讯云那本旧本子上再怎么写，也没人来查。
7.3 A 记录 vs CNAME#
| 记录类型 | 你填什么 | DNS 做什么 |
|---|---|---|
| A 记录 | IP 地址 76.76.21.21 | 直接返回这个 IP |
| CNAME | 域名 xxx.vercel-dns-017.com | ”去问那个域名，它才知道最终 IP” |
为什么 Vercel 要你用 CNAME 而不是 A 记录？
Vercel 的服务器 IP 不是固定的——今天 76.76.21.21，明天扩容就变了。如果让你在 DNS 里写死 A 记录，哪天 Vercel 换 IP，你的网站就挂了。
CNAME 就像一根绳子，你只负责把绳子扔到 Vercel（填 CNAME 记录），绳子那头连到哪台机器，是 Vercel 自己维护的事，IP 随便换都不影响你。
7.4 FQDN 和末尾的”点”#
你在 Vercel 里看到的 CNAME 值：
e24754726155fc79.vercel-dns-017.com.
↑ 这个点这是 DNS 的 FQDN（Fully Qualified Domain Name，完全限定域名）写法，. 代表根域。就像文件路径 /home/user/docs 和 /home/user/docs/ 的关系一样——后者是绝对路径的完整写法。
在 DNS 面板里填的时候，末尾的 . 不需要带，系统会自动补全。
7.5 TTL：DNS 缓存#
TTL（Time To Live）是你设置 DNS 记录时的一个参数，单位是秒。它告诉全世界的 DNS 服务器：“这条记录你可以缓存多久再重新向我查询。”
TTL=600（10 分钟）：改了 DNS 后最多 10 分钟全球生效，负载均衡
TTL=3600（1 小时）：生效慢，但减少查询，服务器压力小
TTL=60（1 分钟）：改完立刻生效，适合测试环境这解释了为什么改 DNS 不是立刻生效的——要等全世界的 DNS 缓存过期后再来查询新值。
八、总结#
这一次优化给 Waline 评论系统做了三件事：
- Vercel 函数区域从美东迁日本——消灭了跨太平洋的来回延迟
- 绑自定义域名
waline.glinfei.space——提高了国内访问的稳定性 - DNS 踩坑——在腾讯云配了半天发现 NS 是 Netlify，顺手把 DNS 体系学明白了
如果你也在用 Waline + Vercel + Supabase，建议两步优化：
- 先把 Vercel 区域调到和 Supabase 同区（通常是日本）
- 再绑个自定义域名（零成本，一条 CNAME 的事）
你会发现评论体验完全不一样。