在接入CDN或更换服务器时，一定要先隐藏好源站地址，再修改DNS解析记录，否则源站IP会直接暴露在公网，失去CDN的防护意义。
改解析记录前先隐藏源站的真实原因
很多站长在接入CDN时习惯先修改DNS解析，让域名指向CDN节点，然后才去配置源站防护，这个顺序一旦搞反，源站IP会在短时间内被扫描工具捕获,直接暴露在攻击者面前。
源站IP暴露的常见场景
- 网站迁移或换IP时：旧IP还未完全回收，新IP先被解析记录指向,导致真实服务器地址泄露。
- CDN配置错误：回源HOST设置不当，让CDN节点直接回源到公网IP,日志中暴露源站。
- 多域名共用服务器：一个服务器上跑多个网站，其中一个域名未隐藏源站,通过DNS记录反查就能找到同一IP下的其他站点。
为什么隐藏源站要在改解析之前完成
域名解析记录是公开的，一旦将A记录或CNAME指向CDN，全球DNS服务器会缓存这条记录，如果此时源站还未做任何限制，任何知道源站IP的人都可以直接访问服务器,绕过CDN的所有安全策略。
行业共识认为，先配置源站访问控制，再修改DNS记录，可以将暴露窗口从小时级缩短到分钟级，甚至完全消除，因为当DNS记录切换时,源站已经只允许CDN节点回源了。
隐藏源站地址的几种实用方法
隐藏源站地址并不复杂，但需要按步骤操作，下面介绍四种主流方法,你可以根据服务器环境选择组合使用。
通过防火墙限制回源IP
这是最直接的方法，在服务器上配置防火墙规则，只允许CDN节点的IP段访问你的网站端口（80/443）。
- 登录云服务器控制台,找到安全组或防火墙配置。
- 获取你所用CDN的官方回源IP段列表（通常每个CDN厂商都有公开文档）。
- 添加入站规则：仅允许这些IP段通过HTTP/HTTPS端口访问。
- 同时拒绝所有其他IP的访问，包括你自己的公网IP（测试时可以用CDN节点IP或内网访问）。
操作提示：有些CDN厂商会定期更新回源IP段，建议设置自动同步或定期检查,避免回源失败。
使用CDN的源站防护功能
主流CDN服务商都提供了源站IP隐藏功能，比如简米云CDN的“源站保护”、Cloudflare的“Authenticated Origin Pulls”等。
- 在CDN控制台开启“源站IP隐藏”或“回源鉴权”。
- 将生成的密钥或证书配置到源站服务器上。
- 开启后，CDN节点在回源时会携带特定Header或证书,源站只响应携带正确凭证的请求。
这种方法不需要手动维护IP白名单，安全性更高，但需要服务器端额外配置。
通过反向代理做二次转发
如果你的架构允许，可以在源站前再加一层反向代理（如Nginx、HAProxy）,只让代理服务器暴露在CDN回源网络中。
- 在源站服务器上安装Nginx，配置监听内网IP或127.0.0.1。
- 使用另一台低配服务器（或同一台服务器的不同网卡）作为反向代理,只允许代理服务器访问源站。
- 将CDN的回源地址指向代理服务器,代理服务器再将请求转发到真正的源站。
这种架构适合对安全要求较高的场景，源站彻底不接触公网，只在内网通信。
修改源站服务器监听地址
如果服务器有多个网卡，可以只让Web服务监听内网IP或回环地址,然后通过端口转发或iptables将公网流量导向内网。
- 编辑Web服务器配置文件（如Nginx的listen指令），将监听地址改为127.0.0.1:80或内网IP。
- 使用iptables或firewalld做DNAT,将CDN回源IP段的流量转发到该内网IP。
- 这样公网IP上不直接监听服务,扫描工具无法识别端口状态。
这种方法适合有一定Linux操作经验的用户，配置相对复杂，但隐蔽性极好。
改解析记录时的具体操作流程
当你已经完成源站隐藏配置后，再动手修改DNS解析记录，这里有几个关键步骤,能帮你减少切换过程中的风险。
降低TTL值提前准备
- 在计划切换前24-48小时，将DNS解析记录的TTL（生存时间）临时改小，比如300秒（5分钟）。
- 这样当你最终修改记录时，全球DNS缓存能快速更新,不会长时间指向旧地址。
- 等待切换稳定后，再将TTL改回正常值（如3600秒或更高）。
先验证隐藏效果再改解析
- 使用在线工具或本机curl命令，模拟从不同IP访问你的源站IP（非域名），确认80/443端口已拒绝连接或只响应CDN节点。
- 检查服务器日志，确认只有CDN回源IP的访问记录,没有其他陌生IP的请求。
- 用域名通过CDN节点访问网站，确保页面正常加载,且回源过程没有报错。
逐步切换解析记录
- 如果你有多个DNS服务器或使用了智能DNS，可以先修改部分线路的解析记录（如仅电信线路）,观察一段时间。
- 确认无异常后再切换全部线路,避免出现大面积访问故障。
- 切换完成后，保留旧解析记录一段时间，但指向一个黑洞地址或无效IP,防止遗漏的缓存继续访问旧服务器。
实际场景：换了CDN却忘了隐藏源站
一位站长接手了一个老网站，打算从传统CDN切换到更便宜的海外CDN，他按照教程先修改了DNS的CNAME记录，指向新CDN节点，然后去配置新CDN的源站信息，结果在配置过程中，新CDN节点还没生效，旧CDN已经在逐步失效，导致源站IP直接暴露在公网，不到两小时,服务器日志里就出现了大量扫描和暴力破解请求。
解决方案：他立即在服务器上启用了iptables，只允许新旧两个CDN的IP段访问，同时关闭了所有其他端口的公网访问，然后重新调整了DNS解析顺序：先配置好新CDN的源站隐藏，再修改DNS记录,最后等待旧CDN节点完全失效后才移除旧规则。
这个案例说明，顺序错乱带来的暴露窗口虽然短暂，但足够被自动化工具捕获，如果先做好源站隐藏，即便是配置失误,攻击者也无法直接触碰服务器。
常见问题解答
隐藏源站IP后，如何验证是否真的隐藏成功
使用在线端口扫描工具（如Shodan、Censys）查询你的源站IP，看80/443端口是否显示为关闭或过滤状态，或者用手机切换4G网络，直接访问源站IP，如果不能打开网页，说明隐藏生效，同时检查服务器日志,确认只有CDN节点IP的请求记录。
我已经改了解析记录，还能再隐藏源站吗
可以，但需要尽快操作，先立即在服务器上配置防火墙规则，只允许当前CDN的回源IP段访问，然后确认CDN控制台开启了源站防护功能。只要源站IP没有被大量扫描并记录，及时补救也能降低风险，如果已经出现攻击，建议立刻更换源站IP,并重新配置隐藏。
使用了CDN就一定安全吗，还需要隐藏源站吗
CDN只是隐藏了源站IP的默认路径，并不代表源站IP不可被探测，如果源站配置不当，仍然可能通过历史DNS记录、子域名扫描、证书透明日志（Certificate Transparency）等方式暴露真实IP，隐藏源站地址是CDN安全策略的最后一环,也是最重要的一环。
无论是个人博客还是企业官网，改解析记录前先隐藏源站，都应该成为接入CDN的标准操作流程。 安全不是功能，而是习惯，把这个习惯固化到每次变更中,远比事后补救更省心。