这段时间不少人被 GCP 的 CDN 互联流量费用教育过，一觉醒来账单比机器还贵。
折腾了一圈，索性直接用 Google 自家的规则，在 VPC 层面把 CDN 流量提前掐掉，从源头避免 Egress 费用。
于是就有了这个东西 :backhand_index_pointing_down:
GCP CDN Egress Blocker 是干嘛的？
简单说一句话：
在流量还没离开 GCP 虚拟机之前，就直接丢弃发往主流 CDN 的出站流量。
脚本会自动抓取目前最常见的三大 CDN 服务商：
Cloudflare
Akamai
Fastly
通过 ASN → IP 段的方式，在 GCP VPC 防火墙层级生成出站拦截规则，从而规避这些 CDN 互联带来的高额流量账单。
:warning: 提前说清楚：
国外大量网站都依赖这三家 CDN
一旦启用，相当于你主动“失联半个互联网”
:backhand_index_pointing_right: 强烈建议：
系统、面板、程序、依赖全部装好之后再跑脚本
这个方案的核心思路
和 VM 里搞 iptables 不一样，这个脚本直接动的是 GCP 网络层：
流量在离开虚拟机前就被丢弃
不计入 CDN 出站流量
对实例性能几乎没有影响
重启、换 IP 都不影响规则生效
说白了，就是用 GCP 的规则，解决 GCP 自己的计费问题。
功能点概览（说人话版）
云端拦截
防火墙规则在 VPC 层生效，不进 VM、不算流量
自动更新
从 RADB 拉最新 ASN/IP 段，避免 CDN IP 变动漏网
交互式安装
可选每天 / 每周 / 每月自动更新
自检机制
一条命令就能知道拦没拦住
使用前的权限准备（很关键）
脚本需要操作 GCP 防火墙规则，权限不到位是跑不起来的。
方式一：直接给实例 API 权限（推荐）
停止 VM 实例
编辑实例 → API 访问范围
选择「为每个 API 设置权限」
Compute Engine 设置为 读写
保存并启动
方式二：IAM 授权
给实例使用的服务账号添加：
Compute Security Admin
安装 & 使用
:one: 安装依赖
Debian / Ubuntu
apt update && apt install whois coreutils -y
CentOS / RHEL
yum install whois -y
:two: 下载并运行
curl -O https://raw.githubusercontent.com/BlackReferee/gcp-cdn-blocker/main/gcp-cdn-blocker.sh
chmod +x gcp-cdn-blocker.sh
./gcp-cdn-blocker.sh
跟着提示选更新周期就行，基本不用动脑。
常用命令速查
命令 作用
update 立即拉取最新 CDN IP 并同步规则
check 检查三大 CDN 是否已被拦截
clear 完整卸载（清理规则 + 定时任务）
如何确认真的拦住了？
直接跑检测：
./gcp-cdn-blocker.sh check
正常情况会看到类似：
Cloudflare ... [ 成功拦截 ]
Akamai ... [ 成功拦截 ]
Fastly ... [ 成功拦截 ]
或者手动测试：
curl -I -m 5 https://www.cloudflare.com
返回 Connection timed out 基本就对了。
那 CDN 访问怎么办？（顺带说下 VMRack CDN）
GCP 这种玩法，本质是“切断高成本互联”，适合做后端、API、内网服务。
但如果你本身是对外提供内容分发的，就不适合这么硬拦。
这时候更合理的做法是：
源站放在 GCP / 其他云
前面用独立 CDN 扛流量
比如像 VMRack 提供的 CDN，思路就很清晰：
CDN 负责对外分发、缓存、抗攻击
源站只和 CDN 通信，流量路径可控
成本比 GCP 自带互联更直观
适合博客、下载站、静态资源、API 网关等场景
一个是“断流止血”，一个是“合理分流”，用在不同位置，思路完全不冲突。
总结一下
GCP CDN 互联贵，是事实
VPC 层拦截，比 VM 里折腾更干净
脚本适合 后端 / 内部服务 / 成本敏感场景
对外内容分发，还是老老实实上 CDN（比如 VMRack 这种）
有折腾价值，但别无脑上生产，用之前一定想清楚自己的业务形态。
有兴趣的 MJJ 可以自己跑跑看，账单变化会很明显。
