数据库连不上、接口返回403，很多人会先查代码和网络，绕了一圈才想到看白名单。阿里云白名单配得好，能挡住大部分无关流量。配得草率，服务就可能直接暴露在公网上。下面先说它的工作方式，再用两个案例看配置时容易踩的坑。
白名单是怎么工作的
白名单的规则很直接：列表里的来源可以访问，其他请求一律拒绝。阿里云不同产品里它的叫法不同。云数据库RDS里叫数据库白名单，对象存储OSS里是Referer白名单，网络层面则落在安全组和访问控制规则上。叫法不同，判断方法是一样的。先想清楚谁需要访问，再把范围收窄到够用为止。名单写得越精确，别人能钻的空子就越少。
案例一：RDS连接超时，问题出在白名单
某电商团队把新订单服务接入阿里云RDS。本地调试一切正常，部署到测试环境后却频繁超时。团队依次检查了账号密码、端口和连接池参数，都没有问题。
最后打开RDS控制台的白名单，才发现里面只放行了办公室的出口IP。测试环境的ECS走的是另一个公网出口，请求在数据库入口就被挡住了。团队把ECS所在的内网网段加进白名单后，问题立刻消失。
排查这类问题，可以先在ECS上用telnet或nc测试数据库端口是否能通。端口不通，多半是白名单或安全组的问题。端口通了，再去查账号和参数。
这件事有两点可以直接用在日常配置里。其一，应用和数据库在同一地域时，优先走内网地址。这样流量不经过公网，数据库也不必为了连接而开放到外网。其二，白名单要对应真实的部署结构。别凭记忆填IP，先在服务器上确认它实际使用的出口地址，再填进去。
案例二：图片被盗链，流量账单突然涨了
一家内容平台的OSS存储桶在某段时间流量明显增加，账单跟着涨。排查后发现，好几个第三方网站直接引用平台的图片地址，等于用平台的带宽给自己的页面供图。
团队配置了Referer白名单，只允许自己的域名和少数合作伙伴域名访问资源。同时开启了空Referer限制，拦下了一部分直接在地址栏打开或脚本抓取的请求。两周内，异常流量下降了七成以上。
Referer很容易被伪造，所以它只适合挡住普通盗链，不能当作身份认证。涉及合同、财务等敏感文件时，应当配合签名URL使用。给每个链接设置有效期，只签发给需要的人，链接泄露后也能很快失效。
配置时的几条建议
- 0.0.0.0/0只用来临时调试。对全网开放的规则要在排查结束后马上删除，否则它会一直留在那里，等于没有白名单。
- 能用网段就不用单个IP，但别图省事开大段。出口IP经常变化时，先看能否申请固定出口，或者走内网打通。实在要用网段，也要尽量缩小，网段越大，放行的机器就越多。
- 每条规则都写备注。写清用途、负责人和添加日期。半年后如果没人记得某个IP是谁的，备注就是唯一的线索。
- 每季度复查一次。人员调动、服务下线之后，旧规则最容易被遗忘。对照当前的服务清单，逐条确认还在用的才保留。
- 白名单之外还要做权限控制。账号按最小权限分配，密码定期更换，并保留操作日志，出问题时才能追溯。
遇到拒绝访问，先看白名单
白名单本身不复杂，难的是长期维护。每次改规则前，先确认这个来源还在不在用，改完再验证一次连接。遇到连接超时或403，不要急着怀疑代码。先打开白名单，核对当前出口IP是否在列表里。很多时候，问题就出在这里。
