谷歌云试用账号 GCP谷歌云防火墙优先级规则
你有没有经历过这种抓狂时刻：
在GCP控制台里，吭哧吭哧配好一条防火墙规则——允许TCP 80端口，来源IP是0.0.0.0/0，目标标签是web-server；
然后兴冲冲curl一下自己的实例，结果……Connection refused；
再一看网络日志，连SYN包都没进来。
你挠头：我明明开了80啊！
别急，不是GCP抽风，也不是你的实例挂了——大概率，是你被防火墙优先级规则温柔又坚定地背刺了。
今天咱们不讲概念堆砌，不列枯燥参数表，就用炒豆子的节奏，把GCP防火墙的“优先级”掰开、揉碎、撒点盐，一口嚼明白。
一、先说人话：优先级不是“谁后配谁牛”，而是“谁数字小谁说了算”
GCP防火墙规则的优先级（Priority），是个1–65535之间的整数。注意：不是越大越优先，恰恰相反——数字越小，权限越大，越早执行。
想象你在公司门口站岗，手里拿一叠访客名单。名单按编号排好：001号最先放行，002号其次……65535号排在队伍尾巴，等前面全处理完才轮到它。
GCP防火墙就是这么个“门禁系统”。它收到一个数据包（比如来自1.2.3.4的TCP 80请求），会从优先级最小的那条规则开始逐条比对，一旦匹配上（无论allow还是deny），立刻执行动作，并停止继续往下查——后面所有规则，看都不看一眼。
所以问题来了：如果你配了一条优先级为1000的allow tcp:80，但上面还躺着一条优先级为500的deny all（比如默认自带的default-deny-ingress），那恭喜你，80端口永远收不到包——因为包还没走到你那条规则，就被500号直接“请回去了”。
二、GCP的两个“隐形BOSS”：隐式拒绝 & 默认规则
很多新手以为：“我没配deny规则，那就等于全放行？”错！GCP骨子里是个“保守派”：
- 所有入站流量，默认全部拒绝（implicit deny ingress）；
- 所有出站流量，默认全部允许（implicit allow egress）。
这个“默认拒绝”，不是某条可见规则，而是底层硬逻辑。你打开控制台看到的每一条规则，都是在跟这个隐形BOSS抢C位。
更扎心的是：GCP还会自动生成两条“基础守门员”规则：
default-allow-internal（优先级65534）：允许VPC内网互通（10.0.0.0/8等）；default-deny-ingress（优先级65535）：拒绝所有外部入站流量。
看到没？65535是最大值，意味着它站在队尾——但正因为它在最后，且动作是deny，就成了所有未被前面规则“接住”的流量的终极归宿。
所以，你写的那条allow 80如果优先级设成65530？不好意思，它排在default-deny-ingress前面，但若配置有误（比如target tags写错、方向选反、协议填成udp），照样被65535默默拒之门外。
三、四步诊断法：流量到底卡在哪？
遇到连不上，别急着重启实例，先按顺序问自己四个问题：
- 这条流量，匹配到了哪条规则？（打开VPC网络→防火墙→点击对应规则→看“匹配详情”里的命中次数）
- 这条规则的优先级，在所有相关规则里排第几？（把当前项目下所有ingress规则按Priority升序排列，看看它前面有没有更狠的deny）
- 谷歌云试用账号 规则的target是否真覆盖了你的实例？（检查实例是否有对应network tag；或是否属于指定的服务账户/实例名称；别写成
webserver而实例tag是web-server） - 源IP和协议是否完全吻合？（0.0.0.0/0 ≠ “所有IP”，它不包括Google健康检查IP段；ICMP ping走的是ICMP协议，不是TCP 22）
实测案例：某客户死活ssh不上，查日志发现SYN都进不来。最后发现——他配了allow tcp:22，但优先级设成了1000；而另一条同事半年前配的deny tcp:22 from 203.0.113.0/24，优先级是500。203段IP虽不在他测试范围内，但规则本身已生效，且因优先级更高，直接截停了所有22端口流量（没错，GCP的deny规则不校验source IP范围是否匹配，只要端口对就拦）。
四、实战黄金法则：三条保命建议
① 优先级别贪大，建议从1000起步，留足空间
别一上来就写Priority=1（除非你真要压倒一切）。推荐区间：1000–4000。这样以后加紧急规则（如临时开放调试端口），还能插在中间（比如1500），不用动原有结构。
② 永远显式deny，别依赖隐式拒绝
想封某个IP段？别指望“我不配它就进不来”。明确写一条deny all from 192.168.100.0/24，优先级设得比你的allow规则高（比如900），并加注释：“防灰产扫描，2025-Q3到期”。显式即可靠，也方便审计。
③ 测试时，用gcloud命令代替控制台“点点点”
控制台UI容易漏看优先级字段。直接敲：gcloud compute firewall-rules list --sort-by=priority --filter="direction=INGRESS"
输出一目了然，谁在前谁在后，清清楚楚。
五、最后送你一句GCP老司机箴言
“防火墙不是开关，是流水线；
你写的不是‘放行’，是‘拦截前的最后通牒’；
优先级不是编号，是判决书上的签发顺序。”
下次再看到connection timeout，别先怀疑实例，先打开防火墙列表，按Priority从小到大扫一眼——那个静静躺在你规则上方的deny条目，可能正端着茶杯，笑看你徒劳重试。
毕竟，在GCP的世界里，最沉默的规则，往往拥有最响亮的否决权。
