谷歌云个人实名 GCP谷歌云防火墙开放端口教程

前言：开端口这件事，听起来很猛，其实有章法

在 GCP 上开放端口，本质上就是在防火墙规则里“允许某些网络到你的某台实例（或一组实例）来访问某个端口”。说人话：你要让别人进你的小区，但先得告诉保安——谁可以进、从哪个门进、进来要找谁、能不能在你家门口乱敲门。

很多新手之所以会踩坑，不是因为不会点按钮，而是把“能访问”和“安全”当成两件事：要么盲开端口，要么一通乱改导致服务永远起不来。本文就带你把流程理顺：你会知道每一步在做什么、为什么这么做，以及常见错误怎么自救。

准备工作：先想清楚三件事（不然你会开出一堆“没用的规则”）

1）你要开放的端口是多少？

比如：

• SSH：22
• HTTP：80
• HTTPS：443
• 数据库：3306（MySQL）、5432（PostgreSQL）等
• 自定义服务：例如 8080、3000、5000

注意：你开端口是给“服务监听的端口”开，不是给“你觉得应该能访问的端口”开。比如你的 Nginx 正在监听 80，你却放行 8080——恭喜你，访问永远连不上，锅通常会被推到“网络不通”上。

2）你的实例在哪个 VPC 里？

GCP 防火墙规则是绑定到 VPC 的。你得知道你的虚拟机（VM）属于哪个 VPC（网络）。

如果你不确定，可以在控制台点到 VM 实例详情，看看网络标签和网络所在的 VPC。

3）你希望谁能访问？（这是安全问题，也是效率问题）

理想状态是“只允许你需要的人访问”。例如：

• 只允许公司公网 IP：比如 203.0.113.10/32
• 只允许某个网段：比如 10.10.0.0/16
• 只允许 LB 的健康检查（如果你用负载均衡）
• （不建议）开放给所有人 0.0.0.0/0

谷歌云个人实名 开放给所有人并不等于一定会出事，但它会让你的暴露面变大，日志更吵，扫描更频繁，安全事件排查更痛苦。

核心概念速通：GCP 防火墙规则怎么玩

在开始“动手开端口”之前，先把关键概念摆正。你之后看控制台会少走很多弯路。

1）入站规则（Ingress）才是“开放端口”的主要入口

开放端口通常指的是入站（IN），因为外部访问你的服务就是从网络进到实例。

出站（Egress）是“你从实例向外访问”。两者不要搞混。

2）目标（Targets）决定规则作用到哪些实例

规则不一定对所有实例生效。常见选择有：

• 把规则作用到带某个网络标签（Network Tags）的实例
• 作用到某个服务账号（Service Account）相关资源（更少用在新手阶段）
• 作用到整个网络（All instances in the network）——这就比较“广撒网”了

新手一般推荐用“网络标签”。原因很简单：你可以只给某些机器放行，不会误伤其他服务。

3）优先级（Priority）决定谁说了算

GCP 会按规则优先级从小到大匹配（数字越小优先级越高）。如果存在冲突（比如某规则允许，另一规则拒绝），优先级会影响最终效果。

所以千万别在同一个端口上“允许一条、拒绝一条、再来一条”，最后你自己都分不清到底到底拦了还是放了。

4）日志（Logs）建议开起来，排查会轻松很多

尤其你在测试连通性时，日志能告诉你“请求有没有打到防火墙层”，“被放行还是被拒绝”。不然你只能在另一端盲猜。

步骤一：在 VM 上确认服务确实在监听目标端口

这一步很关键。很多人把精力全投入防火墙，却忘了服务可能压根没起来、监听错端口、或绑定在 127.0.0.1 导致外部连不上。

以 Linux VM 为例，你可以在实例里执行类似检查（不同发行版命令略有差异）：

• 检查是否监听：ss -lnt 或 netstat -lnt
• 检查服务状态：systemctl status 你的服务名
• 检查 Nginx/应用配置的 listen 地址和端口

如果你开的是 SSH 22，但服务并未配置，或者系统上根本没运行 SSH，就算防火墙放行了你也进不来。

步骤二：给目标 VM 加网络标签（推荐做法）

