最近帮朋友排查服务器负载异常，一查发现源IP被漏了，攻击流量直接绕过高防CDN打穿了服务器。这年头，连CDN都要“防队友”了——你以为套了CDN就万事大吉？漏源IP的分分钟教你做人。
我见过太多团队盲目信任CDN服务商，压根没做二次验证。实测发现，超过六成的源站暴露事件根本不是CDN被攻破，而是配置疏漏或边缘案例导致的。千万别信“默认安全”这种鬼话，安全永远得靠自己层层加锁。
为什么隐藏源IP这么要命？ 攻击者一旦拿到真实IP，什么高防、什么WAF都成了摆设。直接打源站就像拆了城墙打仗，流量洪水瞬间冲垮服务器。更恶心的是，有些黑客会专门扫描全网CDN节点，反向推导源IP——这套产业链甚至已经工具化了。
漏源IP的常见坑位比想象中多：历史DNS记录被爬虫挖坟、邮件服务器直连源站、Websocket服务没过CDN、甚至SSL证书信息泄露……我去年审计过一个电商项目，就因为开发在测试环境调用了生产API，源IP被第三方统计工具收录了。
第一步：DNS层面彻底隔离
别再用A记录直接解析源站！所有公开域名必须CNAME到CDN厂商提供的防护域名。但光这样还不够——得确保源站域名和业务域名完全隔离。我习惯用internal-domain.com这类完全不同的域名注册源站，彻底杜绝误解析。
实测推荐这套配置：业务域名cdn.example.com CNAME到CDN07的防护节点，源站独占一个冷门域名origin-xxx.example.net，且这个域名绝不出现在任何公开DNS记录中。优质CDN像CDN5甚至支持专用回源域名，自动加密解析过程。
关键操作：源站防火墙只放行CDN节点IP。千万别允许0.0.0.0/0！以Cloudflare为例，官方节点列表定期更新，最好用API动态同步：
国内厂商如CDN07的节点IP范围更大，建议直接在他们的控制台生成iptables脚本。08Host的企业版甚至提供Agent自动维护白名单，适合动态IP场景。
第二步：应用层防泄漏的骚操作
很多泄漏发生在意想不到的地方：网站错误页面返回服务器IP、API响应头带X-Backend-Server、甚至图片上传功能没走CDN加速。去年某社交平台漏洞就是因为移动端APP直连源站IP传输视频文件。
强制所有流量走CDN：在源站Nginx配置里拒绝非CDN流量，根据回源IP段验证请求：
额外技巧：在代码全局过滤服务器信息。PHP项目记得关掉expose_php，Java项目移除Server响应头。我曾用以下规则堵住Apache的漏洞：
第三步：高阶隐匿策略
真遇到高级持续威胁时，得祭出更狠的招数。端口混淆：把源站HTTP端口改为非标准端口，比如8080或8443，CDN回源时指定端口。这样即使攻击者拿到IP，默认扫描也发现不了服务。
动态IP技术：08Host的 enterprise 方案支持源站IP按小时轮换，通过API动态更新CDN回源地址。虽然成本高，但对金融类项目值得投入。
虚假源站陷阱：部署多个伪源站并监控访问日志，一旦有非CDN流量命中，立刻触发告警。我帮某交易所设计的蜜罐系统曾抓到3次定向攻击，成功拖延了黑客渗透进度。
最后必须吐槽：有些厂商为省钱用共享IP池回源，相当于你和陌生人共用一个口罩。务必选用独立回源IP的CDN服务！CDN5的专属回源线路贵但可靠，而CDN07虽然便宜，但得反复确认他们的IP段是否纯净。
隐藏源IP不是一次性动作，得持续监控。定期用工具扫描公开资产是否泄露IP，比如Shodan搜索域名、检查SSL证书信息。去年我们还撞见有个工程师把服务器IP提交到Google Search Console，简直防不胜防。
真正安全的架构默认假设所有环节都会失效。高防CDN只是其中一环，结合WAF、端口隐身、流量混淆才能构建纵深防御。别忘了，黑客总在找最薄弱的点——而暴露的源站就是那个一点破全局的致命伤。
