苟新节

主题

 

阿里云安全组和服务器防火墙，到底有什么区别？ ​

更新: 6/23/2026字数: 0 字 时长: 0 分钟

很多人第一次把项目部署到阿里云 ECS 时，都会遇到一个非常典型的问题：

服务器里 curl 127.0.0.1:82 能通，nginx 也正常，容器也启动了，但浏览器访问 http://公网IP:82 就是打不开。

这时候，大概率不是代码有问题，而是你卡在了两个“门”上：

  1. 阿里云安全组
  2. 服务器防火墙

它们名字听起来都像“防火墙”，所以很容易混淆。实际上，这两个东西不在同一层，职责也不同。理解它们之后，服务器网络问题会清晰很多。

一句话先讲明白 ​

阿里云安全组，是云平台层面的第一道门。

服务器防火墙，是操作系统层面的第二道门。

外部请求想访问你的服务，通常要先过阿里云安全组，再过服务器防火墙，最后才能到你的 nginx、Docker 容器或者应用进程。

也就是说：

只开安全组不行，只开服务器防火墙也不行。

两边都放行，外部访问才真正能通。

可以把它理解成两道门禁 ​

假设你的服务器是一栋楼。

  • 阿里云安全组，是小区大门
  • 服务器防火墙，是你家门口的防盗门
  • nginx、Docker、应用服务，是屋里的具体房间

一个访客从外面来找你，流程是这样的：

互联网 -> 阿里云安全组 -> ECS 网卡 -> 服务器防火墙 -> Nginx / Docker / 应用

任何一层没放行，请求都会失败。

阿里云安全组是什么 ​

阿里云安全组，是 ECS 实例外围的网络访问控制规则。你可以理解成云服务器的“云端门禁”。

它控制的是：

  • 哪些端口允许外部访问
  • 哪些来源 IP 可以访问
  • 哪些协议可以通过，比如 TCP、UDP
  • 出方向和入方向是否允许通信

比如你的网站跑在 82 端口，如果阿里云安全组没有开放 82/tcp，那外部请求根本到不了你的服务器系统。

这时候你在服务器里执行：

bash
curl http://127.0.0.1:82

可能是通的。

但你在自己电脑浏览器里访问：

bash
http://47.101.33.206:82

却不通。

原因就是：请求还没到服务器，就已经被阿里云安全组拦住了。

服务器防火墙是什么 ​

服务器防火墙，是 ECS 操作系统内部的网络控制机制。

常见的有：

  • firewalld
  • iptables
  • nftables

在 CentOS、Alibaba Cloud Linux、RHEL 这类系统里，很多时候你会接触到的是 firewalld。

它控制的是：

  • 服务器本机允许哪些端口被访问
  • 哪些服务可以对外监听
  • 哪些来源可以进入系统

如果阿里云安全组已经开放了 82 端口，但系统防火墙没开放，那么请求虽然已经到达 ECS 机器，但会被系统内部挡住。

这种情况下，你可能会看到：

  • 安全组配置没问题
  • nginx 在监听 82
  • 但浏览器还是连不上

这就说明，请求到了云服务器边缘，但没穿过系统这层门。

两者最核心的区别 ​

最简单的区别如下：

1. 所在位置不同 ​

  • 阿里云安全组：云平台层
  • 服务器防火墙：操作系统层

2. 生效范围不同 ​

  • 阿里云安全组：控制 ECS 实例对外的网络访问
  • 服务器防火墙：控制这台 Linux 系统自身的网络访问

3. 排错位置不同 ​

  • 安全组没开：请求根本到不了服务器
  • 防火墙没开：请求到了服务器，但进不了系统服务

4. 配置方式不同 ​

  • 安全组：在阿里云控制台配置
  • 防火墙：在服务器终端执行命令配置

为什么很多人会误判问题 ​

因为部署成功后，最容易做的测试是本机测试。

比如：

bash
curl http://127.0.0.1:82

如果返回了 HTML，大家就会觉得“服务没问题”。

这个判断只对了一半。

它只能证明：

  • nginx 在工作
  • 应用在工作
  • 服务器本机回环访问没问题

它不能证明：

  • 公网是否能访问
  • 安全组是否放行
  • 防火墙是否放行

所以“本机 curl 通了”不等于“公网能访问”。

一个最常见的部署场景 ​

假设你把项目部署在阿里云 ECS 上，结构是这样的：

  • 宿主机 nginx 监听 82
  • 宿主机 nginx 反向代理到 127.0.0.1:8001
  • Docker 里的 web 容器映射到宿主机 8001
  • 前端再通过 /api/v1 访问后端

这时公网访问路径是：

浏览器 -> 公网IP:82 -> 阿里云安全组 -> 服务器防火墙 -> 宿主机 Nginx:82 -> 127.0.0.1:8001 -> Docker web 容器

这里任何一个环节错了，网站都打不开。

怎么判断问题出在哪一层 ​

我建议按下面顺序查。

第一步：看服务是不是已经监听端口 ​

先确认 nginx 或你的应用是否真的在监听：

bash
ss -lntp | grep :82

如果能看到类似：

bash
LISTEN 0 511 0.0.0.0:82

说明宿主机上确实有进程在监听 82 端口。

如果这里没有监听，先别看安全组和防火墙，先修服务本身。

第二步：看服务器本机能不能访问 ​

执行：

bash
curl http://127.0.0.1:82

如果返回页面 HTML，说明本机访问没问题。

