谷歌云优惠券 GCP谷歌云端口不通排查

你有没有过这种体验？

凌晨两点，咖啡见底，屏幕右下角时间跳到02:17，你刚在GCP控制台点完“创建实例”，顺手记下公网IP，打开终端敲下：ssh -p 22 [email protected]……然后——

ssh: connect to host 34.123.89.45 port 22: Connection timed out

你揉了揉眼睛，又试了telnet 34.123.89.45 22，结果连光标都不闪一下。你翻出自己写的Terraform代码，确认firewall rule里写了ports = ["22"]；你查了实例详情页，网络标签对得上；你甚至把防火墙规则删了重建三次……最后瘫在椅子上，盯着GCP控制台那个绿色的“RUNNING”状态，感觉它像在冷笑。

别急，这不是玄学，是GCP的“端口不通”四重奏——它不响，但真有谱。

第一乐章：防火墙规则，不是写了就算数

GCP的防火墙规则，长得像规则，干的却是门禁保安的活——而且还是那种戴墨镜、查工牌、还要核对指纹+虹膜+今日暗号的狠角色。

你以为allow-ssh规则只要源IP是0.0.0.0/0、目标端口是22、目标是ssh-server标签就万事大吉？错。GCP防火墙分入站（Ingress）和出站（Egress），而SSH连不上，99%卡在入站——但你还得确认三件事：

1. 规则是否启用？ 控制台里那个小开关，灰着就是关着，哪怕它名字叫“allow-ssh-forever”。（别笑，真有人截图发群里问：“为什么我开了规则还是不通？”——开关是灰色的。）
2. 目标是实例，还是子网？ 规则里的“Target”选的是“Apply to instances with these network tags”，那你的实例必须带对应tag；若选“Apply to all instances in the network”，那就不用tag——但多数人图省事选前者，结果忘了给实例打标签。
3. 优先级有没有被更高优规则挡了？ GCP防火墙按优先级数字升序匹配，100比65535优先。如果你有一条优先级为100的deny-all规则，且没写源IP限制，它会默默吃掉所有流量——包括你那条65535的SSH放行规则。

💡 速查口诀：一开二标三优先，标签不对等于没配。

第二乐章：实例自己“装死”——网络标签不是装饰品

很多人以为网络标签（Network Tags）只是个分类标签，类似微信备注。错了。它是GCP防火墙的“钥匙孔”——没有这把钥匙，再宽的门也不给你开。

举个栗子：你建了条规则：
Target: apply to instances with network tag 'web-server'
结果你实例只打了http-server这个tag……恭喜，SSH请求连防火墙大门都没摸到，直接被丢弃。

更隐蔽的坑是：实例启动后才生效的标签，不会自动同步到正在运行的防火墙规则里。也就是说，你先启实例，再补标签，规则不会立刻认账——得重启实例，或手动触发网络接口重载（不推荐）。稳妥做法：创建实例时一步到位打上tag。

验证方法？进实例详情页 → “网络接口” → 展开看“网络标签”字段。空？赶紧补。有？再核对拼写——webservers ≠ web-server，GCP可不搞模糊匹配。

第三乐章：公网IP，分“临时”和“保留”，别让IP悄悄溜走

你拿到的那个34.123.89.45，看着像身份证号，其实可能是张“临时暂住证”。GCP默认分配的是临时外部IP——只要实例停止（stop），IP立刻回收，下次启动换新号。

所以你昨天能连，今天连不上？先去控制台看实例状态是不是“STOPPED”过。如果是，IP早换了。你还在连旧地址，当然超时。

解决？两种方案：
✅ 正确姿势：创建实例时勾选“分配静态外部IP”；
❌ 土法炼钢：实例停了再启，祈祷IP没被别人抢走（概率≈中彩票）。

补充冷知识：静态IP也分“区域级”和“全球级”。SSH用区域级就够了，全球级是给HTTP(S)负载均衡准备的——别乱选，贵。

第四乐章：SSH本身，也在偷偷搞事情

你以为端口通了就一定能SSH登录？天真。GCP默认SSH服务监听的是0.0.0.0:22，但有些镜像（比如自定义CentOS）可能：
• 关了sshd服务（systemctl status sshd一看吓一跳）；
• 改了端口（/etc/ssh/sshd_config里Port 2222）；
• 禁了密码登录，又没配密钥（连上去直接Permission denied (publickey)）；
• 甚至…防火墙在系统内又拦了一道（iptables -L扫一眼，发现INPUT链DROP了所有非22端口）。

这时候，别急着砸键盘。GCP提供串行控制台（Serial Console）——相当于给虚拟机装了个物理显示器和键盘。进实例详情页 → “远程访问” → “连接到串行控制台”，输入用户名密码（或密钥），就能直连系统内部。这是最后的救命稻草，比重装系统快十倍。

Bonus章节：那些让你怀疑人生的“高级陷阱”

• 健康检查干扰：如果你把实例加进了实例组，并启用了HTTP健康检查，GCP会定期探测/healthz。某些应用（比如Nginx）若未配置该路径，会返回404，导致实例被标记为“不健康”并从负载均衡摘除——但这不影响SSH！不过新手常误以为“不健康=连不上”，纯属心理暗示。
• 谷歌云优惠券 VPC Service Controls：企业账号可能启用了这个安全围栏。它会在VPC边界拦截流量，哪怕防火墙全开，也会静默丢包。查控制台“Security” → “VPC Service Controls”，看是否有策略覆盖了你的项目。
• Cloud NAT配置错误：如果实例只有内网IP，靠Cloud NAT出公网，那NAT规则没配好，会导致出向DNS查询失败，进而影响apt/yum更新——看起来像“系统坏了”，实则是连不上源站。

终极排障流水线（抄下来贴工位）

1. 确认实例状态是Running（不是Stopped/Provisioning）；
2. 确认实例有外部IP，且是静态（或至少没被回收）；
3. 确认实例绑了正确的网络标签；
4. 确认防火墙规则启用中、方向为Ingress、源IP合理、目标端口正确、优先级未被更高规则覆盖；
5. 用串行控制台登录，检查sshd是否运行、端口是否监听（sudo ss -tlnp | grep :22）；
6. 检查实例内部防火墙（iptables或ufw）；
7. 如仍不通，开一个最小化测试规则：Source: 0.0.0.0/0, Target: All, Port: 22, Priority: 100，排除规则逻辑问题。

最后送一句掏心窝子的话：GCP的端口不通，从来不是“没配”，而是“配得不够细”。它不像本地VM那样一气呵成，而像组装瑞士手表——少一颗螺丝，整块表停摆。但一旦理清逻辑，你会觉得：哦，原来它严谨得有点可爱。

下次再看到Connection timed out，别叹气。泡杯茶，打开控制台，按上面七步走一遍——大概率，五分钟后你就笑着敲进去了。

毕竟，运维的浪漫，就是把不可控的混沌，亲手拧成确定的回车键。