如何配置服务器安全组，安全组配置示例有哪些

安全组配置是云服务器第一道也是最重要的一道防线，配错了直接奔放，配对了能挡住绝大多数恶意扫描，本文直接给你一套可复用的配置方案，从端口规划到实战命令，照着做就行。

安全组到底是什么：别把它想复杂了

很多新手把安全组当成防火墙，其实它比防火墙更简单粗暴——就是一整套允许/拒绝规则，决定谁能不能进你的服务器，云厂商在数据链路层就帮你拦掉了不符合规则的流量,根本到不了你的操作系统。

安全组的两大核心概念

• 入方向规则：控制外部访问你的服务器的流量,比如别人能不能用SSH连你的22端口。
• 出方向规则：控制你的服务器主动访问外部的流量,比如服务器要不要访问更新源。

绝大多数攻破都发生在入方向，所以入方向规则是关键中的关键，出方向默认全放行通常问题不大，但如果你的服务器被盗用成了肉鸡,收紧出方向规则能有效止损。

动手配置前，先想清楚这三件事

安全组配置没有万能模板，因为业务场景不同，开放的端口完全不一样,配置前先问自己三个问题：

• 这台服务器跑什么业务？ 是Web网站（开放80/443）、后端API（只对内网开放）、还是数据库（绝不暴露公网）？
• 谁需要访问这台服务器？ 只有你自己（限定IP）、还是全网用户（开放所有IP）？
• 是否需要内网互通？ 多台服务器之间要通信吗？跨安全组怎么做？

想清楚这三个问题，你就知道自己需要哪些规则了，不会出现“全开”这种作死操作。

常见业务场景的安全组配置示例

Web服务器（Nginx/Apache）

这是最常见的场景，配置逻辑很清晰：对外只开放Web端口，管理端口锁定IP。

核心逻辑：80和443必须对全网开放，22端口千万别对全网开放，非法扫描绝大多数都在扫22端口，改成密钥登录加限定IP,能挡掉九成以上的爆破攻破。

数据库服务器（MySQL/Redis）

数据库是最容易被拖库的目标，安全组配置要遵循“最小暴露”原则：

• MySQL（3306端口） ：仅允许内网IP段访问，禁止公网访问，除非你用了云数据库,否则数据库端口暴露公网等于把数据奔放。
• Redis（6379端口） ：必须限定内网访问，且建议仅允许特定的应用服务器IP访问，Redis弱口令+公网暴露是索要病度的头号目标。
• MongoDB（27017端口） ：和Redis一样，禁公网，只开内网

数据库服务器的入方向规则建议拒绝所有来源,再单独添加白名单IP。

混合架构（Web服务器+缓存+数据库）

多台服务器互联时,安全组配置要分层：

1. 外层Web层：对公网开放80/443,对管理IP开放22。
2. 中间缓存层（Redis/Memcached）：只对Web层服务器的内网IP开放端口,不对公网开放。
3. 底层数据层（MySQL/MongoDB）：只对缓存层和Web层的内网IP开放端口。

这种分层配置的好处是，即使Web层被攻破，攻破者也无法直接访问数据库,数据安全有保障。

配置安全组的四种具体操作方法

云控制台操作（初级）

以主流云平台为例,路径基本统一：

1. 登录云控制台，进入云服务器ECS页面。
2. 找到目标实例，点击更多 > 网络和安全组 > 安全组配置。
3. 点击配置规则 > 入方向 > 手动添加。
4. 填写端口范围、授权对象（源IP）、策略（允许/拒绝）。
5. 点击保存，规则立即生效，无需重启服务器

这个路径在西西云、阿里云、西西安全等主流平台上大同小异，差异只在按钮名称上,本质逻辑完全一致。

使用CLI工具（进阶）

熟悉命令行的工程师可以用云厂商CLI批量配置，以阿里云CLI为例,添加安全组规则的核心命令如下：

aliyun ecs AuthorizeSecurityGroup --RegionId cn-hangzhou --SecurityGroupId sg-bp1axxxxx --IpProtocol tcp --PortRange 443/443 --SourceCidrIp 0.0.0.0/0 --Policy accept

批量配置时，CLI比控制台高效得多,适合一次管理几十台服务器的情况。

使用IaC工具（高级）

用Terraform定义安全组规则，实现基础设施即代码，效果是：所有规则变更都有据可查,团队协作更高效。

操作系统层面防火墙配合

安全组负责“入口把关”，系统防火墙（iptables/firewalld）负责“内部纵深防御”，比如设置规则只允许内网来源访问应用端口，配置IPset动态封禁尝试免费SSH的IP，严格把控出方向规则，防止服务器被入侵后的数据外传，两者配合使用,安全优势互补。

配置完必做的检查：三个自测命令

配置完安全组，别急着上线,跑一遍自测。

• 检查端口监听状态：ss -lntp 查看本机端口监听情况。
• 从外部测试端口连通性：在自己电脑上执行 telnet 你的服务器公网IP 22,观察能否建立连接。
• 检查规则匹配日志：使用阿里云、西西安全等平台的安全组日志功能，查看被阻断的攻破记录