如果这里都不通，那问题在：

  • nginx 配置
  • Docker 端口映射
  • 容器没启动
  • 应用没启动

这时还不需要查安全组。

第三步：看服务器防火墙有没有开放端口 ​

如果你用的是 firewalld，先看已开放端口：

bash
firewall-cmd --list-ports

如果没有 82/tcp，那就需要开放：

bash
firewall-cmd --permanent --add-port=82/tcp
firewall-cmd --reload
firewall-cmd --list-ports

看到结果里有：

bash
82/tcp

才算系统层放通了。

如果你的系统没启用 firewalld，也可能需要检查 iptables 或 nftables 规则。

第四步：看阿里云安全组有没有开放端口 ​

登录阿里云控制台，找到这台 ECS 对应的安全组。

检查入方向规则里是否有：

  • 协议类型：TCP
  • 端口范围：82/82
  • 授权对象：0.0.0.0/0

如果没有，就新增一条。

这一步非常关键。很多人服务器里全通了，但控制台安全组没放行，结果公网就是不通。

第五步：从外部机器访问 ​

最后，用你自己的电脑浏览器打开：

bash
http://你的公网IP:82

或者用本地命令：

bash
curl http://你的公网IP:82

如果这里能通，说明整条链路已经打通。

一个很重要的结论 ​

外网访问问题，必须分层排查。

不要一上来就改代码，也不要一上来就怀疑 Docker。

先确认：

  1. 服务有没有监听
  2. 本机能不能访问
  3. 防火墙有没有放行
  4. 安全组有没有放行
  5. 外部机器能不能连通

按这个顺序查，效率最高。

安全组和防火墙能不能只留一个 ​

理论上，某些场景下你可以让系统防火墙关闭，只依赖阿里云安全组。

也可以让安全组放得比较宽，再依赖系统防火墙细控。

但对于大多数个人开发者和中小项目来说，我更建议：

两边都保留，并且规则明确。

原因很简单：

  • 安全组负责云侧入口控制
  • 防火墙负责系统内部第二层保护
  • 双层控制更稳，排障也更清晰

当然，规则不要乱配。最怕的是两边都配了，但自己都不知道放了什么、挡了什么。

实际部署时应该怎么配 ​

如果你只是部署一个普通 Web 项目，常见做法是这样：

阿里云安全组开放 ​

  • 22/tcp：SSH 登录
  • 80/tcp：HTTP
  • 443/tcp：HTTPS
  • 82/tcp：你当前项目临时使用的访问端口

服务器防火墙开放 ​

  • 22/tcp
  • 80/tcp
  • 443/tcp
  • 82/tcp

不建议开放的端口 ​

除非你明确知道自己在做什么，否则不要把这些内部端口直接暴露公网：

  • 3301 后端 API 端口
  • 6379 Redis 端口
  • 数据库端口，比如 5432、3306

这些端口更适合只在内网或 Docker 网络里通信，不应该直接给公网访问。

Docker 场景下为什么更容易绕晕 ​

因为 Docker 又引入了一层端口映射。

例如：

bash
127.0.0.1:8001 -> 容器 80

这意味着：

  • 容器内服务监听的是 80
  • 宿主机暴露的是 8001
  • 外网访问不一定直接访问 8001
  • 你可能还会再通过宿主机 nginx:82 转发到 8001

这时候你会同时看到：

  • 容器端口
  • 宿主机端口
  • Nginx 监听端口
  • 公网开放端口

如果脑子里没有“分层”概念，很容易把它们混成一团。

正确理解应该是：

  • 容器端口，是容器内部服务端口
  • 宿主机端口，是 Docker 映射出来给宿主机用的
  • Nginx 监听端口，是外部真正访问的入口
  • 安全组和防火墙，控制的是外部请求能不能走到这个入口

我个人推荐的排障方法 ​

以后遇到“浏览器打不开”的情况，直接按这 6 条查：

  1. docker compose ps 看容器是不是正常启动
  2. ss -lntp 看宿主机端口有没有监听
  3. curl 127.0.0.1:端口 看本机是否能通
  4. nginx -t 看反向代理配置是否正确
  5. firewall-cmd --list-ports 看系统防火墙是否放行
  6. 去阿里云控制台看安全组是否放行

只要这 6 步按顺序做，绝大多数网络访问问题都能定位出来。

新手最容易踩的几个坑 ​

1. 以为容器启动了，公网就一定能访问 ​

不对。容器启动只能说明应用活着，不代表外网链路通了。

2. 以为 curl 127.0.0.1 通了就万事大吉 ​

不对。这只能证明本机回环通，不代表公网通。

3. 只改安全组，不改服务器防火墙 ​

不够。系统层还可能挡住。

4. 只改服务器防火墙，不改安全组 ​

也不够。云平台层可能直接拦截。

5. 把 Redis、数据库直接暴露到公网 ​

很危险。内部依赖尽量只在内网使用，不要图省事直接对外开放。

最后总结 ​

阿里云安全组和服务器防火墙，不是二选一，而是两层不同位置的访问控制。

你可以把它记成一句话：

安全组管“能不能到服务器”，防火墙管“到了服务器能不能进系统服务”。

所以当你的网站打不开时，不要只盯着代码和 Docker，先把整条访问链路想清楚：

公网 -> 安全组 -> 服务器防火墙 -> Nginx -> Docker -> 应用

只要你学会按层排查，部署问题会简单很多。

我见青山多妩媚，料青山见我应如是

Copyright © 2026-present gouxinjie