Vibe Coding 上线篇：从 ECS 到 ESA Pages、Vercel，搞懂域名解析怎么配
代码已经写好了，项目也部署成功了，为什么用自己的域名还是打不开？
作者：尔东陈在路上｜发布日期：2026-09-21｜原文：https://mp.weixin.qq.com/s/81dAfIAL3NG2GKS0RHH-7Q
Vibe Coding 上线篇：从 ECS 到 ESA Pages、Vercel，搞懂域名解析怎么配
代码已经写好了，项目也部署成功了，为什么用自己的域名还是打不开？
做 Vibe Coding，前半程往往围绕页面、功能和交互展开；到了上线阶段，却突然出现一组陌生名词：A、CNAME、TXT、NS、HTTPS、证书验证……
最近在梳理自己的项目部署时，我就围绕这些问题展开了一轮讨论：自建 ECS 服务器应该怎么解析？部署到 ESA Pages、Vercel 又有什么不同？为什么博客指向了一串很长的域名，却不能直接把那个长域名当作博客地址？
这篇文章就从这些实际问题出发，讲清楚两条常见的上线路线，以及它们背后的域名解析逻辑。
最重要的判断不是“网站是静态还是动态”，而是“用户要通过什么入口访问这个服务”。 自建服务器直连，通常用 A 记录；平台托管，则按平台要求配置 A、CNAME 等记录，不能只凭部署平台的名字判断。
——
一、先分清：买域名、部署项目和域名解析，不是一回事
可以把一个网站的上线理解为几项相互配合的工作。
注册域名，是获得一个名字的使用权。 比如 chenwenbo.cc。
部署项目，是让代码在某个环境中提供服务。 这个环境可能是自己管理的 ECS，也可能是 ESA Pages、Vercel 这样的托管平台。
域名解析，是告诉访问者应该去哪里找这个服务。 浏览器通过 DNS 查询获得相应地址，随后才连接网站入口。网站内容并不是经过 DNS 服务器传输给浏览器的。
此外，还需要让服务器或平台识别这个域名，并为 HTTPS 配置有效证书。也就是说，DNS 解析正确、域名绑定正确、HTTPS 正常，是需要分别确认的事情。
还有一个容易混淆的关系：
域名在哪里买、DNS 在哪里管理、网站部署在哪里，可以是三家不同的服务商。
例如，域名在阿里云注册，DNS 由阿里云云解析管理，网站部署在 Vercel。这种组合并不矛盾。真正决定“去哪个控制台修改解析”的，是域名当前使用的权威 DNS 服务，而不只是域名的购买渠道。
二、先认识三个最常用的记录：A、CNAME、TXT
刚开始不需要记住所有 DNS 类型，先理解这三个。
A 它表达的意思：这个域名对应这个 IPv4 地址 常见用途：直连 ECS，或者接入要求使用 A 记录的平台
CNAME 它表达的意思：这个域名是另一个域名的别名 常见用途：平台托管、CDN、ESA 接入，也可能用于验证
TXT 它表达的意思：在这个域名下发布一段文本 常见用途：域名控制权验证、证书验证、邮箱安全配置
这三种记录不是互相替代的三个方案，而是承担不同职责的工具。
A：直接告诉别人地址
A 记录的值是 IPv4 地址。你已经有一台 ECS，知道它的公网 IP，就可以把希望使用的域名解析到这个地址。需要通过 IPv6 提供服务时，对应的是 AAAA 记录。
CNAME：让自己的域名跟随另一个域名解析
CNAME 的值不是 IP，而是另一个域名。
这样，目标域名背后的地址发生变化时，你通常不需要跟着修改自己的记录。平台可以调整底层服务地址，你仍然使用它分配的接入域名。
TXT：发布供其他系统检查的信息
TXT 常被用来证明：“我能管理这个域名。”
平台给出一段指定文本，你把它添加到 DNS 中，平台查询后确认匹配，就完成相应验证。它证明的是域名控制权，不是网站内容可信，也不是网站已经部署成功。TXT 还常用于 SPF、DKIM、DMARC 等邮件安全机制。
另外两个会遇到的类型是：MX 指定邮件服务器，NS 指定由哪些 DNS 服务器负责回答解析查询。 特别是 NS，关系到后面要讲的“保留原 DNS”还是“迁移 DNS 管理”。
控制台中的“主机记录”怎么填？
以阿里云云解析中管理 chenwenbo.cc 为例：
@ 对应 chenwenbo.cc www 对应 www.chenwenbo.cc blog 对应 blog.chenwenbo.cc dzj-agent 对应 dzj-agent.chenwenbo.cc
这里的 @ 表示当前管理的域名本身。阿里云的这个输入框会自动拼接后缀，不需要再次填写完整域名；其他 DNS 服务商的表单格式可能不同，要看输入框提示。
三、场景一：项目部署在自己的 ECS 上
这条路线的特点是：服务器由自己管理，网站入口由自己配置。
例如，这次给 Agent 项目配置的域名是：
dzj-agent.chenwenbo.cc
为它添加 A 记录，指向 ECS 的公网 IPv4，就是典型的服务器直连方式。配置结构如下，实际记录值应填写自己的公网 IP：
主机记录：dzj-agent 记录类型：A 记录值：你的 ECS 公网 IPv4
公网网站不能把这里误填成 ECS 的 VPC 内网地址，否则外部用户即使查到了地址，也无法按这种直连方式访问。
解析到服务器，不代表应用就能访问
假设项目运行在服务器的 3000 端口，A 记录并不会自动把网站请求转给这个端口。
普通的 A、AAAA、CNAME 记录不负责网站端口和路径映射。你不能把 A 记录值写成“IP 加 :3000”，也不能让 CNAME 指向一个带 /dashboard 的网址。
一种常见做法，是让 Caddy 或 Nginx 作为网站入口，再把请求转给应用：
浏览器通过 HTTPS 访问域名 ↓ 服务器上的网站入口 ↓ 运行在本机 3000 端口的应用
这项工作叫反向代理，属于网站服务配置，不属于 DNS 解析。
因此，自建 ECS 上线时，不能只检查 A 记录。还要确认应用正在运行、入口配置正确、安全组及系统防火墙允许必要访问，以及证书有效。公开网站通常需要按方案开放 80、443；数据库、管理面板等端口不应该为了“让网站能打开”而全部暴露到公网。
使用 Caddy 时，在域名、端口和存储等条件满足后，它可以自动申请和续期证书，但“自动”不代表可以跳过这些前提。
这条路线可以记成：域名指向服务器，服务器再把请求交给应用。
四、场景二：项目部署在 ESA Pages、Vercel 等托管平台
这一类服务不宜简单理解为“静态服务器”。
ESA 的 Functions and Pages 支持静态网站、单页应用、服务端渲染和边缘函数；Vercel 也提供函数能力。这里真正的区别是：你把项目交给平台托管，而不是自己维护一台固定服务器。
1. ESA Pages：先绑定项目，再按接入方式配置
以本次讨论中的博客配置为例：
主机记录：blog 记录类型：CNAME 记录值：blog.chenwenbo.cc.a1.initaq.com
这条来自实操的记录，表示让 blog.chenwenbo.cc 通过 ESA 分配的接入域名完成解析。它不是其他项目可以直接照抄的通用记录值。
对 ESA Pages 来说，需要区分两个层次：
DNS 接入负责找到 ESA；Pages 的域名绑定负责让 ESA 知道请求应该交给哪个项目。
因此，不能只在 DNS 控制台加一条 CNAME，还要在对应的 Pages 项目中完成自定义域名绑定，并检查站点的 HTTPS 证书配置。
ESA 又有两种主要接入方式：
CNAME 接入：保留原来的 DNS 服务商。 在 ESA 完成配置后，把平台生成的 CNAME 填回原 DNS 控制台。适合只把部分网站接入 ESA，同时保留其他子域名原有服务的情况。
NS 接入：把 DNS 管理交给 ESA。 按平台要求修改域名的 DNS 服务器地址，此后主要在 ESA 中维护解析记录。Pages 绑定域名时，相关记录由平台在站点内创建。
所以，NS 接入不是“不需要域名解析”，而是“换了一个地方管理域名解析”。
2. Vercel：根域名和子域名，可能使用不同记录
Vercel 不能简单概括成“全部用 CNAME”。
按其官方配置方式，在保留外部 DNS 服务商的情况下：
example.com 常见记录类型：A 记录值从哪里获得：当前项目的 Domains 设置
www.example.com 常见记录类型：CNAME 记录值从哪里获得：当前项目的 Domains 设置
app.example.com 常见记录类型：CNAME 记录值从哪里获得：当前项目的 Domains 设置
Vercel 的子域名接入可以使用项目对应的专属 CNAME。不要拿几年前教程里的固定地址，也不要复制另一个项目的记录值代替当前项目的要求。
操作逻辑是：先在项目中添加自定义域名，再到实际负责解析的 DNS 服务商那里配置记录，最后回到平台检查域名状态。平台要求 TXT 验证时，再按提示添加。
平台托管这条路线，可以记成：域名接入平台，平台再根据绑定关系找到项目。
五、常见 Vibe Coding 项目，域名怎么组织更清楚？
理解两条基本路线之后，可以把它们组合使用。下面是几种实用的组织方式，而不是必须遵守的固定模板。
个人官网、博客和小工具：按项目拆分子域名
例如：
example.com 品牌主页 blog.example.com 博客 tools.example.com 小工具集合 agent.example.com Agent 应用
这些名字可以分别指向不同服务，不必因为共用一个主域名，就部署在同一台服务器或同一家平台。每个完整域名仍需配置自己的解析，以及对应的服务绑定。
我的建议是：新项目先用独立子域名接入，不要为上线一个实验项目就修改整个主域名的入口。 这样更容易看清这次改动影响什么。
前端在平台，后端在 ECS：分别配置入口
例如，可以把页面放在托管平台，把需要独立运行环境的后端放在 ECS：
app.example.com → 前端平台要求的接入记录 api.example.com → ECS 公网 IP 的 A 记录
这是前面两种接入方式的组合。
但有个重要边界：域名解析不会顺便解决前后端跨域。 浏览器把 app.example.com 和 api.example.com 视为不同来源，后端仍需按实际需求配置 CORS。两者都以 example.com 结尾，并不等于同源。
另一种组织方式，是让浏览器统一访问同一域名，再由平台路由或反向代理把 /api 请求交给后端。这是在 HTTP 服务层分流，不是在 DNS 中按路径分流。
ECS 前面再加 ESA：服务器没有搬走，只是入口改变了
还有一种容易和“部署到 ESA Pages”混淆的情况：
项目仍然运行在 ECS，只是在前面加一层 ESA 加速和防护。
这时，网站域名先接入 ESA；需要回源的请求，再由 ESA 按配置访问 ECS。它与“把项目代码部署到 Pages”不是一回事。仅看到一条指向 ESA 的 CNAME，并不足以判断应用究竟运行在哪里。
项目迁移：优先改网站入口，不轻易迁移整套 DNS
从 Vercel 迁到 ESA Pages，或者从平台迁到 ECS，不一定需要更换域名，也不一定需要更换 DNS 服务商。
如果只是更换某个网站的托管位置，可以先在新平台完成部署、域名绑定和证书准备，再修改相应网站记录。若决定更换 NS，就要提前把原有解析完整迁入新服务，尤其不能漏掉邮箱 MX 和验证 TXT。
迁移时还应给旧服务保留过渡时间，因为不同访问者可能暂时仍在使用旧的 DNS 缓存。
六、几个最容易踩的坑
坑一：把 CNAME 目标当成网站的备用网址
本次讨论里最有代表性的问题是：
blog.chenwenbo.cc.a1.initaq.com
既然博客指向它，为什么不直接访问它？
因为，“找到同一个服务入口”和“请求同一个网站”，不是一回事。
CNAME 不会把浏览器请求的域名替换掉。访问 blog.chenwenbo.cc 时，请求仍然表明自己要访问这个博客域名；直接访问长域名时，请求使用的则是另一个名字。服务器或平台可以据此返回不同内容。
直接访问长域名能否成功，还取决于平台是否为它提供项目路由和相应的 HTTPS 配置，不能仅凭它是 CNAME 目标判断。它也不能与平台明确提供的默认部署地址、预览地址混为一谈。
对访客提供自定义域名；对 DNS 配置填写平台分配的接入域名。
坑二：以为 CNAME 就是网页跳转
假设 www.example.com 的 CNAME 指向 example.com，这并不代表浏览器地址栏会自动变成后者。CNAME 解决的是解析关系，不是页面重定向。
希望用户统一进入带 www 或不带 www 的一个地址，需要在平台或服务器上配置重定向。两个域名也应分别完成必要的接入和绑定，不能只配其中一个就假定另一个会自动可用。
坑三：同一个名字同时塞进 A 和 CNAME
对于同一个完整主机名，不要为了“保险”同时配置 A 和 CNAME。例如，不能把 app.example.com 同时当作直连 ECS 的地址和指向平台的别名。在阿里云的同一解析线路下，这两类配置会冲突。
但 app.example.com 用 CNAME、api.example.com 用 A，没有这个问题，因为它们是不同名字。
根域名 @ 还涉及额外的兼容性问题。部分服务提供 ALIAS、CNAME 展平或特殊处理；阿里云也对部分根域名记录共存做了兼容，但文档明确提示了 MX、TXT 可能受影响的风险。因此，不要把子域名配置直接照搬到根域名，更不要忽略已经存在的邮箱记录。
坑四：证书申请成功，就删除所有验证记录
_acme-challenge 看起来像一串可以清理的临时配置，但要先确认它承担什么任务。
证书的 DNS 验证可以直接使用 TXT；也可以用 CNAME 把验证委托给另一个域名，由对方维护验证信息。ESA 的托管 DCV 就使用后一种思路。
一次性挑战值和长期验证委托，不是一回事。 仍承担自动续期任务的托管验证记录不能随意删除，否则可能不是今天出问题，而是在后续续期时失败。是否清理，应按平台说明判断。
坑五：TTL 是 10 分钟，就认为全球一定 10 分钟更新
TTL 表示解析结果的缓存时间，不是全球同步倒计时。
修改记录后，有些访问者已经拿到新结果，有些仍在使用旧缓存，是可能出现的情况。少数解析服务的缓存策略还可能让变化更晚被看到。
准备迁移时，比较稳妥的做法是提前降低 TTL，等原来的缓存周期过去后再切换入口。切换之后再把 TTL 改小，并不能立刻清掉外部已经保存的旧缓存。
坑六：解析成功，就等于完成全部上线要求
DNS 能查到地址，不代表 HTTPS、应用功能和服务合规要求都已经满足。
例如，使用阿里云中国内地 ECS 对外提供网站服务，需要按要求完成 ICP 备案；已经在其他接入商备案的，还要核对是否需要办理接入。把 A 改成 CNAME，并不能替代这些要求。
七、出了问题，不要只反复修改 DNS
排查时，我建议沿着访问过程逐层检查。
先看解析。 域名有没有查到结果？结果是否符合当前配置？记录是不是改在真正生效的权威 DNS 服务商那里？可以使用 dig、nslookup 等工具检查，而不只是看控制台里有没有一条记录。
再看连接。 已经获得地址却连接超时，要检查网络、安全组、系统防火墙和服务监听，不要直接认定还是 DNS 问题。
再看 HTTPS 和网站绑定。 证书是否覆盖访问的域名？平台有没有把这个域名绑定到正确项目？服务器是否把请求交给了正确应用？
最后看应用。 页面能打开，不代表接口调用正常。前后端分开部署时，浏览器的跨域限制就可能影响功能，这不是修改 A 或 CNAME 能解决的。
这套顺序，比反复删除记录、重新添加，再期待它突然生效，更容易定位问题。
八、让 AI 帮忙配置域名，应该怎么提需求？
在 Vibe Coding 工作流里，可以让 AI 协助读取平台要求、整理配置方案和执行验证。但不要只给一句“帮我把域名配好”。
下面这段可以作为上线任务的起点：
请帮我制定这个项目的自定义域名接入方案。
部署方式：ECS / ESA Pages / Vercel 目标域名： 当前 DNS 服务商： ECS 公网 IP，或平台给出的域名配置要求： 是否已有网站、邮箱或其他子域名在使用：
先只读检查现有配置，并说明： 域名解析、项目绑定、HTTPS 分别需要做什么。
请列出需要新增或修改的主机记录、类型、记录值， 说明对现有业务的影响，并提供验证方法和回退方案。
不要猜测平台接入地址。 不要为了新增一个网站就直接更换 NS。 不要删除仍在使用的邮箱记录和证书续期验证记录。 涉及变更时，先展示具体差异，再执行我确认的操作。
这里最值得保留的习惯是：先搞清楚现状，再做最小范围的修改；修改之后，用实际访问验证结果。
——
写在最后：域名解析的核心，是理解每一层负责什么
回看这几种部署方式，域名解析并没有想象中那么神秘。
A 记录提供 IPv4 地址，CNAME 建立域名别名关系，TXT 发布验证或配置信息，NS 决定由谁回答解析查询。
而真正完成网站上线，还需要让服务器或平台识别这个域名，并正确提供 HTTPS 和应用服务。
对 Vibe Coding 来说，值得学会的不是背下每个控制台的按钮位置，而是能解释清楚：
用户输入域名后，先找到谁，再由谁接待，最后由哪个项目返回内容。
这条访问过程想明白了，换服务器、换平台、拆分前后端或者迁移项目，就都能沿着同一套思路处理。
延伸阅读
ESA：为函数和 Pages 配置域名 https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/trigger
Vercel：添加与配置自定义域名 https://vercel.com/docs/domains/working-with-domains/add-a-domain
阿里云：不同场景下的 ICP 备案 https://help.aliyun.com/zh/icp-filing/basic-icp-service/product-overview/faq-about-icp-filing-applications-in-different-scenarios