阿里云账号实名代办阿里云国际版防火墙规则

阿里云国际 / 2026-04-14 14:44:07

各位正在阿里云国际版后台疯狂点鼠标、反复刷新SSH连接失败页面的朋友，先放下手里的咖啡，深呼吸三次——不是你服务器坏了，不是你密码输错了，大概率，是你和防火墙之间，正在进行一场没有翻译官的跨语言谈判。

阿里云国际版（Alibaba Cloud International）的防火墙，表面看就俩按钮：Security Group（安全组）和Network ACL（网络访问控制列表）。名字听着像孪生兄弟，实则性格迥异、分工明确、互不背锅。很多人配完发现：ping 不通、telnet 超时、网站打不开、数据库连不上……最后抓耳挠腮翻文档三小时，才发现——哦，原来安全组放行了22端口，但Network ACL默默把整个子网的入向流量全拦了。

别急，咱今天不念PPT，不抄控制台Help文档，就用修水管、开快递柜、管小区门禁这三套生活比喻，把这套「云上守门系统」给你盘明白。

一、安全组：你家智能门锁 + 物业前台（实例级防护）

安全组（Security Group），是绑在ECS、RDS、SLB这些具体云资源上的「贴身保镖」。它只认两件事：谁来（源IP/安全组）、想干啥（协议+端口），其他一概不管。

✅ 它的特点很「人情味」：
• 有状态：你允许入站TCP 80，出站响应自动放行，不用额外配；
• 无默认规则：新建安全组，默认所有流量全拒——不是阿里云小气，是怕你刚开机就被扫出100个爆破请求；
• 支持安全组引用：A组可直接引用B组作为源，适合微服务间互通，比写一堆IP清爽多了；
• 最多200条规则，但建议你别真写到199条——后期排查时，你会对着列表默念《心经》。

⚠️ 常见翻车现场：
• 把「0.0.0.0/0」当成万能钥匙，结果被扫描器盯上，半夜收到阿里云安全告警邮件，标题写着《您的ECS疑似正被用于挖矿》；
• 改完规则不点「保存」，只点了「确定」——注意！国际版控制台里，「确定」≠「保存」，它只是关闭弹窗；
• 给Windows服务器开了3389，却忘了检查本地防火墙（Windows Defender Firewall）是否也在同步拦截；
• 测试用curl -v http://your-ip，结果返回Connection refused——不是防火墙问题，是你的Nginx根本没启动。

二、Network ACL：小区主干道红绿灯（子网级兜底防护）

Network ACL（简称NACL），是挂在VPC子网（Subnet）上的「交通协管员」。它不管你是谁家的服务器，只看数据包从哪来、往哪去、走哪条路。

✅ 它的性格很「公务员」：
• 无状态：入站放行80，出站必须单独配一条允许响应返回，否则HTTP请求发出去，回不来；
• 有默认规则：每张NACL自带两条隐式规则——最末尾拒绝所有入站+所有出站，且无法删除；
• 按顺序匹配：规则编号越小优先级越高，100→200→300，遇到第一条匹配就执行，后面的直接无视；
• 支持显式拒绝：你可以写一条「拒绝192.168.100.0/24访问」，比安全组只能「允许」更硬核。

⚠️ 高频致郁时刻：
• 新建子网时，系统自动关联了一个「默认NACL」，而这个默认表里——只有两条拒绝规则；
• 你兴冲冲加了5条允许规则，编号全设成100，结果系统按字典序排成了100, 100, 100… 实际只生效第一条；
• 修改NACL后，流量没立刻变，因为部分连接已建立（TCP ESTABLISHED），要等会话超时或主动断开才走新规则；
• 在多可用区部署时，每个子网都要单独配NACL——别想着复制粘贴，AZ不同，子网ID不同，规则得重来。

三、双保险？不，是双关卡：它们怎么配合又互相扯皮？

流量路径是这样的：
公网 → EIP/NAT网关 → NACL（子网层） → 安全组（实例层） → ECS内部防火墙 → 应用进程

阿里云账号实名代办 也就是说：NACL先拦第一道，安全组再拦第二道，任一关卡喊“停”，你就进不去。就像寄快递：快递柜（NACL）说“不收非本楼件”，你家门锁（安全组）说“不给陌生人开门”，两个都得点头，包裹才能进屋。

💡 真实排障口诀：
• 连不上？先看NACL是否允许该方向流量；
• 能ping通但端口不通？说明NACL过了，安全组可能卡住了；
• 同一子网内两台ECS互访不通？检查双方安全组是否双向放行，NACL是否限制了私网流量；
• 换了个IP就失效？大概率你在安全组里写了旧EIP，而不是用安全组ID引用。

四、手把手：三分钟配好Web服务器（含避坑注释）

场景：一台新加坡区域ECS，跑Nginx，需对外提供HTTP/HTTPS，允许SSH管理，禁止其他所有访问。

Step 1｜安全组配置（推荐新建专用SG）
• 入方向：
  – 类型HTTP，端口80，源0.0.0.0/0（或CDN回源段）
  – 类型HTTPS，端口443，源同上
  – 类型SSH，端口22，源限定为你的办公IP（如203.123.45.67/32），千万别写0.0.0.0/0！
• 出方向：
  – 全部放行（或按需配DNS/更新源）

Step 2｜NACL检查（重点！）
• 进入VPC → 子网 → 查看关联的NACL
• 若是默认NACL，立刻解绑，新建一个命名清晰的（如web-prod-nacl）
• 入站规则：
  100：允许TCP 80，源0.0.0.0/0
  110：允许TCP 443，源0.0.0.0/0
  120：允许TCP 22，源你的办公IP/32
  130：允许ICMP（方便诊断）
  200：拒绝全部（留给系统兜底）
• 出站规则同理：80/443/22/ICMP放行，其余拒绝

Step 3｜终极验证清单
□ SSH能否登录（注意：确认是22端口，不是2222）
□ curl -I http://你的公网IP 返回200 OK
□ telnet 你的公网IP 80 显示Connected
□ 用手机流量访问网站，确认非局域网专属
□ 查看ECS内netstat -tuln | grep :80，确认Nginx真在监听
□ 登录阿里云「VPC流日志」，筛选被拒绝的流，一眼定位拦截环节

五、彩蛋：那些没人告诉你、但能救命的细节

• 安全组规则不支持「范围端口」写法：不能写「8000-9000」，得拆成8000、8001……直到9000（别试，控制台会报错）；
• NACL规则数上限是20，不是200——超了会提示「Rule quota exceeded」；
• 修改安全组后，已有连接不受影响，新连接才走新规；
• 国际版控制台语言切换会影响规则描述显示，中文界面下写的「允许HTTP」，切英文后变成「Custom TCP Rule」，容易误判；
• Cloudflare等CDN回源IP段经常变，别死写IP，查官方文档定期更新，或干脆让CDN传X-Forwarded-For头，后端校验。

最后送一句掏心窝子的话：云防火墙不是越严越好，也不是越松越爽。它是你数字资产的第一道呼吸阀——太紧，业务窒息；太松，风险呛喉。配完别急着关页面，留5分钟，用另一台机器、另一个网络、甚至开个手机热点，真连一次。毕竟，所有「应该能通」的假设，都不如一次真实的curl来得诚实。

祝你今晚的SSH连接，一次成功，不重启，不怀疑人生。