Google Cloud 静态公网 IP 怎么使用，哪些情况下需要固定服务器地址

刚开始使用Google Cloud时，很多人会遇到一个看似简单的问题：创建了一台Compute Engine虚拟机，Google给了一个公网IP，网站可以正常访问。过了一段时间，重新创建虚拟机、删除实例或者调整网络配置之后，却发现IP地址发生了变化。

这时候就会产生一个问题：到底什么时候需要静态公网IP？

答案并不是“只要服务器上线就必须购买静态IP”。

在Google Cloud中，静态IP的主要价值是让一个公网入口长期保持不变。但这个固定地址究竟应该绑定到VM、负载均衡器，还是根本不应该暴露公网，需要根据应用架构决定。

一、什么是Google Cloud的静态公网IP

Google Cloud中的外部IP地址大体可以分成临时的Ephemeral IP和静态的Static IP。

临时公网IP通常由Google Cloud自动分配。

例如创建一台Compute Engine虚拟机时，如果没有指定静态地址，系统可以自动给它分配一个外部IP。

这个IP并不是你永久拥有的资源。对于VM来说，实例停止或者删除等生命周期变化可能导致临时IP被释放。Google官方文档也明确区分了两种地址：静态IP在预留后会一直保留到用户主动释放，而临时IP不会永久绑定到资源。

静态公网IP则不同。

用户可以先预留一个地址，然后把它分配给VM或者负载均衡器的转发规则。即使相关计算资源发生变化，只要静态IP本身没有被释放，它仍然可以作为固定的网络入口。

这也是静态IP最核心的用途。

二、最简单的场景是给Compute Engine固定公网IP

假设你在Google Cloud上运行一台Linux服务器。

服务器上安装了：

Nginx

PHP

MySQL

WordPress

或者自己的Node.js、Python、Java应用。

如果只是测试服务器，使用临时IP完全可以。

但如果准备正式运行一个网站，就可能希望：

www.example.com

长期指向同一个公网入口。

这时候可以预留一个静态外部IP，然后将它绑定到VM。

Google Cloud目前支持在控制台的IP Addresses页面中预留静态外部IP，也可以通过gcloud命令完成。预留时需要选择IPv4或IPv6，以及Regional或者Global等属性；对于普通VM公网IPv4，通常使用Regional静态外部IP。

例如：

35.xxx.xxx.xxx

绑定到你的Web服务器。

DNS中的A记录：

www.example.com → 35.xxx.xxx.xxx

这样，网站的域名就有了一个稳定的公网入口。

三、但是，网站并不一定应该直接绑定VM公网IP

这是理解Google Cloud网络架构时非常重要的一步。

小型网站可以：

用户 → 静态公网IP → VM

但规模稍大的系统可能变成：

用户 → Global Load Balancer → 多台VM

这时候静态IP应该放在哪里？

通常不是每台VM都分别提供一个公网入口，而是把一个Global静态外部IP分配给负载均衡器。

用户永远访问这个地址。

负载均衡器再根据健康检查、区域、后端状态等条件，把请求转发给后端服务。

Google的Global external Application Load Balancer使用Global external IP作为对外入口，可以让用户访问一个固定地址，而后端服务器可以随时扩容、替换甚至跨区域部署。

这时候静态IP的意义已经不再是“固定某一台服务器”，而是“固定整个应用的入口”。

这两者完全不同。

四、域名并不严格要求服务器必须拥有静态IP

很多教程会告诉初学者：

“网站有域名，所以必须使用静态IP。”

这个说法不够准确。

DNS的A记录确实需要一个当前有效的IPv4地址，但技术上并没有规定这个地址必须是Static IP。

问题在于，如果服务器的公网IP发生变化，DNS记录就需要跟着修改。

例如：

第一次：

example.com → 35.100.100.100

服务器重新创建后变成：

35.100.100.200

那么原来的DNS记录仍然指向旧地址。