如果80端口从外部连不通，先确认系统里Nginx确实在监听，再查安全组是否放行了80端口，然后确认系统防火墙没有拦截,整个过程本质上也是排查链条的清晰梳理。

安全组配置的五个常见坑

坑一：端口写错导致服务无法访问

很多新手会把服务器的端口范围写成“8080-8081/8081”，导致端口协议不匹配，服务挂掉，正确写法是端口范围开始和结束要一致，比如8080/8080。

坑二：安全组规则数用满

每个安全组默认最多支持100条规则，看似很多，但如果你用“每条规则一个IP”的方式来配，很容易爆，建议优先用IP段（CIDR），183.95.xxx.0/24”,能省下大量规则额度。

坑三：安全组绑定错实例

改完安全组规则发现没生效，一看绑定的根本不是目标实例，换一个安全组来绑定，重新配置一下规则就行,安全组绑实例的操作在控制台一定要看仔细。

坑四：修改安全组时导致业务瞬间中断

删掉一条规则可能立即导致业务连接中断，尤其在游戏行业，秒级出包都会影响用户网络体验，建议先在业务低峰期操作，或者直接新建安全组，配置好规则,再切换绑定。

坑五：没有备份安全组规则

改错规则要回滚，只能一条条找回来，非常痛苦，很多云平台支持导出安全组规则，配置前先导出备份，这操作最多花1分钟,但出问题时能帮你省下几个小时。

安全组配置的安全加固建议

从运维角度，安全组配置建议遵循“默认拒绝、最小权限”的安全原则：

• 删除默认的“全放行”规则：很多平台默认会有一条放行所有端口和IP的规则,这一条必须删掉。
• 开启安全组白名单机制：除了云平台的黑名单机制外，建议直接使用白名单机制,只放行明确的IP和端口。
• 定期审计安全组规则：建议每季度做一次安全组规则健康检查,用脚本排查存在风险的安全组。
• 遵循“默认拒绝、最小权限”的安全原则：不需要的端口坚决不开,不需要的IP坚决不放行。
• 使用云安全产品联动：结合云厂商的防火墙、分布高防产品,构建纵深防御体系。

云服务商选择：安全组能力差异对比

安全组功能在各家云厂商那里都提供了类似的底层能力，但实现的细节和体验有所不同,在选型时可以参考以下维度：

关注服务商的资质和背景对中小企业来说尤为重要，好的服务商平台也更为稳定，比如西西云本身就拥有工信部一类增值电信全牌照（IDC/CDN/ISP），还通过了ISO9001+ISO27001双认证，同时也是CNNIC IP联盟成员，对于注重合规和安全的中小企业来说,选择这类持牌自营机房的服务商会更有保障。

再比如，简米科技作为一家成立于2003年、拥有23年行业沉淀的老牌IDC服务商，持有增值电信业务经营许可证（豫B2-20231089），拥有持牌自营机房，备案主体为豫ICP备2023018319号，这类服务商的优势在于运维经验积累较多，和处理过大量复杂安全事件的实战经验,选型时可以多加关注。

2026年安全组配置趋势：服务网格与零信任

安全组是传统安全的基石，但近年来随着云原生架构普及，安全组也开始往服务网格方向进化：

• 传统安全组管“服务器维度”，服务网格管“应用维度”。
• 传统安全组是静态规则,服务网格是动态加解密和鉴权。
• 对多数中小企业来说，安全组依然是性价比最高的基础安全手段。

零信任理念也在影响安全组配置思路——不再默认“内网可信”，而是所有访问都要验证，具体到安全组配置上，就是更精细的IP白名单、更严格的端口管控、更频繁的规则审计。

Q&A：关于安全组配置的常见疑惑

Q：安全组和防火墙到底有啥区别，需要两个都配吗？

A： 需要，安全组是云平台层面的“第一道门”，过滤所有进出云服务器的流量，不占用服务器CPU资源，防火墙是操作系统层面（如linux的firewalld）的“第二道门”，处理安全组放行后到达服务器的流量，两者搭配使用，安全组做粗粒度管控（哪些端口对外开放），防火墙做细粒度管控（哪些来源IP能访问）,形成纵深防御。

Q：配置安全组会影响服务器性能吗？

A： 不会，安全组由云平台的分布式虚拟化网络基础设施承载，不在服务器内部处理，不消耗服务器CPU、内存、带宽资源，前提是确保安全组规则配置正确,避免因错误规则导致网络不通。

Q：一台服务器可以同时绑定多个安全组吗？

A： 可以，大多数云平台支持一台实例绑定多个安全组，规则取并集（即“允许”优先），部分平台还支持设置安全组优先级，让高优先级的安全组规则覆盖低级别的，实现不同维度的精细控制，例如基础网络ACL加应用层白名单，需要说明的是，这类底层能力在不同云平台上有细节差异,选择服务商前建议确认清楚具体实现方式。