谷歌云企业账号购买 谷歌云 VM 绑定外网 IP 依然无法访问公网？GCP 防火墙与 NAT 常见排查坑点
这个问题我在 GCP 开通后最常遇到：VM 明明已经挂了外网 IP，SSH 也能连上，但 curl 不出去、apt 更新失败、业务请求超时。大多数时候，不是“云有问题”，而是下面四层里有一层没打通：
- 账号和 billing 没处理好，项目其实处于受限状态
- VPC 防火墙只放了入站，出站被拦了
- 路由或 Cloud NAT 没配对，或者配错区域
- 操作系统本地防火墙、DNS、代理把流量卡住了
先别猜，先判断你卡在哪一步
| 现象 | 更可能的原因 | 优先检查 |
|---|---|---|
| 能 SSH，不能访问外网网站 | 出站防火墙 / DNS / 系统代理 | VPC egress、nslookup、curl |
| 有外网 IP，但 ping 8.8.8.8 都不通 | 默认路由被删、组织策略限制、系统防火墙 | routes、iptables/ufw |
| 没外网 IP，业务想主动访问公网 | 需要 Cloud NAT | Cloud Router + NAT 是否同区域 |
| 只能访问 Google 部分服务 | DNS 或 Private Google Access 误解 | 解析结果、网关策略 |
1）账号、实名认证、充值没过关，先别急着排网络
很多人排查网络时忽略了最基础的一步：项目 billing 是否已正常绑定。GCP 新账号常见几个坑：
- 信用卡验证失败，账号能进控制台，但项目创建受限
- 企业实名资料不一致，触发人工审核
- 付款方式被风控拒绝，充值后仍显示待验证
- 账号处于欠费或暂停状态，资源看着还在，实际策略已经变严
实操建议：
- 个人账号优先用真实姓名 + 可验证的信用卡
- 企业账号尽量用公司域名、营业执照、统一账单信息
- 不要用来源不明的“成品号”，后续风控概率很高，出了问题很难申诉
支付方式上，GCP 不同地区差异很大。常见情况是：信用卡最稳，借记卡不一定稳定，企业客户才更适合走月结或发票流程。如果你的卡刚绑定就被拒，先别反复重试，频繁失败更容易触发风控。
2）外网 IP 绑了，不代表出站一定放行
这是最容易踩的坑。很多人只加了“允许 SSH / RDP 的入站规则”，却没看出站规则。GCP 默认通常是允许出站，但一旦你用了自定义 VPC、组织级安全策略、Shared VPC，就很可能变成默认拒绝。
重点看这几个点：
- 方向：你要排的是 egress，不是 ingress
- 目标对象：规则是绑到 instance tag，还是 service account
- 优先级：deny 规则优先级是否高于 allow
- 端口：至少先放行 80、443、53（DNS）、ICMP（测试用）
如果你看到“能连 SSH，但 curl https 失败”，很多时候就是 443 被挡，或者 DNS 53 没放行。
3）有外网 IP 还不通，检查路由和 NAT 的“区域配对”
如果 VM 没有外网 IP，那出公网必须靠 Cloud NAT。这个场景最常见的错误有三个：
- 只建了 NAT，没有建 Cloud Router
- NAT 和 VM 不在同一个区域
- 子网选错，NAT 没覆盖到实例所在 subnet
如果 VM 有外网 IP 仍然不通，重点查默认路由是否存在：0.0.0.0/0 是否指向 internet gateway。很多人导入自定义网络模板时，把默认路由删掉了，结果“看起来有公网 IP，实际上出不去”。
# Linux 上可快速看三件事
ip route
curl -4 https://ifconfig.me
nslookup google.com4）别忽略 OS 防火墙和 DNS，这两类问题最像“公网故障”
我见过不少工单，最后发现不是 GCP 网络，而是系统层面拦了：
- Ubuntu 上 ufw 默认拒绝出站
- iptables 写过旧规则，重启后仍然生效
- Windows Server 本地防火墙限制了出站 80/443
- DNS 指到了内网解析器，外网域名解析失败
判断方法很直接：
- 能访问 IP，不能访问域名：优先查 DNS
- 连 IP 都不通：优先查路由 / 防火墙 / NAT
- SSH 可以，业务端口不行：优先查应用监听和本机防火墙
5）外网 IP、Cloud NAT、负载均衡，成本别只看“有没有公网地址”
很多人一开始为了省事，给 VM 直接绑外网 IP；等到实例一多，管理和安全压力就上来了。实际成本上，建议这样看：
| 方案 | 适合场景 | 成本感受 | 风险点 |
|---|---|---|---|
| VM 直连外网 IP | 单台测试机、临时环境 | 低门槛，但静态 IP 可能产生持续费用 | 暴露面大，安全组容易配错 |
| 私网 + Cloud NAT | 批量实例、生产环境、自动扩缩容 | 有 NAT 网关与流量费用 | 区域、子网、路由容易配错 |
| 负载均衡 + 后端私网 | 对外提供 HTTP/HTTPS 服务 | 费用更高，但控制更细 | 配置项更多，排障路径长 |
如果你只是想让 VM 主动访问外网拉包、同步 API，私网 + NAT 通常比“每台机器绑公网 IP”更好管。反过来，如果你是临时测试，直接挂外网 IP 反而更省时间。
谷歌云企业账号购买 6）真实排查顺序：我建议按这个顺序走
- 确认 billing 已启用，项目没有欠费或暂停
- 确认 VM 是否真的绑定了外网 IP
- 谷歌云企业账号购买 看 VPC 是否存在默认出站放行，或者有没有 deny-all egress
- 检查默认路由是否还在，是否指向 internet gateway
- 如果是私网实例，确认 Cloud NAT 同区域、同 subnet 已覆盖
- 进入 OS 层，排查 ufw / iptables / Windows 防火墙 / 代理 / DNS
7）几个高频失败案例
案例 A：客户刚开通 GCP，信用卡验证失败，项目能登录但很多操作受限。后来把付款方式修正后，VM 网络立刻恢复。这里表面像“公网不通”，本质是账号状态异常。
案例 B：Shared VPC 环境里，管理员在错误的项目里加了防火墙规则，服务项目里的 VM 根本没吃到规则。解决方式是回到 host project 检查。
案例 C：Cloud NAT 已建好，但 VM 在另一个区域。因为 NAT 没覆盖到对应 subnet，出站一直失败。很多人就是在这里卡半天。
FAQ：用户最常问的几个问题
Q1：有外网 IP 为什么还要 NAT？
A：有外网 IP 的实例通常不需要 NAT；没有外网 IP 的实例才需要。很多人是把两种场景混在一起了。
Q2：能 SSH，为什么网页访问不通？
A：SSH 通只能说明 22 端口通，不代表 80/443 放行。还有一种情况是 DNS 或代理出问题。
Q3：GCP 账号刚开就连不上公网，是不是风控？
A：先看 billing 和防火墙。只有当你发现项目创建、规则修改、NAT 开通都异常受限时，再去看风控审核。
Q4：企业账号和个人账号排障有什么差别？
A：企业账号更常见的是实名、付款、组织策略、Shared VPC 这些额外限制；个人账号更多是信用卡验证和额度问题。
如果你现在的情况是“VM 有外网 IP，但公网还是不通”，优先别在公网 IP 上纠结，先按 billing → VPC egress → route → NAT → OS 防火墙/DNS 这个顺序查，基本都能在 15 分钟内缩小范围。