因此，真正的问题不是“DNS强制要求静态IP”，而是生产网站需要稳定的DNS目标。

使用静态IP可以把这个问题简单化。

Google官方文档也特别说明，在负载均衡器场景中，可以使用静态外部IP作为统一入口，再让DNS记录长期指向这个地址。

五、什么时候应该使用静态公网IP

最典型的情况有几个。

第一是正式Web服务器。

如果网站长期运行，并且域名通过A记录指向服务器，静态IP通常比较合适。

第二是API服务器。

例如：

api.example.com

被移动App、其他服务器或者合作伙伴长期调用。

如果IP发生变化，就可能影响访问，因此固定入口非常有价值。

第三是需要进行IP白名单控制的服务。

例如某个数据库、API或者后台系统规定：

“只有来自203.0.113.10的请求才能访问。”

如果这个出口IP经常变化，白名单就需要不断修改。

第四是VPN、远程访问以及某些网络设备。

对方系统往往需要知道一个长期稳定的公网入口，这时静态IP就比较有意义。

第五是负载均衡器。

这类场景中静态IP的重要性尤其高，因为它可以作为整个应用集群的统一入口。

六、什么时候完全没必要使用静态公网IP

如果只是临时测试服务器，就没有必要为了“看起来专业”而预留静态IP。

例如：

今天创建VM测试PHP；

测试完成以后删除；

过几天重新创建另一台VM。

这种环境使用临时IP就足够。

CI/CD测试机器、临时开发环境、一次性计算任务，也通常不需要为每台机器永久保留公网IP。

甚至对于正式生产系统，也不一定需要让每台VM都拥有公网IP。

更合理的设计可能是：

Internet

↓

Load Balancer

↓

Private VM

这样后端VM没有直接暴露在公网。

七、固定服务器地址不等于必须暴露服务器

这是云服务器安全设计中非常重要的一点。

很多初学者会认为：

“我要固定IP，所以必须给服务器一个公网IP。”

实际上完全不是这样。

可以把公网固定IP放在负载均衡器上，然后后端VM只使用私有IP。

例如：

example.com

↓

Global Static IP

↓

Google Cloud Load Balancer

↓

Private VM

这样外部用户只看到负载均衡器的公网入口。

后端服务器不需要直接暴露公网SSH或者Web端口。

这比“每台服务器都有一个公网IP”更加符合现代云架构。

八、Global和Regional不能混为一谈

Google Cloud的静态外部IP存在Regional和Global之分。

普通Compute Engine VM使用的外部静态IP通常是Regional资源。

如果你的VM位于：

us-central1

那么这个Regional IP属于相应区域。

而Global静态IP主要用于支持全球范围入口的网络服务，例如Global external Application Load Balancer。

Google目前的文档明确区分了Regional external Application Load Balancer和Global external Application Load Balancer，它们对应的转发规则和IP资源范围并不一样。

因此，不能简单地理解成：

“我要全球访问，所以把VM的IP设置成Global。”

真正需要Global IP的通常是全球负载均衡入口，而不是普通的一台区域VM。

九、Cloud SQL是一个特殊情况

如果使用Google Cloud SQL，就不能完全按照Compute Engine VM的思路理解。

Cloud SQL可以配置Public IP，也可以使用Private IP。

如果启用Public IP，Google Cloud会为Cloud SQL实例提供静态IPv4地址。

但如果应用本身运行在Google Cloud VPC里，很多情况下更值得考虑Private IP。

Google目前也明确建议，在没有特殊需求必须通过互联网访问Cloud SQL时，优先考虑Private IP。

如果确实使用Cloud SQL Public IP，还需要配置Authorized Networks等访问控制，并根据连接方式做好TLS等安全措施。

因此，“数据库需要固定公网IP”并不是默认答案。

很多时候更好的答案是：

数据库根本不应该暴露公网。

十、NAT的作用也经常被误解

假设你的VM使用私有IP，没有公网入口，但它需要访问：

