GCP 永久免费出流量只有 1GB/月？2026 出流量极限与省钱架构

Google Cloud 的永久免费层（Always-Free）常被拿来和 Oracle 比，但它有一个让很多人"翻车"的硬伤：出流量（egress）每月只有 1GB。相比之下 AWS 有 15GB、Oracle 干脆不限（免费实例本身流量不另收）。这 1GB 到底够干嘛、超了怎么算、怎么用架构把钱省回来，就是本文要算清的账。

一、GCP 永久免费到底包含什么

永久免费的核心是一台 e2-micro（或老 f1-micro） 实例，限制很具体：仅限 us-east1、us-west1、europe-west1 三个区域，1 个共享 vCPU、约 1GB 内存、每月 30GB 标准硬盘、每月 1GB 出流量、外加 5GB Cloud Storage 和少量 BigQuery / Pub/Sub 额度。注意：这台机器是"微型共享核"，性能勉强够一个轻量服务，但绝对扛不住任何并发。1GB 出流量是它的命门。

二、1GB/月出流量到底能干嘛（算账）

1GB = 约 1000MB。一个普通 HTML 页约 50KB，加载一次（含 CSS/JS 图片）按 500KB 算，1GB 大约够 2000 次完整访问。看起来还行？但现实里：一张未压缩的 2MB 图片被加载 500 次就用光了；一个返回 JSON 的 API 每次 10KB，10 万次调用就爆。更要命的是，GCP 的 1GB 是全球出流量合计，你从美国节点回源到亚洲用户，跨境那段也计入。所以 1GB 对"有人看的站点"几乎等于没有，只够纯实验或内部工具。

三、出流量超限怎么计费

GCP 出流量按"阶梯定价"：前几 TB 大约 0.12 美元/GB 起（美→美洲），到亚太、跨洋更贵（0.18~0.23 美元/GB 区间）。一旦你那 1GB 免费额度用光，每多 1GB 就按这个单价扣。一个突然被推荐的帖子，可能让你单日多出几十 GB 出流量，账单直接三位数。这和在 AWS 上踩出流量坑是同一种痛。

四、用 Cloudflare 兜底出流量（省钱架构）

核心思路：让 GCP 免费实例只做"源站"，把公开流量全部交给 Cloudflare 的边缘缓存。具体做法：域名 DNS 托管到 Cloudflare，开启橙色云（Proxy），把静态资源（图片、CSS、JS）设为 Cache Everything 或长缓存。这样绝大多数用户请求被 Cloudflare 边缘命中，根本不打到 GCP 源站，GCP 的出流量近乎为零。更进阶：把图片、大文件直接丢进 Cloudflare R2（兼容 S3 API，有免费额度），源站彻底不吐大文件。这一套下来，GCP 的 1GB 出流量基本永远用不完。

五、GCP 免费层适合搭什么

最适合：内部 API / Webhook 接收端、GitHub Actions 之外的轻量 CI runner、个人笔记后端、配合 Cloudflare 做源站的"几乎不出流量"架构。最不适合：会被公开大量访问的站点（出流量天花板太低）、需要稳定延迟的回国业务、任何出流量不可控的服务。如果你要的是"免费且能对外扛量"，GCP 单靠自己做不到，必须靠 CDN 兜底。

六、FAQ

Q：1GB 出流量能不能调大？ A：不能，这是永久免费硬上限，想多只能付费或换架构（CDN 兜底）。Q：e2-micro 和 f1-micro 选哪个？ A：新账号默认 e2-micro，更省且性能略好，优先它。Q：和 Oracle 比谁更值？ A：要出流量和内存选 Oracle（不限流量 + 大 ARM）；要做 Google 生态 / 配合 Firebase 选 GCP。Q：CDN 兜底后还怕超吗？ A：静态资源走 Cloudflare 后源站出流量极低，基本不会超；但动态 API 回源仍会吃那 1GB，建议 API 也尽量缓存或限流。

七、结论：1GB 是天花板，不是地板

GCP 永久免费是一台"好用的微型实验机"，但 1GB/月出流量是它绕不开的天花板。把它当源站、用 Cloudflare 扛公开流量，这套架构能让你几乎零成本跑起一个对外服务。想更系统省流量，读 Cloudflare Tunnel 自建 与 免费层 + CDN 静态站。要更稳的出流量与更大内存，再看 免费层合集 和本站 年付档位。

八、延伸：GCP 免费层与别家云的组合

GCP 的 1GB 出流量短板，不一定要靠 Cloudflare alone 补——还有"异构组合"玩法：把 GCP 免费实例当纯计算 / 定时任务节点（如每天跑一次爬虫、出结果推到别处），出流量本身极低；把对外服务拆给 Oracle 永久免费 或本站 年付小机。这样 GCP 只做"不出网的脑子"，1GB 永远用不完，还白嫖了它的稳定算力与 BigQuery 免费额度。对"要 Google 生态又不想被出流量卡死"的用户，这套组合最省心。

九、延伸：监控与预算告警实操

真正能防超的，是"看得见"。除了 Budgets 告警，建议再开 Cloud Monitoring 的免费指标盯实例 CPU / 网络，一旦异常流量冒头立刻发觉；并用 Cloud Logging 的日志 sink 把关键请求落到 BigQuery 免费层做长期审计。再进阶：写个 Cloud Function（也在免费额度内）定时比对昨日 egress，超阈值就发邮件。把"被动等账单"变成"主动盯仪表盘"，GCP 免费层就能长期稳稳薅羊毛而不翻车。

十、延伸：GCP 免费层的"冷启动"与应对

e2-micro 是共享核，长时间无请求会被"挂起"，下次访问要冷启动几百毫秒。对静态站（CDN 兜底）无感；对 API 服务，建议加个小保活：用 Cloudflare 的 Health Check 或外部 uptime 监控每几分钟探一次，让实例保持温态。或者在前面挡一层 Cloudflare Workers 做缓存，冷启动的那一下由边缘返回旧值，用户无感。把冷启动当成"免费层的呼吸"，用缓存遮住它。

十一、延伸：把 GCP 当"构建 / 批处理"节点

除了当源站，GCP 免费实例极适合做"计算节点"：GitHub Actions 的免费额度有时不够，把重构建 / 视频转码 / 数据批处理丢到 GCP 免费 e2-micro 上跑（低频、可中断），CI 只负责触发和收结果。这样 CI 额度省下、GCP 的 1GB 出流量也不被碰（结果走对象存储外链）。对"要 Google 生态 + 不想被出流量卡死"的用户，这是比对外服务更稳的免费层用法。

#GCP免费 #出流量极限 #1GB每月 #Cloudflare兜底 #e2micro #省钱架构 #源站缓存 #永久免费 #CDN