在云计算的日常运维中，最让人抓狂的瞬间，莫过于服务明明已经成功启动，但在本地浏览器或终端里敲下回车时，等待你的却是一行冷冰冰的“连接超时（Connection Timed Out）”。

对于很多刚通过第三方渠道完成谷歌云账号购买并兴冲冲部署新项目的新手来说，这种情况几乎是个必经的“新兵连洗礼”。你可能反复确认了代码没问题、程序端口（比如 Web 服务的 80/443、宝塔面板的 8888、或者是数据库的 3306）已经在实例内部正常监听（Listen），但公网就是死活访问不进去。

这时候，99% 的原因都指向了同一个地方：Google Cloud（GCP）的防火墙规则（Firewall Rules）配置错误。

谷歌云的防火墙是其 VPC（专有网络）安全架构的第一道防线，默认采用“隐式拒绝所有入站流量”的严格策略。如果你不主动、正确地给它“开绿灯”，你的实例就是一座物理隔离的孤岛。今天这篇文章，我们就用最接地气的真人写作风格，把 GCP 防火墙的底层逻辑、常见配置大坑以及如何一步步排查解决端口不通的问题彻底聊透。

1. 底层逻辑：为什么你的“理所当然”在 GCP 行不通？

很多从传统物理服务器或者某些国内轻量应用服务器转过来的开发者，习惯了“在系统内部用 iptables 或 ufw 放行端口”的思维。但在谷歌云的生态里，这是远远不够的。

谷歌云的防火墙是分布式防火墙。

这意味着它不是运行在你的虚拟机（VM）操作系统内部，而是驻留在虚拟化网络的底层结构中。当一个公网数据包试图访问你的服务器时，它在还没触碰到你的 Ubuntu 或 CentOS 系统内核之前，就已经在谷歌云的路由器层面被拦截并丢弃了。因此，即使你在系统里把防火墙完全关闭（systemctl stop firewalld），只要 GCP 控制台的规则没配对，端口依然是不通的。

当你完成谷歌云账号购买并开通默认网络（Default Network）时，谷歌虽然会预设几个诸如放行 Ping（ICMP）、内部互通、以及默认 SSH（22 端口）和 RDP（3389 端口）的规则，但任何自定义的生产环境端口，都需要你手动去雕刻规则。

2. 经典翻车现场：GCP 防火墙配置的四大“大坑”

我们在排查了无数个“端口不通”的案例后，总结出了以下四个最容易让人抓狂的配置错误。对照一下，看看你踩了哪一个？

坑一：目标（Targets）选项选错了“白名单”

在创建防火墙规则时，有一个选项叫 “目标（Targets）”。它决定了这条规则对你 VPC 里的哪些机器生效。

• 新手常犯错误：误以为“目标”是指允许谁来访问我，于是把目标选成了“指定的非托管实例”或特定的网络标签，导致规则根本没有应用到当前卡顿的实例上。

• 正确理解：目标是指“这条规则要保护/应用在哪台服务器上”。如果你想让这条规则对整个网络里的所有机器生效，最省事的方法是将目标选为 “网络中的所有实例（All instances in the network）”。

坑二：源 IP 范围（Source IP ranges）填了“悄悄话”

另一个高频出错点是 “源 IP 范围（Source IP ranges）”。

• 新手常犯错误：想要让全网用户都能访问自己的网站，于是在源 IP 范围里填了实例自己的公网 IP，或者填了 10.x.x.x 这样的内网私有网段。结果就是除了服务器自己或者内网机器，外部谁也进不来。

• 正确写法：如果你希望该端口面向整个互联网开放（比如 Web 服务），源 IP 范围必须填写 0.0.0.0/0。这里的 /0 代表匹配全世界所有的 IPv4 地址。

坑三：网络标签（Network Tags）拼写不一致（最隐蔽的隐形杀手）

如果你在“目标”中选择了 “指定的协议标签（Specified target tags）”，你就需要给规则起一个标签名（比如 web-server），同时还要去实例（VM 实例）的详情页里，把这个标签手动贴在机器上。

• 大坑所在：这个标签是严格区分大小写且不能有空格的。如果你在防火墙规则里写的是 Web-Server，而在实例上贴的是 web-server，谷歌云的系统无法识别，规则直接沦为摆设。

