华为云安全组排查实录：服务在跑但公网访问不通时的排查顺序

背景：最让人着急的一种故障

云服务器上最常见、也最让人着急的一类故障是这样的：登录服务器一看，服务进程在跑、端口也在监听，从服务器本机用 curl 访问 127.0.0.1 也能返回页面，可换到自己的电脑上用公网 IP 一访问，就是连接超时或者拒绝连接。
这种“本机通、公网不通”的现象，问题往往不在应用本身，而在从公网到服务器的链路上某一环被拦住了。华为云上的链路大致是：客户端 → 公网 IP → 弹性云服务器 ECS 绑定的安全组 → 操作系统防火墙 → 应用监听端口。排查时按从内到外的顺序逐环验证，每确认一环就缩小一半范围，比来回改配置、重启服务要省事得多。本文把这套顺序整理成可直接照做的排查笔记。
需要先说明一点：下面写的是通用排查方法与控制台操作路径，不涉及任何一家业务的真实 IP、账号信息，示例端口也只是常见的 22、80、443，照做时请换成你自己的实际端口。

第一步：先确认服务真的在监听

很多“不通”其实是服务没起来，或者只监听了本地回环地址。先在服务器内做两件事。
第一，看进程与端口。登录服务器后用 ss -tlnp（或 netstat -tlnp）查看监听状态，重点看两列：一是本地地址，二是端口。如果看到的是 127.0.0.1:8080，说明服务只绑了回环地址，公网流量根本到不了它，需要把应用的监听地址改成 0.0.0.0 再重启；如果看到 0.0.0.0:8080 或者 :::8080，说明监听面没有问题。
第二，在本机做一次回环访问。比如服务是 Web 应用，就在服务器上执行 curl -I http://127.0.0.1:8080，能拿到 HTTP 响应头就说明应用层是好的。这一步通过之后，就可以排除应用本身，把注意力放到网络链路上；这一步不通过，就先修应用配置，不要急着去改安全组。

第二步：查安全组，这是最高频的原因

如果本机访问正常、公网访问不通，第一个要查的就是安全组。华为云安全组是有状态的，默认规则下入方向只放行有限的流量，新建服务器后如果没有给业务端口加规则，公网访问会被直接丢弃，表现就是连接超时。
排查路径是：华为云控制台 → 弹性云服务器 ECS → 找到目标实例 → 点进详情看它绑定了哪一个（或哪几个）安全组 → 进入对应安全组看入方向规则。逐条核对四个要素，缺一个都可能不通：

1. 方向必须是入方向。出方向放行解决不了外部访问你的问题，很多人误把规则加到了出方向。
2. 协议与端口要对上。Web 服务一般是 TCP 80 或 443，SSH 是 TCP 22，自定义应用是多少就填多少，不要只填一个大概的范围，也不要把 UDP 和 TCP 搞混。
3. 源地址不能写错。测试阶段可以先用 0.0.0.0/0 验证通路，确认通了之后再收紧到自己的办公 IP 或跳板机 IP，长期对全网放行 22 端口是不推荐的做法。
4. 规则要加在实例实际绑定的安全组上。一台 ECS 可以绑定多个安全组，但也可能绑定了你以为的另一个安全组。改规则之前先在实例详情页确认名字，不要凭印象改。
   改完规则不需要重启实例，安全组规则一般是即时生效的，改完立刻从公网再测一次。如果这时通了，问题就定位了，记得把测试用的宽松源地址收紧回去。

第三步：查操作系统层面的防火墙

安全组放行之后如果还是不通，下一环是服务器自身的操作系统防火墙。云上安全组和系统防火墙是两道独立的门，任何一道没开都不通，很多人只开了一道就以为完事了。
不同系统的查看方法不同：CentOS / EulerOS 一类常用 firewall-cmd --list-all 看当前放行的服务与端口，需要放行时用 firewall-cmd --add-port=8080/tcp --permanent 再 --reload；Ubuntu 一类常用 ufw status，放行用 ufw allow 8080/tcp。如果是用 iptables 直接写规则的系统，就用 iptables -L -n 核对 INPUT 链。
这一步有个实用的区分技巧：如果从服务器本机 curl 回环地址能通，但从同一 VPC 内的另一台服务器用内网 IP 访问不通，问题大概率在系统防火墙或监听地址上；如果内网能通、只有公网不通，问题大概率在安全组或公网 IP 绑定上。内外对照一下，定位会快很多。

