个人博客接入阿里云 ESA 的一套最小配置
最近在整理个人博客的边缘层配置时，我把 DNS、HTTPS、缓存和基础安全重新看了一遍。按我现在的取舍，阿里云 ESA 是比较顺手的一种组合。
这篇文章只写我在 能从阿里云官方文档核验到的内容，以及我会怎么把它落到一个普通个人博客上。
问题背景：小站点最怕的不是没有功能，而是运维面太散
个人站、博客、文档站和轻量 API 通常没有专门的边缘团队，但一样会遇到几个老问题：海外访问慢、源站 IP 暴露、静态资源和动态请求混在一起、HTTPS 证书和回源策略分散在不同控制台里。
我看 ESA 的角度不是“再买一个 CDN”，而是尽量把接入、缓存、安全和一部分规则能力收敛到同一层。按官方产品总览，ESA 不只是缓存静态资源，还把 DNS 托管、WAF、DDoS、防盗刷、规则引擎、函数和 Pages 这类边缘能力放进同一个产品面里。
我为什么会先考虑 ESA
| 我关心的点 | 阿里云 ESA | 传统拆分方案 |
|---|---|---|
| 接入入口 | 支持 NS 和 CNAME 两种方式。NS 适合统一托管根域名和子域名，CNAME 适合先接入单个子域名。 | DNS、加速和安全往往分散在不同入口，排障链路更长。 |
| 缓存和路由 | 官方文档明确支持静态与动态资源加速，并可用规则引擎按主机名、路径、扩展名、协议、国家/地区等条件控制生效范围。 | 很多场景会先做静态缓存，后面再额外补动态路由和细粒度规则。 |
| 安全 | 官方文档明确给出 SSL/TLS、WAF、DDoS、源站保护等能力，适合把能挡在边缘挡掉的流量前移处理。 | 常见做法是先上加速，后面再补 WAF 或回源白名单，配置阶段更容易遗漏。 |
如果只看个人博客这个场景，我最在意的是少切几个控制台。和只做静态缓存的传统 CDN 方案相比，ESA 把 DNS 托管、HTTPS、WAF 和规则控制尽量收在了一层里，这一点对轻量站点更省事。
另外，ESA 套餐页把免费版定位成测试入口，把基础版定位成个人网站或对成本敏感的小型业务，这个分层也比较贴近真实使用路径。
可落地的最小方案
下面这套不是把所有功能都开满，而是我觉得个人博客、内容站或轻量 API 可以先跑起来的最低配置。
1. 先选对区域和接入方式
- 如果域名没有 ICP 备案，又主要服务海外用户，优先看 全球（不包含中国内地）。
- 如果流量包含中国内地，按官方接入文档，中国内地 和 全球 都要求 ICP 备案。
- 新域名、想统一管理 DNS 的站点，优先 NS 接入。
- 已有稳定 DNS 体系、只想先把
www或blog这类单个子域名挂上加速，优先 CNAME 接入。
| 接入方式 | 适合谁 | 我看重的点 |
|---|---|---|
| NS | 新站、准备把整套域名流量交给 ESA 管 | DNS 托管、加速和流量调度统一管理，后续给多个子域名加代理更顺手。 |
| CNAME | 已有 DNS、不想一次性切整个根域名 | 改动更小，适合先从单个子域名试水。 |
2. 先把 HTTPS 配齐，再开强制跳转
官方文档给得很明确：在开启 Always Use HTTPS 之前，先把边缘证书配好。开启后，ESA POP 收到 HTTP 请求会返回 301 跳转到 HTTPS。
这里的边界也很明确：如果页面里还在加载 HTTP 资源，浏览器会报 Mixed Content。所以我的顺序是：
- 先配置边缘证书。
- 检查静态资源、图片、字体、脚本是否已经全站 HTTPS。
- 再开启站点级的 Always Use HTTPS。
3. 缓存不要全站一把梭，先按资源类型和路径分层
阿里云 ESA 的默认缓存并不是所有请求都生效。按官方默认缓存规则，默认只有 GET 和 HEAD 会进入缓存组件，而且还要看文件类型是否命中默认扩展名列表。
所以我的做法是：让静态资源吃到边缘缓存，让 API 和后台路径明确绕过缓存。下面的 TTL 秒数是我的建议值，不是官方默认值。
规则 1：静态资源缓存
匹配条件：
http.request.uri.path.extension in ["css","js","jpg","jpeg","png","svg","webp","woff2","mp4"]
建议动作：
- 开启缓存
- 节点缓存：86400s
- 浏览器缓存：3600s
- 如果源站已经返回 Cache-Control / Expires / Last-Modified / ETag，则优先遵循源站策略规则 2：API 和后台绕过缓存
匹配条件：
http.request.uri.path starts_with "/api/" or
http.request.uri.path starts_with "/admin/"
建议动作：
- Bypass Cache
- 保留源站实时响应如果你有 HTML 页面也想缓存，就不要只依赖默认扩展名列表，而是明确补规则；否则 ESA 很可能只缓存静态文件，不会按你预期缓存页面响应。
4. 安全先抓两件事：WAF 和源站暴露面
官方接入文档提到，ESA 接入后，对外暴露的是边缘节点 IP，这天然减少了源站直接暴露的机会。再往前一步，我会优先把这两件事做掉：
- 开启 WAF 与平台级 DDoS 基础防护，把明显异常流量先挡在边缘。
- 按业务路径补少量自定义规则，例如对登录、表单、支付回调或高频接口做更细的条件控制。
规则引擎文档里已经给出可用维度：主机名、URI、请求方法、协议、来源国家/地区、IP 等。对轻量业务来说，不需要一上来就写复杂策略，先围绕高风险路径做 2 到 3 条规则，通常就够用了。
我会怎么给不同类型的网站选方案
- 个人博客/内容站：CNAME 起步最稳，先接
www或blog，配好静态缓存和 HTTPS；等确认效果后再决定是否切 NS。 - 出海官网/落地页：如果不依赖中国内地加速，优先看全球（不包含中国内地），避免备案前置条件拖慢上线。
- 轻量 API 或前后端混合站：把静态资源缓存和 API 绕过缓存拆开，再利用 WAF 和规则引擎收紧敏感路径。
- 纯测试项目：免费版适合试接入链路；如果要长期跑个人站，我会直接看基础版，而不是把免费版当长期生产方案。
风险和边界
- 中国内地和全球区域都涉及 ICP 备案要求；刚完成备案的域名，官方建议等待 8 小时后再尝试新增站点。
- CNAME 接入只会加速实际配置了 ESA CNAME 的子域名，不会自动覆盖整个根域名。
- 每个接入域名的 CNAME 记录值是唯一的，不能跨域名复用。
- 开启 Always Use HTTPS 之前要先清理 HTTP 资源引用，否则会出现 Mixed Content 问题。
- 默认缓存主要覆盖 GET/HEAD 和一批常见静态扩展名；页面响应、API 或特殊资源类型通常要手动补规则。
- 复杂规则能力和可配置数量与套餐相关，正式上复杂规则前先对照套餐能力页确认，不要默认所有版本都一样。
结论
对我来说，ESA 最有价值的地方不是功能堆得多，而是个人博客最常用的几件事可以放到同一层里处理：接入、缓存、HTTPS 和基础安全。
如果只是做个人博客，我会先从 CNAME 接入、静态资源缓存和 HTTPS 开始，不会一上来把所有规则都配满。先把最小闭环跑通，再按流量和风险补配置，这样更稳。
参考来源
关键词：#阿里云ESA #边缘安全加速