坑四：协议和端口（Protocols and ports）没分清 TCP 和 UDP

• 新手常犯错误：在指定端口时，只勾选了“全部允许”，或者在指定协议时把 TCP 错选成了 UDP。比如很多代理协议或自定义游戏服务端同时需要 TCP 和 UDP，如果少配了一个，服务就会表现为“时通时断”的诡异状态。

3. 硬核实战：端口不通的“四步诊断与自救法”

既然知道了坑在哪里，当遇到端口不通时，我们应该按照怎样的逻辑链条去排查呢？请把下面这四步诊断法保存好。

第一步：确认服务在“内网”是活的（排除系统内部问题）

在怀疑谷歌云之前，先确认你自己的程序真的起来了。

使用 SSH 连入你的 GCP 实例，运行以下命令：

netstat -tunlp | grep 端口号# 或者ss -tunlp | grep 端口号

如果看到输出中有 0.0.0.0:您的端口 或者 :::您的端口，且状态为 LISTEN，说明程序正常。如果绑定的是 127.0.0.1:您的端口，那完蛋了，这说明程序只接受本地访问，你需要修改程序的配置文件，把监听地址改成 0.0.0.0。

第二步：检查系统内自带防火墙

在终端执行：

# 如果是 Ubuntusudo ufw status# 如果是 CentOSsudo firewall-cmd --state

如果系统防火墙是开启的，记得先用命令放行对应端口，或者在测试期间索性直接将其关闭，排除系统内干扰。

第三步：去 GCP 控制台扮演“安检员”（标准配置流程）

确认内部没问题后，登录谷歌云控制台，开始配置或检查你的防火墙规则：

1. 导航栏找到 “VPC 网络（VPC network）” ➔ “防火墙（Firewalls）”。

2. 点击 “创建防火墙规则（Create Firewall Rule）”。

3. 网络（Network）：选择你实例所在的 VPC（默认通常是 default）。

4. 方向（Direction of traffic）：选择 入站（Ingress）（因为是外部流量请求进来）。

5. 对匹配项执行的操作（Action on match）：选择 允许（Allow）。

6. 目标（Targets）：推荐先选 网络中的所有实例 来做排查。

7. 源过滤条件（Source filter）：选择 IPv4 范围。

8. 源 IPv4 范围：输入 0.0.0.0/0。

9. 协议和端口：勾选 指定的协议和端口，勾选 TCP 并在后面填入你的具体端口号（如 8888）。

10. 点击 创建，静候 10 秒钟让分布式网络同步规则。

第四步：使用终极武器——谷歌云“连接测试（Connectivity Tests）”

如果你配完了还是不通，不要盲目乱猜。谷歌云控制台自带了一个非常强大的排查黑科技——网络智能（Network Intelligence） 下的 “连接测试”。

1. 在控制台搜索栏输入 “Connectivity Tests”。

2. 创建一个测试，源选择“任意公网 IP”，目的地选择你的“VM 实例实例”，并填入测试端口。

3. 运行测试后，谷歌云会以可视化的图形进度条告诉你：数据包走到了哪一步。是卡在互联网网关了，还是被某一条具体的防火墙规则（还会贴心地列出规则名字）给拒绝了。跟着这个提示去删改规则，一抓一个准。

4. 防火墙配置一览表（拿来即用模板）

为了方便大家在完成相关的初始化或谷歌云账号购买后能迅速上手，我们把最常用的几种服务防火墙配置总结成下表：

结语

谷歌云（GCP）那看似复杂的防火墙逻辑，背后其实是一套极其严密、也是对企业级安全极度负责的架构设计。刚通过各种途径完成谷歌云账号购买的用户，在面对“端口不通”的下马威时大可不必焦虑。

记住，云计算时代的运维，讲究的是“逐层剥离”。从实例内部的进程监听，到操作系统的策略限制，再到最核心的 GCP 分布式防火墙规则，只要顺着“入站方向 ➔ 全部实例 ➔ 0.0.0.0/0 ➔ 正确的 TCP/UDP 协议”这条线索去排查，再顽固的端口不通问题，也会在你的掌控中迎刃而解。