假设你有一台 VM，要开放 8080 给外部访问。我们可以给这台 VM 打一个标签，例如：

network tag：web-8080

具体操作路径（控制台一般会在这个方向）：

• 进入 Compute Engine > VM 实例
• 选择你的实例
• 在网络标签（Network tags）里添加标签

加完标签之后，再回到防火墙规则里，就能用“目标标签”去精确生效。

小提醒：加标签后一般无需重启实例，但要确保你保存并生效。你不放心的话，就稍后看防火墙日志判断匹配是否正确。

步骤三：创建防火墙规则（放行入站端口）

现在进入教程主场景：创建一条规则，允许某端口入站。

1）打开防火墙管理页面

• 进入 Google Cloud 控制台
• 找到 VPC 网络 > 防火墙（Firewall）
• 点击“创建防火墙规则”

2）基本配置建议（按你想开放的端口来）

你会看到几个关键字段：

规则名称（Name）

建议写得清楚点，比如：

• allow-web-8080
• allow-ssh-from-office
• allow-https-public

以后你排查的时候看到名字就能知道用途，少掉一半“我当时怎么想的”的痛苦。

网络（Network）

选择你的目标 VPC。通常就是 VM 所在的那个网络。

优先级（Priority）

新规则一般用一个较常用的数字，比如 1000、1000 这类（具体策略你可以按现有规则情况调整）。

经验法则：如果你不是特别确定，不要瞎给很小的优先级去抢戏，避免跟现有规则冲突。

方向（Direction）

选择“入站（Ingress）”。

目标（Targets）

选择“指定目标标签（Target tags）”。然后填你刚才加在 VM 上的网络标签，例如：

• web-8080

这样这条规则只对打了这个标签的实例生效。

源过滤（Source IP ranges）

这里是安全核心。你要填允许的来源网段。

常见情况：

• 只允许你自己的公网 IP：x.x.x.x/32
• 允许公司网段：10.0.0.0/8 或你的实际网段
• 测试环境临时开放给全网：0.0.0.0/0（不建议长期这样）

如果你是开放 HTTP/HTTPS 给公网用户，0.0.0.0/0 可能是你“不得不”的选择，但建议至少配合负载均衡、WAF（如果条件允许），并且确保只开放必要端口。

协议与端口（Protocols and ports）

一般你会选择：

• 协议：tcp
• 端口：8080（或 80/443/22 等）

如果是 UDP 服务，也按实际填写。

操作（Action）

选择“允许（Allow）”。

日志（Logs）

建议选择“启用日志记录”。这样你能在出现连接问题时，通过日志快速判断请求到底落没落进来。

步骤四：测试连通性（别急着怀疑世界，先验证路径）

防火墙规则创建完成之后，不要立刻在脑子里写“它是不是没生效”。你可以按顺序做验证。

1）确认防火墙规则状态

回到防火墙列表，确认规则是“启用”。有些人创建完发现自己其实只是草稿，或者后面不小心关掉了。

2）用外部客户端测试端口

常用方式：

• 谷歌云个人实名 HTTP：curl http://你的公网IP:端口
• HTTPS：curl -k https://你的公网IP:端口（测试证书时）
• 端口连通：telnet 或 nc（如果你有工具）

如果你测试 SSH：

• ssh -p 22 你的用户@公网IP

如果源 IP 不是你填的范围，那就是你规则写得再漂亮，也会被防火墙拒掉。

3）查看防火墙日志（真·救命工具）

当你发现“怎么都连不上”，日志能告诉你请求是否匹配该规则，以及最终被放行还是拒绝。

日志通常能帮助你快速定位以下常见问题：

• 你访问的源 IP 不在允许网段
• 实例没有打上你填的目标标签
• 端口写错了（例如你以为 8080，实际应用监听 3000）
• 协议不匹配（tcp/udp 搞反）

常见坑位集合：避免你在夜里“对着防火墙发呆”

坑 1：只开了防火墙，应用却只监听在本机（127.0.0.1）

谷歌云个人实名 很多开发环境会把绑定地址写成 127.0.0.1，导致外部访问不到。解决办法是让应用监听 0.0.0.0 或你的内网网卡地址。