Windows更新服务器；

Linux软件源；

GitHub；

第三方API；

其他互联网服务。

这时候可以使用Cloud NAT。

Cloud NAT允许私有网络中的资源访问互联网，而不需要给每台VM分配公网IP。

如果外部系统需要根据来源IP做白名单控制，Cloud NAT可以提供相对稳定的出口地址配置。

这和“别人从互联网访问你的服务器”是两个完全不同的方向。

一个是：

Internet → 你的服务

另一个是：

你的私有服务器 → Internet

前者考虑公网入口。

后者考虑公网出口。

理解这一点以后，很多Google Cloud网络配置就不会混乱。

十一、静态IP现在并不是简单的“每月10美元”

原稿中“静态IP每月10美元”的说法不适合作为现在的通用价格说明。

Google目前按照外部IP地址的具体使用方式计费。

以Google公布的当前标准费率为例，标准VM上使用中的静态或临时外部IPv4地址为每小时0.005美元；而预留了静态IP却没有分配给资源的地址，会按照更高的闲置费率计费。绑定到转发规则的静态外部IP目前不收这项IP地址费用。

所以真正需要提醒用户的是：

不要预留一堆不用的IP。

尤其是测试项目删除以后，如果静态IP没有释放，它仍然可能继续产生费用。

Google也提供了IP地址列表，可以查看地址当前是IN_USE还是RESERVED。

十二、固定IP也不是安全措施

这是另一个非常常见的误区。

静态IP解决的是：

“地址是否稳定。”

它并不解决：

“谁可以访问服务器。”

即使服务器使用静态IP，攻击者仍然可以扫描这个地址。

因此，静态IP应该与VPC防火墙规则、身份认证、HTTPS、SSH密钥、MFA以及最小开放端口原则结合使用。

例如Web服务器通常只需要开放：

80

443

而SSH不应该为了方便就对整个互联网无限开放。

如果后台管理系统可以限制来源IP，则可以进一步增加网络访问控制。

十三、实际项目应该怎么选择

如果只是测试PHP：

使用临时IP即可。

如果是一台长期运行的小型网站：

可以给VM分配Regional静态外部IP。

如果是正式网站，并且未来可能扩容：

可以考虑Global Load Balancer + Global静态IP，后端VM使用私有IP。

如果是Cloud SQL：

优先考虑Private IP；只有确实需要互联网访问时再考虑Public IP。

如果是私有服务器访问互联网：

考虑Cloud NAT，而不是给每台服务器直接分配公网IP。

如果合作伙伴要求把你的出口IP加入白名单：

应该重点考虑固定的出口IP，而不是简单给服务器增加一个公网入口。

这样一来，“我要一个固定IP”这个需求就可以进一步拆成三个问题：

我要固定入口吗？

我要固定出口吗？

还是其实根本不应该使用公网IP？

这三个问题对应的是完全不同的Google Cloud网络架构。

十四、真正需要固定的不是“服务器”，而是服务入口

云计算和传统服务器最大的区别之一，就是不要把“服务器”和“服务地址”看成同一个东西。

传统服务器时代，一台机器往往就是一个网站，一个公网IP就是这台机器的地址。

云环境则不同。

VM可以删除。

VM可以重新创建。

后端可以扩容。

服务器可以跨区域迁移。

甚至整个计算集群都可以随时替换。

如果用户访问的是一个固定的负载均衡器地址，那么后端怎么变化，用户都不需要知道。

所以在现代Google Cloud架构中，静态IP最重要的价值不是“给某一台服务器永久贴一个地址”，而是为一个需要长期稳定访问的网络入口提供固定标识。

如果只是开发测试，临时IP完全够用；如果是正式网站、API、VPN、白名单系统或者负载均衡入口，静态IP才开始体现价值；而对于数据库和内部服务器，则应该先问一句：这个服务到底有没有必要暴露到公网？

把这个问题想清楚，往往比单纯申请一个静态IP更加重要。