第四步：查公网 IP 与端口映射有没有绑对

再往外一环，是公网访问的入口本身。确认三点：第一，实例是否绑定了弹性公网 IP（EIP），没有绑定 EIP 的实例本来就没有公网入口；第二，访问时用的 IP 是不是当前绑定的那一个，实例重建、EIP 解绑重绑之后 IP 是会变的，浏览器书签里存的老 IP 可能早已失效；第三，如果前面套了负载均衡或者 NAT 之类，监听器与后端服务器组的端口映射有没有对上，后端端口填错同样会表现为不通。
这一环容易被忽略，是因为大家默认“IP 肯定没错”。实际上排查时花十秒钟在控制台核对一次实例详情页的 EIP，比反复重启服务划算得多。

第五步：用分段测试锁定最后一段

如果以上都确认无误还是不通，就用分段测试代替猜测。常用的工具有 ping、telnet、curl -v 和 traceroute，但要注意它们的结论各不相同：

• ping 不通不一定代表服务不通，因为很多环境禁了 ICMP，ping 被丢弃是正常现象，不能单凭 ping 下结论。
• telnet 公网IP 端口能连上说明 TCP 通路是通的，问题在应用层；连不上且长时间无响应，多半是中间某一道防火墙把包丢了；立刻返回拒绝连接，则可能是端口根本没监听或者被显式拒绝。
• curl -v 能看到从 TCP 握手到 TLS 握手再到 HTTP 响应的每一步，卡在哪一步，问题就在哪一段。
  按“本机回环 → 同 VPC 内网 → 公网 IP + 端口”三段逐段测，哪一段开始不通，故障点就在这一段的入口规则上。这个方法虽然笨，但几乎不会误判。

注意事项：排查时最容易踩的几个坑

第一，改配置要一次只改一处。同时改安全组、系统防火墙和应用监听地址，通了也不知道是哪一处起的作用，下次复发还是不会修。一次改一处、测一次、记一次结果。
第二，不要把临时放行的宽松规则留在生产环境。测试用的 0.0.0.0/0 放行 22 端口、临时关掉系统防火墙，都是排查手段，不是最终状态。通了之后要第一时间收紧，并且把最终规则截图或记下来，方便下次对照。
第三，注意规则的生效与缓存。安全组规则一般即时生效，但浏览器、本地 DNS、客户端连接池都可能缓存旧结果，测不通时换一次无痕窗口、换一个网络环境再测，避免被缓存误导。
第四，变更前先记下原规则。动手改安全组之前，把现有规则简单记下来，万一改错了还能原样恢复。云服务器的网络配置改错一次，恢复成本往往比排查本身还高。

小结：一张可复用的排查顺序表

把全文浓缩成一张顺序表，下次遇到“服务在跑但公网不通”，按表从上往下走：

1. 服务器内 ss -tlnp 确认监听地址是 0.0.0.0 而不是 127.0.0.1，本机 curl 回环地址确认应用层正常。
2. 控制台确认实例绑定的安全组，入方向规则的协议、端口、源地址逐条核对，改完即时重测。
3. 系统防火墙（firewalld / ufw / iptables）确认同一端口已放行，内外对照区分是系统层还是云上层的问题。
4. 确认实例绑定的 EIP 就是你正在访问的那个 IP，前面有负载均衡或 NAT 时核对端口映射。
5. 用 telnet / curl -v 分段测试，定位到具体哪一段开始不通，再针对性修那一段的规则。
   这套顺序的核心就一句话：先内后外、逐段验证、一次只改一处。养成这个习惯之后，大多数“公网不通”都能在十几分钟内定位到具体是哪一道门没开，而不是在重启服务和反复改配置里打转。希望这篇笔记能帮你下次少走弯路。