你可以把它理解为：你在屋里敲门，但门锁在房间里面。

坑 2：实例没打网络标签，规则等于“对着空气开炮”

谷歌云个人实名 你在防火墙规则里填了 Target tags = web-8080，但实例上根本没有这个标签。于是规则生效不了。

解决：在 VM 实例里确认 Network tags，确保和规则一致。

坑 3：优先级冲突导致最终被拒绝

你开了一条 allow，但如果存在更高优先级的 deny（或默认策略），结果可能仍然失败。

解决：查看同端口同方向的其他规则，合理调整优先级，减少冲突。

坑 4：源 IP 写错（尤其 /32 与网段混淆）

你以为填了自己的 IP，但其实少了 /32 或者写成了错误网段，导致匹配不上。

比如你要允许单个公网 IP：x.x.x.x/32。

坑 5：你以为开了入站就够了，实际上还有负载均衡/路由层限制

如果你的流量走的是负载均衡（LB）、云防护服务或自定义路由，可能还有其他层规则影响。

解决：确认你的访问路径：直连 VM？还是走 LB？还是走某个转发规则？

进阶建议：把安全做“更体面”，而不是“侥幸成功就行”

开放端口只是第一步。想让事情更稳，建议你加一些“工程化”的安全习惯。

1）尽量只开放必要端口

比如你只提供 Web 服务，就别顺便开放一堆管理端口。能关就关，少暴露一分钟都少一份风险。

2）为管理端口（如 SSH）做来源限制

如果你开放 SSH，建议只允许办公室公网 IP 或跳板机来源网段。别把 22 对着全世界。

全世界对 22 的热情，想必你已经体会过了：日志会像“吐槽大会”一样刷屏。

3）配合使用健康检查与负载均衡（面向公网服务）

如果你提供公网 Web 服务，使用负载均衡比直接把端口暴露给所有人更符合生产习惯。它也更方便做 TLS 证书管理和扩展。

4）开启日志，并定期检查被拒绝/被允许的情况

日志不是为了“追凶”，也是为了“预防”。你可以从日志看到：

• 谷歌云个人实名 哪些 IP 在尝试访问你开放的端口
• 是否有异常频率
• 是否有规则匹配失败（比如标签没打上）

示例场景：几种常见“开放端口”你可以直接套

场景 A：开放 HTTP 80 给公网访问（不建议长期裸露但演示友好）

• Direction：Ingress
• Target tags：例如 web
• Source IP ranges：0.0.0.0/0（公网）
• Protocol：tcp
• Port：80
• Action：Allow

注意：只对打了 web 标签的实例生效。

场景 B：开放 HTTPS 443 给公网（更推荐用 LB，但这里先讲防火墙）

• Direction：Ingress
• Target tags：例如 web
• Source IP ranges：0.0.0.0/0
• Protocol：tcp
• Port：443
• Action：Allow

如果你还要做证书与重定向，通常由应用或负载均衡负责。

场景 C：只允许办公室 IP 访问 SSH 22

• Direction：Ingress
• Target tags：例如 allow-ssh
• Source IP ranges：203.0.113.10/32（示例）
• Protocol：tcp
• 谷歌云个人实名 Port：22
• 谷歌云个人实名 Action：Allow

建议配合二次认证、禁用密码登录等措施（取决于你的安全策略）。

总结：你要记住的不是“点了哪里”，而是“规则到底在放行什么”

开放端口这件事，在 GCP 上其实是一个可控、可追踪的过程。你需要抓住几个要点：

• 先确认应用监听正确端口
• 用入站规则放行（Ingress）
• 用目标标签（Target tags）把规则精准绑到实例
• 用源 IP 范围控制谁能访问（别乱开全网）
• 必要时开启日志，排查会从“玄学”变成“读账本”

做完这些，你就不会被“连不上”搞得像在跟宇宙搏斗。GCP 的防火墙不是怪物，它只是一个很认真的门卫：你给了对的信息，它就放行；你给错了，就会很礼貌地拒绝。

祝你端口顺利通行，线上服务跑得稳，日志看得爽。