【抽奖】

1024 程序员节抽奖 80 个 EdgeOne 兑换码，将在 2025 年 10 月 24 日 20:48 开奖，敬请期待！

快来扫码参与！

前言

这个月一直没想到什么选题，结果腾讯云前两天给我发了邮件告知说源站防护功能下架了：

【EdgeOne】关于免费套餐下线源站防护功能的通知

尊敬的腾讯云用户，您好！

       您的腾讯云账号（昵称：Anye）正在使用 EdgeOne 免费套餐服务，EdgeOne 将于 2025 年 11 月 14 日对免费套餐功能进行调整，具体详情如下： 

       EdgeOne 免费套餐自 2025 年 6 月份限量内测开放以来吸引了全球开发者用户的目光，感谢您选择并使用 EdgeOne 免费套餐，我们始终致力于为您提供稳定、安全且可持续的产品体验，并持续优化我们的服务架构，以更好地满足广大开发者用户的需求。

       在此内测期间，我们对免费套餐的产品功能进行了重新评估，针对“源站防护”功能存在潜在的安全攻击风险，我们将逐步对免费套餐用户下架“源站防护”功能。 


调整时间：2025 年 11 月 14 日 

调整策略： 

1、对新增免费套餐用户，不再提供“源站防护”功能。 

2、对已开通“源站防护”的免费套餐用户，缓冲期内可正常使用，但 2025 年 11 月 14 日起将逐步下架该功能。 

下架影响： 

“源站防护”功能下架后，不再提供回源 IP 网段，请及时调整源站防火墙策略，避免回源 IP 变更影响回源，造成业务受损。 

应对建议： 

若对“源站防护”功能有强需求的用户，可以将免费套餐升级至个人版/基础版/标准版套餐，即可继续正常使用。 


       本次调整给您带来的不便，我们深表歉意。再次感谢您的理解与长期支持！我们将继续努力，为所有用户提供更优质的服务体验。

我寻思这不是我之前写的教程么https://www.anye.xyz/archives/yAwmyIp9

这下好了，免费套餐用不了了，成了付费套餐使用教程了《😊。

本文不讨论 EdgeOne Free 套餐下架该功能的动机是什么，作为免（bai）费（piao）版用户承担一定的使用风险我觉得是可以接受的。经过 猫哥 的提醒，发现了一种更简单的，可长期正常使用的源站防护办法。本文就来介绍一下该办法。

准备工作

• 已经部署好网站的服务器一台

• 一个 EdgeOne 兑换码（后期开放公测不再需要）

原理说明

EdgeOne 的 源站防护 是通过限制源站访问来源 IP 实现的。也就是说，当你的网站部署在一台公网服务器上时，只有来自 EdgeOne 节点的请求才能被源站接收和响应，其它来源的访问（包括直接通过 IP 访问的攻击者）都会被拒绝，从而 彻底隐藏真实 IP，避免绕过 CDN 的各种攻击行为。

实现这一点的关键，就是在 Web 服务（例如 Nginx/OpenResty）中配置一组允许访问的 IP 白名单。这些 IP 是 EdgeOne 回源节点的固定出口地址，只要维护好这个列表，就可以实现严密的访问控制。

然而我们还可以通过在 EdgeOne 上配置自定义的请求头，让 Web 服务器来分析判断流量是否来源于 EdgeOne，根据请求头的值来决定是否允许访问。这样就不需要频繁更新 IP 白名单了，同时也就绕过了源站防护功能下架的问题。

实战开始

首先前期站点绑定工作同 https://www.anye.xyz/archives/yAwmyIp9。

EdgeOne 绑定加速站点

进入腾讯云官网

或者是国际版

输入站点域名开始接入

点击 绑定至已购套餐

备案域名可以 选择全球可用区（包含境内节点），接入方式按需选择，我这里选择 DNSPod 托管 ：

配置站点加速

点击 域名管理 ，新增加速网站，按需开启 IPv6 访问，使用 HTTPS 协议回源，按需选择加速模版后保存。

配置规则引擎

点击 站点加速，切换到 规则引擎 选项卡，点击 创建规则 ，使用空白规则进行添加：

按照如下内容进行填写：

匹配条件

执行动作

保存并发布。

修改站点配置

注意：本次演示使用 1Panel ，使用 Nginx / Openresty 等其他网站应用可参考编写。

反向代理/一键部署的站点

找到站点，点击 配置 - 反向代理 - 源文 ：

在 location 块的最上方添加：

if ($http_eo_verification_code != "xxxxxxxx") {
    return 444;
}

如图：

静态站点/运行环境

直接在 网站配置 - 配置文件 中添加，在 server { ... } 块的 最上层（即所有 location 块之前）。

保存并重载。

局限性

当然这种办法相较于 ip 限制的办法也有一定的局限性：

1. 请求头容易被伪造：虽然通过自定义请求头能有效区分来自 EdgeOne 的流量，但 HTTP 请求头本身是可以被伪造的。只要攻击者知道验证头的名称和值，就可以直接绕过验证。因此，不建议将校验值明文公开在前端页面或开源仓库中，应妥善保管，仅限服务端和 EdgeOne 配置中使用。

2. 无法防御 4 层（TCP/UDP）级别的攻击：请求头判断仅能在 HTTP 层面（即第 7 层）生效。如果遭受 SYN Flood、UDP Flood 等底层流量攻击，仍需依靠云防护或高防 IP 才能抵御。 换句话说，这种方案属于“应用层防护”，无法代替 EdgeOne 源站防护在网络层的安全能力。

总结

总的来说，这种“请求头验证”方案属于 轻量级源站防护替代方案，能在 EdgeOne 免费套餐下架相关功能后继续提供一定程度的安全防护。

它的优势在于部署简单、无需频繁维护 IP 白名单，劣势在于依赖请求头的保密性与正确配置。

若站点具有较高安全要求或面向公网高流量场景，建议仍考虑升级付费套餐或结合云防火墙、IP 限制策略共同使用，以达到更完善的防护效果。