买一台云服务器，开机、装环境、跑起来，前后不到半小时，看着一切顺利。结果第二天域名一解析过来，页面直接转圈打不开；或者更尴尬的情况，网站好好地跑着，浏览器打开却是一个默认欢迎页。回头一查控制台，安全组里只留了一条默认的 SSH 规则，80 和 443 端口压根没放行。服务器安全组这东西，就是卡在新手和「刚入门运维」之间的一道门槛，它不难，但它跟你之前理解的「装个软件」完全不是一回事。
需要一台配置够用、规则又比较开放的云服务器来练手的朋友，这两家可以重点看看：狗云DOGYUN（高性价比云服务器，多机房可选）、Zenlayer（全球多地区节点，海外业务首选），开机器之后第一件事就是先把安全组规则理顺，别等站点上线了再回头救火。
一、安全组到底是什么，它挡在谁的前面
先把这个概念说清楚，后面所有操作都好理解。安全组可以理解成挂在云服务器网卡最外层的一道虚拟防火墙。数据包从互联网出来，要先经过云厂商的清洗设备，然后进入安全组，安全组逐条比对规则，匹配得上就放行，匹配不上直接丢弃，连到服务器内部的机会都没有。
所以你配的规则，本质上是在回答一个问题：谁，在什么条件下，可以访问这台机器的哪个端口。三个要素缺一不可协议、端口、来源。规则写不全，表现为「连不上」；规则写太宽，表现为「什么都能连」，是安全隐患。
还有一点特别关键：安全组默认拒绝。也就是说没有被任何规则明确放行的流量，一律丢弃。这跟很多人在自己电脑上装的防火墙软件思路是反的那些工具是「默认全放，你手动拉黑」，而云安全组是「默认全拦，你手动开洞」。理解了这一点，你就知道为什么新机器必须主动加规则才能访问。
二、入站和出站：别把两个方向搞混
安全组规则分两个方向，作用完全不同。
入站规则（Inbound）管的是「外面的人能不能进来」。你的网站对外提供服务，80、443 这两个端口就得写在入站规则里；你自己用 SSH 连机器，22 端口也在入站。绝大多数人配置时出错，都是出在入站规则上。
出站规则（Outbound）管的是「机器能不能出去」。比如你的网站要访问外部的 API、要去拉取更新、要连接数据库服务器，这些都属于出站流量。很多云厂商的默认出站策略是「全部放行」，你不用管；但如果你做的是对安全性要求比较高的环境，会把出站也收紧成白名单，这时就得把数据库地址、镜像仓库、支付网关这些加进允许列表。
我自己的习惯是：入站规则一条一条精确配置，出站规则保持默认放行但加上流量监控和费用告警。理由是出站收紧带来的运维成本通常被低估了你每次装个新软件包可能就连不上了，出问题排查起来比入站还痛苦。
说个容易踩的坑：如果你在入站规则里放行了 80，但出站规则被收紧成只允许几个固定 IP，页面是能打开的，但页面里的图片、JS、CSS 全都加载不出来，浏览器控制台报一堆 mixed content 或者 connection timeout。这种现象非常有迷惑性，因为「页面能访问」很容易让人误判成网络问题。
三、协议和端口该怎么写
安全组规则的每一行，核心字段就这么几项：
协议。TCP、UDP、ICMP、ALL 几种。一般网站服务选 TCP，DNS 解析、QUIC 这类要选 UDP，做 Ping 测试要单独加一条 ICMP。
端口。这里最容易写错。写单个端口就是「22」，写一段就是「22-25」，写多个不连续端口用逗号分隔，比如「80,443,22」。写「80,443」和写「80-443」差别很大后者等于把 81 到 442 全部放开了，很多人图省事用范围，结果无意中开了一大片。
来源（Source）。最常见的来源写法有三种：0.0.0.0/0 表示任何人都能访问；你的办公 IP 比如 203.0.113.8/32 表示只有这个地址；0.0.0.0/0 但指定某个端口段，比如 0.0.0.0/0 只开 80、443。
安全组里这些源地址用的是CIDR 写法，不是子网掩码。常见的写法对照是：单个 IP 后面加 /32，一个 C 段是 /24，一个 B 段是 /16，整个互联网是 /0。你在别的云平台习惯看「子网掩码」的话，这里容易填错，填错了规则不生效或者范围比想象的大。
至于优先级，多数厂商是数字越小越优先，从高到低逐条匹配，命中即停。所以在默认拒绝的策略下，通常不需要靠优先级去覆盖什么，直接把允许的规则加上就够了；但如果你既有「允许全部」的兜底规则，又有「禁止某个 IP」的规则，那这条禁止规则必须排在前面，否则永远轮不到它生效。
四、一套可以直接抄的安全组规则
下面这套是我给普通网站用的基线配置，机器上跑 Nginx 加一个后端服务，你可以在此基础上调整：
入站规则第一条：TCP，端口 22，来源写你自己的固定 IP（家里宽带、公司出口、或者跳板机）。如果你没有固定 IP，那就先临时用 0.0.0.0/0 放开，用熟了再收紧这一步收紧之后，安全性提升非常明显。
第二条：TCP，端口 80，来源 0.0.0.0/0，理由是 HTTP 用于跳转 HTTPS 和证书验证。
第三条：TCP，端口 443，来源 0.0.0.0/0，这是网站真正的服务端口。
第四条：如果你的服务不是直接对外，比如只监听 127.0.0.1 或者内网地址，那对应的端口根本不用在安全组里开。原则就是只在有外部访问需求时开端口。
第五条是很多人会忘的：如果你用 Docker，容器映射出去的端口同样要走安全组。Docker 的 iptables 规则有时候会让这个问题变得很迷惑容器里服务明明起来了，宿主机的 8080 端口本机 curl 通，外部就是连不上。排查时记得先确认容器端口有没有在安全组里声明。
还有一条隐藏规则同样重要：服务器本机防火墙和云安全组是两套东西，需要一起考虑。云安全组管的是「从网络进来」，系统里的 firewalld、ufwd、iptables 管的是「进到操作系统之后」。两者都通过才能真正访问，只配一个都不够。新手常见的痛苦就是：安全组明明放行了 443，系统防火墙却把 443 挡了。这时候用 systemctl status firewalld 看一下状态，再决定是放行端口还是干脆在测试阶段关掉系统防火墙。
如果你更习惯在本地可视化地管理这些规则，市面上也有一些轻量的防火墙工具，比如 SimpleWall 这种基于 WFP 驱动的小工具，可以按程序粒度看谁在访问网络，本机调试时挺顺手。
五、连不上的时候，按这个顺序排查
安全组配完之后如果还是访问不了，别乱改，按这个顺序走一遍基本都能定位：
第一步，确认服务本身起来了。在服务器本机执行 curl -I http://127.0.0.1:80 看有没有响应。本机都不通，那跟安全组没关系，是应用或者 Nginx 本身的问题。
第二步，确认进程在监听正确的地址。用 ss -tlnp 或者 netstat -tlnp 看监听列表。有个很常见的坑：Nginx 配置里写了 listen 127.0.0.1:80，那它只接受本机访问，外部怎么都连不上，必须改成 listen 0.0.0.0:80 或者带具体 IP 的 listen。还有些服务默认绑 IPv6 的 :: 地址，某些环境下表现也不一样。
第三步，确认安全组规则匹配。回控制台逐条看协议、端口、来源三个字段。特别注意两点：一是端口写成了范围或者写反了；二是你改的是另一个安全组一台机器可以挂多个安全组，或者规则改在别的实例上，这些都很常见。
第四步，确认系统防火墙没拦。前面说过，这里是第二大高频原因。
第五步，确认域名解析指向的是不是这台机器。dig 一下你的域名，看看解析出来的 IP 和控制台里的公网 IP 是否一致。这一步能揪出很多「配置都对但就是打不开」的情况，典型场景是换了 IP 忘了改解析，或者 DNS 还挂在旧服务器上。
第五步之后再不通，才轮到运营商线路、安全防护误判这类外部因素。顺带一提，做多地区访问测试的时候，用 ping 工具类的多节点检测能快速判断是不是某个区域的路由问题，而不是你的配置问题。
六、几个安全组相关的实用习惯
改规则前先导出备份。控制台一般都能导出规则成 JSON 或 CSV。安全组改错了连 SSH 都进不去的情况我遇到过几次，备份就是给自己留后路。
给自己留一条保命通道。如果你有多个 IP、或者有云厂商的 VNC/网页控制台直连功能，一定要提前确认那个入口是通的。有的厂商网页控制台走的是内部通道，不受安全组限制，这就是你配错规则时的救命稻草。
一次改一条，改完立刻测。同时放开五个端口然后一起测，出问题你根本不知道是哪条规则的事。养成小步迭代的习惯。
定期回看规则表。很多机器跑了两年，规则里还留着当初调试用的 8000、8888、测试用的 MySQL 3306 端口，来源全是 0.0.0.0/0。这些就是典型的隐患入口，隔几个月清理一次，把不再用的规则删掉。
数据库端口永远不要对公网开放。需要远程连数据库就走 SSH 隧道或者内网连接，安全组里 3306、5432、6379 这类端口来源应该是内网网段或者干脆不开放。
写在最后
安全组配置本身没什么技术含量，它更像一份「权限申请表」：你需要什么服务，就开什么端口，能指定具体来源就别图省事写 0.0.0.0/0。真正花时间的是那套排查思路本机不通看应用，本机通外部不通看安全组和系统防火墙，规则都对还不行看解析。
把这套流程走顺了，你以后开任何一台新机器，半小时内就能把环境和访问都配置到位，也不用担心哪天真被人在扫端口的时候摸进来。工具和面板会一直变，但「默认拒绝、精确放行、分层排查」这个思路不会过时。
喜欢 
顶
难过
囧
围观
无聊
