腾讯云多账号实名方案 腾讯云端口不通排查

凌晨两点十七分，我的手机震了第三下。

不是闹钟，不是外卖，是老板发来的截图——一张红色加粗的「连接超时」报错，外加一句朴实无华的问候：“服务器挂了？”

我揉了揉眼睛，顺手把凉透的美式倒进水槽，打开电脑。心里默念三遍：不生气，不骂人，这届端口它只是想静静。

一、开局即迷惑：能 ping 通，但死活 telnet 不上

目标是一台部署在腾讯云广州区的 CentOS 7 虚拟机，对外提供 HTTP 服务（80 端口）。运维同学反馈：“浏览器打不开，curl 报 Connection refused，但 ping 得通。”

我立刻本地开终端：

ping -c 3 119.29.29.99
→ 3 packets transmitted, 3 received, 0% packet loss

好家伙，网络层稳如老狗。

telnet 119.29.29.99 80
→ Trying 119.29.29.99...
→ telnet: connect to address 119.29.29.99: Connection refused

哦豁——这不是网络不通，这是端口在装死。

二、第一关：安全组？它比你妈还操心

腾讯云控制台点开，直奔「安全组」。我们配的是「允许所有内网 + 仅开放 22/80/443」——看起来很干净。

但等等……我放大再看一遍入站规则：

• 类型：HTTP，端口：80，来源：0.0.0.0/0 ✅
• 类型：HTTPS，端口：443，来源：0.0.0.0/0 ✅
• 类型：SSH，端口：22，来源：指定 IP ✅

逻辑没问题？不，问题就藏在那个「HTTP」类型里。

腾讯云的安全组规则里，「HTTP」类型默认只放行 TCP 协议，而我们的 Nginx 实际监听在 TCP 上——按理说没问题。但！有个隐藏设定：如果你手动填了端口范围（比如 80-80），又误选了「全部协议」，规则可能被悄悄覆盖或冲突。

我翻出历史操作日志，发现三天前同事调整过规则，新增了一条「自定义 TCP：8080-8080，来源 10.0.0.0/8」，结果误点了「全部协议」——而安全组规则是按顺序匹配、第一条生效。这条新规则没拦住 80，但它后面那条「拒绝全部」的兜底规则，竟阴差阳错卡住了部分流量路径（别问，问就是腾讯云控制台 UI 的玄学渲染逻辑）。

教训：安全组不是越写越安心，是越改越心慌。每次增删，务必点击「规则排序」按钮，确认关键放行规则排在最前面。

三、第二关：网络 ACL？云上隐形墙

安全组搞定了，还是连不上。我突然想起——这台机器绑了子网，而子网关联了「网络 ACL」。

网络 ACL 是子网级别的有状态防火墙，和安全组不同，它默认拒绝所有入站和出站。我们团队习惯性给所有子网配一条「允许全部」规则，但这次……忘了配。

打开子网详情 → 网络 ACL → 入站规则列表：

空的。

没错，就两行字：「无规则」。相当于在门口焊了扇铁门，还挂了把 padlock。

赶紧补上两条基础规则：

• 入站：TCP，端口 22/80/443，源 0.0.0.0/0，允许
• 出站：ALL，目标 0.0.0.0/0，允许

保存，再 telnet——依然 Connection refused。

……所以，它根本不是网络层的问题。是更近的地方，在作妖。

四、第三关：系统防火墙？CentOS 的倔强

登录服务器（终于用 22 端口进去了），第一反应：systemctl status firewalld。

输出：active (running)。

腾讯云多账号实名方案 我默默输入：firewall-cmd --list-all，然后看到了这辈子不想再看见的三行：

ports: 22/tcp
services: ssh
interfaces: eth0

翻译成人话：除了 SSH，别的端口一律不认。Nginx 的 80？在防火墙眼里，约等于不存在。

快速放行：

firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload

再 telnet——还是 refused。

我盯着终端，深吸一口气，打开了 Nginx 错误日志：/var/log/nginx/error.log。

日志里干干净净，连一行 warn 都没有。

不对劲。

五、第四关：SELinux？那个从不说话但总在捣乱的室友

查进程：ps aux | grep nginx —— 进程在跑。

查监听：ss -tlnp | grep :80 —— 没输出。

我愣了三秒，重打一遍命令，加了 sudo：sudo ss -tlnp | grep :80。

出来了：

LISTEN 0 128 *:80 *:* users:(("nginx",pid=1234,fd=6))

等等——*？不是 0.0.0.0，是星号？

查 Nginx 配置：grep -r "listen" /etc/nginx/，发现 default.conf 里写着：

listen 80;

没写 IP，没写 bind，就是裸 listen 80。

在 CentOS 7 + SELinux 启用环境下，Nginx 默认不允许监听所有接口，除非显式授权。SELinux 的布尔值 httpd_can_network_bind 默认是 off。

执行：

setsebool -P httpd_can_network_bind 1

重启 Nginx：systemctl restart nginx。

再跑 ss -tlnp | grep :80：

LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=5678,fd=6))

成了。

本地 curl 测试：curl http://119.29.29.99 —— 返回了熟悉的 HTML。

我瘫在椅子上，感觉人生被掏空，又莫名充实。

六、终极自查清单（可打印贴工位）

• ✅ ping 通？→ 网络层 OK
• 腾讯云多账号实名方案 ✅ telnet 端口失败？→ 定位到传输层及以上
• ✅ 腾讯云安全组：检查规则顺序、协议类型、端口范围、是否启用
• ✅ 网络 ACL：子网是否绑定 ACL？入/出站是否有放行规则？
• ✅ 实例系统防火墙（firewalld/iptables）：是否允许该端口？是否 reload？
• ✅ 应用是否真正监听？ss -tlnp 或 netstat -tlnp 看绑定地址（0.0.0.0 ≠ 127.0.0.1）
• ✅ SELinux（CentOS/RHEL）：getenforce 查状态，sestatus 查详情，setsebool -P httpd_can_network_bind 1 放行
• ✅ 应用配置：Nginx/Apache 是否监听了正确 IP？Docker 是否加了 -p 映射？

七、附赠：端口排查防暴走口诀

一 ping 二 telnet，三看安全组四 ACL；
五查防火墙六监听，七撸 SELinux 八喝咖啡；
九翻日志十重启，十一发现是同事改了 hosts……

最后，友情提示：下次再遇到「端口不通」，别急着怀疑人生。先泡杯茶，再打开 checklist——因为绝大多数时候，不是云不行，是你还没把它「驯服」。

毕竟，云计算的本质，是把物理世界的复杂性，打包成一道道选择题。而我们，是那个一边选 C 一边祈祷答案别是 D 的考生。

（完）