云服务器添加入站规则，其实没你想的那么复杂

很多人第一次接触云主机时，最容易卡住的，不是买服务器，也不是装系统，而是云服务器添加入站规则这一步。表面看只是“开个端口”，实际上它关系到服务能不能访问、数据库会不会暴露、项目上线后是否安全稳定。规则配对了，网站、接口、远程连接都能正常跑；规则配错了，轻则访问失败，重则直接把机器暴露在公网。

所以，别把入站规则当成后台里一个不起眼的小选项。它本质上是在告诉云平台：哪些来源、通过什么协议、访问哪些端口，可以进这台服务器。只要理解了这个逻辑，后面不管是部署网站、开放SSH、运行API，还是给测试环境临时放行，都不会再靠“试错碰运气”。

先弄明白：入站规则到底控制什么

简单说，入站规则控制的是“外面的请求能不能进来”。比如：

• 你想用SSH远程登录Linux服务器，需要放行22端口；
• 你部署了网站，需要放行80和443端口；
• 你跑了一个Java服务监听8080端口，如果外部要访问，就得放行8080；
• 你装了MySQL监听3306端口，但如果只想本机访问，就不应该对公网开放。

很多新手会误以为“程序启动了就能访问”。其实不是。程序监听端口只是第一层，云控制台的安全组或防火墙规则是第二层，系统内部防火墙可能还是第三层。也就是说，云服务器添加入站规则只是打通链路的一部分，但往往是最关键的一环。

常见的规则字段，别再一看就懵

大多数云平台的入站规则界面都差不多，核心就是以下几项：

1. 协议类型

常见有TCP、UDP、ICMP，或者“All”。

• 网页访问、SSH、MySQL、Redis，大多数用的是TCP；
• 某些音视频、游戏、DNS服务可能用UDP；
• ICMP通常对应ping测试；
• 不是特别确定时，不建议直接选All，范围太大。

2. 端口范围

可以是单个端口，比如22、80、443，也可以是一个范围，比如8000-9000。原则上，能开单个就别开一段，能开一段就别全开。

3. 来源地址

这是最容易出问题，也最体现安全意识的地方。来源地址通常写成CIDR格式：

• 0.0.0.0/0：表示所有IPv4地址都能访问；
• 你的办公公网IP/32：表示只有这一台出口IP能访问；
• 某个内网网段：表示只允许内网或特定网络访问。

新手最喜欢图省事，直接把所有端口来源都设成0.0.0.0/0。短期省事，长期埋雷。像22、3306、6379、9200这类敏感端口，绝对不建议无脑全网开放。

哪些端口该开，哪些端口最好别开

下面给一个比较实用的判断思路：

适合公网开放的常见端口

• 80：HTTP网站访问；
• 443：HTTPS网站访问；
• 22：SSH远程登录，但最好限制来源IP；
• 特定业务端口：比如你的API明确跑在8080、9000等端口。

谨慎开放的常见端口

• 3306：MySQL；
• 5432：PostgreSQL；
• 6379：Redis；
• 27017：MongoDB；
• 9200：Elasticsearch；
• 11211：Memcached。

这些数据库或中间件端口，通常更适合内网访问，或者只对固定IP开放。很多安全事故不是“被黑客高水平攻破”，而是自己把服务大敞四开。

一个真实感很强的场景：网站部署好了却打不开

有个很典型的案例。某团队把一个后台管理系统部署到云服务器，Nginx已经启动，域名也解析到了公网IP，浏览器访问却一直超时。他们先查Nginx配置，又查应用日志，折腾了半天没结果。

最后问题就出在云服务器添加入站规则没做完整：只放行了22端口，忘了开80和443。外部请求根本到不了Nginx，自然也不可能返回页面。

这个案例说明一件事：“服务正常”不等于“链路畅通”。当你遇到“本机能访问、外部不能访问”的情况，优先检查三层：

1. 应用是否真的在监听目标端口；
2. 云平台是否已添加对应入站规则；
3. 系统防火墙是否放行该端口。

再看一个更危险的案例：数据库被直接暴露公网

另一种情况更常见，也更危险。某创业团队为了让开发同事远程连测试库，直接把3306端口放开，来源写0.0.0.0/0，密码还比较简单。结果没几天，数据库就出现异常登录和大量扫描记录。

他们原本只是想“临时方便一下”，但安全问题往往就发生在这种临时操作里。正确做法应该是：

• 优先通过内网访问数据库；
• 如果必须公网连接，只允许固定办公IP访问；
• 配合强密码、最小权限账号；
• 用完及时关闭临时规则。

所以，云服务器添加入站规则不是单纯的运维动作，更是安全边界的设置。你每多放开一个端口、每多扩大一个来源范围，攻击面就随之增加。

实操思路：添加入站规则时按这个顺序判断

不管你用哪家云平台，都可以按照这个顺序来：

1. 先确认需求：到底要开放什么服务，是网站、SSH，还是API接口；
2. 确认端口：程序监听的是哪个端口，不要凭感觉填；
3. 确认协议：通常选TCP，别随手全选；
4. 确认来源：能限制到固定IP就不要放全网；
5. 确认时效：临时规则做完事就删除；
6. 最后验证：从外部网络实际访问一次，看是否真正生效。

这里有个经验特别重要：规则不是越多越好，也不是越宽松越省事，而是越贴合业务越安全。你要养成“按需开放”的习惯，而不是“先全开、后面再说”。

为什么明明加了规则，还是访问不了

这是很多人第二阶段会遇到的问题。明明已经完成了云服务器添加入站规则，结果服务还是不通。常见原因一般就这几个：

• 应用只监听了127.0.0.1，没有监听公网网卡；
• 系统防火墙如firewalld、iptables、ufw没放行；
• 安全组绑错了实例，规则加到了别的机器上；
• 端口填错，比如程序跑在8080，你放行成了8000；
• 配置改了但服务没重启；
• 运营商、公司网络或本地环境本身做了限制。

遇到这种情况，不要只盯着云控制台反复刷新。最有效的做法是逐层排查：先在服务器本机curl或telnet本地端口，再从同网段机器测试，最后再从公网测试。这样能快速判断问题到底卡在哪一层。

给新手的几个实用建议

• 22端口不要对全网长期开放，最好限制为自己的固定公网IP；
• 数据库端口尽量不暴露公网，优先走内网、跳板机或VPN；
• 开放前先记录，开放后及时复核，避免时间久了没人知道哪些规则还有用；
• 测试环境比生产环境更容易失控，因为大家常觉得“先能用再说”；
• 每次上线新服务，都把入站规则当作发布检查项，别等访问失败再补。

写在最后

云服务器添加入站规则看似只是控制台里的一个小操作，实际上它决定了你的服务是“可达”还是“隔离”，是“安全上线”还是“带着风险裸奔”。真正专业的做法，不是把端口一股脑全开，而是清楚知道：为什么开、给谁开、开多久、出了问题怎么回收。

如果你现在正好遇到网站打不开、接口不通、远程连不上，先别急着怀疑程序有问题，先回头看看入站规则。很多时候，问题就出在这一步。把这个底层逻辑想明白，以后不管换哪家云平台，操作界面再变，你也能稳稳处理。