首先，如何突破CDN技术，获得真正的IP，这是因为域前置技术不同于我们以往所认识的突破CDN,HOST头完全是一个任意域名，所通信的IP地址都是负载IP，无迹可查。其次，假定通过域前技术得到了服务商的帮助，但CDN加速所指向的域名地址是Nginx反向代理地址，并且仅仅判断域名不能确定是哪一个提供的反代服务。第3层，假定溯源能够知道提供服务的Ngrok，维护人员愿意提供帮助，但作为反代服务，因为Ngrok等大多数反代提供商都是匿名注册的，而且当我们没有进行反代连接时，服务器上也看不到我们真正的IP地址，但我们当然可以获得我们的反代端口，这样我们就可以对这一端口进行严密监视，也不必太担心。实际上，在反代这一方面上还有一个谬论，那便是未必是Ngrok，我们可以采用国外的其他反代服务提供者，比如hiroku，或者是我们用肉鸡做的，这样都是无法被发现的，即使有各方面的支持，追踪也是困难的。

接下来，就让我们来谈谈大家最感兴趣的域前溯源思想，当然，今天这一方法还没有很好的溯源方法，所以说说我个人以及与朋友交流后的一些想法。对于不同的负载IP对应哪家CDN厂商做收集进行整合？当然他提出了一个主流大厂去验证域名归属，小厂去做标记，我觉得这也是一个办法，但毫无疑问这是一个很大的工作量。第三，我有个建议，按照第一条所说，如果CDN提供商能够知道它所采用的CDN，那么，结合HOST头，我们完全可以推导出他的CNAME值，因为加速域名在同一个CDN服务提供商中是唯一的，而且在域前置的实施方案中，CNAME已经能够指向一个真正的IP进行通信。因此，借助服务提供商的帮助是完全可能找到真正的IP的，当然我们上面提到的“二层隐藏”无疑也是造成这种追溯猜测的另一个难题。

前几篇文章分别对这两种方法分别进行了说明，阐述了它们的优点和缺点，但二者如何结合呢？让我们一起来看看吧！动作步骤，首先配置一个普通的域前置，和上面配置反向代理的方法一样，请注意回源化配置，这里的域名地址配置为云函数触发的API网关地址。