没有不值得去解决的问题,也没有不值得去学习的技术!

停用 Adsterra Native Banner 6 天后:异常跳转消失,但浏览器安全警告仍在

【图 1:8 月 8 日,手机系统浏览器访问博客时出现“网站存在安全隐患”提示】

作者:

前段时间,我在博客中尝试接入了 Adsterra,希望在 Google AdSense 之外增加一种新的广告变现方式。

当时我并没有部署 Popunder、Social Bar 等广告形式,实际使用的只有 Native Banner,一共部署了 3 个广告位:

  • 中文文章详情页正文末尾;
  • 中文归档页文章列表末尾;
  • 英文归档页文章列表末尾。

原本只是一次正常的广告平台测试,但运行一段时间以后,我在手机端遇到了几个非常反常的现象。

首先,是手机系统自带浏览器突然开始提示我的网站存在安全风险。

正是因为出现了这个警告,我才进一步想到:

如果系统浏览器已经认为网站存在风险,那么其他移动端浏览环境会不会也有问题?

于是,我又专门使用微信打开博客文章进行测试。

没想到这一测试,真的发现了更加严重的问题:正常打开文章后,页面竟然自动离开了我的博客,经过陌生域名跳转,最后甚至进入了手机短信发送界面。

这些现象让我开始严重怀疑最近接入的 Adsterra Native Banner。

于是,8 月 8 日我决定先把 Adsterra 全部停掉,不主动清理缓存,而是等待缓存自然过期,再观察几天后的结果。

现在已经到了 8 月 14 日,距离停用 Adsterra 已经过去 6 天,可以整理一下这次实际测试得到的阶段性结果了。


一、事情的起点:系统浏览器突然提示网站存在安全隐患

2026 年 8 月 8 日早上,我使用手机系统自带浏览器打开自己的博客时,突然遇到了安全拦截。

【图 1:8 月 8 日,手机系统浏览器访问博客时出现“网站存在安全隐患”提示】
【图 1:8 月 8 日,手机系统浏览器访问博客时出现“网站存在安全隐患”提示】

浏览器直接提示:

网站存在安全隐患

并提醒可能存在账号、密码等重要信息泄露风险,建议停止访问。

当时看到这个提示,我相当意外。

毕竟这是我自己长期维护的博客,访问的也是正常主域名。

如果只是偶尔出现一次异常,我或许还会怀疑是不是浏览器误报。

但这个安全提示让我产生了一个新的想法:

既然系统浏览器已经开始警告,那么是不是网站在某些移动端环境中真的出现了什么异常行为?

于是,我决定继续测试。


二、正因为系统浏览器出现警告,我才进一步用微信测试

发现系统浏览器的安全警告以后,我没有停在这里。

我随后专门使用微信打开博客中的文章详情页面,希望看看在另外一种常见的移动端浏览环境中,网站是否能够正常访问。

结果这次测试反而发现了更严重的问题。

文章页面刚刚显示出来不久,就突然离开了我的网站。

随后微信出现了外部网址访问警告。

【图 2:8 月 8 日,微信打开博客文章后自动跳转至 rd.rvcovers.click】
【图 2:8 月 8 日,微信打开博客文章后自动跳转至 rd.rvcovers.click

准备访问的地址已经变成:

Plaintext
https://rd.rvcovers.click/pop.go?spaceid=...

这显然已经不是我的博客域名。

更关键的是,我当时只是正常打开自己的文章,并没有主动点击什么明显的外部链接。

也就是说,这并不是:

用户主动点击广告以后进入广告页面。

而是:

正常打开博客文章后,页面自行发生了异常跳转。

这让我对前面系统浏览器出现的安全警告更加警觉。

因为两个现象虽然表现形式不同,但它们是在同一个时间段内出现的。


三、异常跳转最后甚至进入了短信发送界面

事情还没有停在陌生域名跳转这里。

继续经过后续页面以后,又出现了所谓的验证流程。

最终,手机甚至直接进入了短信发送界面。

【图 3:8 月 8 日,异常跳转最终进入短信发送界面】
【图 3:8 月 8 日,异常跳转最终进入短信发送界面】

短信收件人中已经出现境外电话号码,同时短信正文也被自动填写。

这已经远远超出了我对于普通网页广告的接受范围。

对于站长来说,我当然知道网站正文、广告平台和广告主之间可能是不同的系统。

但普通访客不会这样区分。

用户只是想打开一篇技术文章,结果却遇到:

Plaintext
正常文章

陌生域名

其他落地页面

短信发送界面

最终用户最容易形成的印象其实只有一个:

这个网站可能有问题。

而真正受到影响的,还是我的网站域名和用户信任。


四、为什么我开始严重怀疑 Adsterra?

回想最近一段时间网站上的变化,Adsterra 是一个非常明显的新变量。

而且除了异常跳转之外,我此前使用 QQ 浏览器查看网站时,还发现 Adsterra Native Banner 的部分广告素材质量比较一般,图片比较模糊,一些广告内容与技术博客本身也不是很协调。

与此同时,Google AdSense 的每千次展示收入也已经从此前大约:

Plaintext
0.7

下降到了:

Plaintext
0.4

当然,仅凭 AdSense 收入下降,不能证明 Adsterra 就是原因。

广告收入本来就会受到流量、用户地区、广告竞价、展示次数等多方面因素影响。

真正让我决定停用 Adsterra 的,还是几个现象同时出现:

  • 系统浏览器开始对网站发出安全警告;
  • 微信正常打开文章后发生自动跳转;
  • 跳转最后甚至进入短信发送流程;
  • Adsterra 广告素材体验并不理想;
  • 移动端整体访问情况也明显变差。

尤其是异常跳转和短信流程,对于一个长期运营的网站来说,风险已经明显高于继续测试这点广告收入的价值。

因此,我决定先把 Adsterra 完整停掉。


五、8 月 8 日:停用全部 3 个 Adsterra Native Banner

我的 Adsterra 实际部署并不复杂。

整个网站始终只使用了 Native Banner

在 WPCode 中一共有 3 个相关广告代码:

Plaintext
[Adsterra] Native Banner - 文章末尾
[Adsterra] Native Banner - 所有归档页尾部广告 - 中文
[Adsterra] Native Banner - 所有归档页尾部广告 - 英文

8 月 8 日,我将这 3 个广告位全部停用。

【图 4:WPCode 中的 3 个 Adsterra Native Banner 均已停用】
【图 4:WPCode 中的 3 个 Adsterra Native Banner 均已停用】

其中:

  • ID 20250:文章末尾广告;
  • ID 21010:中文归档页广告;
  • ID 21013:英文归档页广告。

对于两个归档页广告,我还同时进入 WordPress 主题编辑器,将模板中对应的简码删除。

因此这次实际上做了两层处理:

  1. WPCode 中停用 Adsterra 广告代码;
  2. 主题模板中删除对应的归档页广告简码。

不过,当时我并没有主动清理网站页面缓存和 CDN 缓存。

我的计划是:

让现有缓存自然过期,然后再重新测试。

这样虽然需要多等几天,但也可以比较自然地观察 Adsterra 广告从网站中逐渐退出的过程。


六、6 天以后再测试:微信中的异常跳转已经没有出现

到了 8 月 14 日,我再次使用微信打开博客文章进行测试。

【图 5:8 月 14 日,通过微信重新打开博客文章,页面可以正常访问】
【图 5:8 月 14 日,通过微信重新打开博客文章,页面可以正常访问】

这一次文章可以正常显示,并且正常停留在我的博客中。

我没有再遇到 8 月 8 日那种:

Plaintext
博客文章

陌生域名

其他落地页面

短信发送界面

的异常流程。

之前最让我担心的两种现象:

自动跳转短信发送流程,目前都没有再次出现。

这也是这次停用实验中最明显的变化。

从时间关系来看:

Plaintext
出现异常跳转

停用 Adsterra Native Banner

等待缓存逐渐过期

重新测试

异常跳转不再出现

所以目前我仍然严重怀疑此前的异常跳转与 Adsterra 有关

当然,仅凭目前这些测试,我还无法从技术层面做到百分之百证明具体是哪一段第三方广告链路触发了跳转。

但对于我自己的网站来说,风险判断已经足够明确:

停用 Adsterra 以后,此前最严重的异常行为消失了。

这已经足够让我继续保持 Adsterra 停用状态。


七、安全警告仍然存在,但我暂时并不认为这能排除 Adsterra

8 月 14 日,我又重新使用手机系统自带浏览器访问博客。

结果发现安全警告仍然存在。

【图 6:8 月 14 日,停用 Adsterra 6 天后,系统浏览器仍然显示网站风险警告】
【图 6:8 月 14 日,停用 Adsterra 6 天后,系统浏览器仍然显示网站风险警告】

不过,这次提示内容与 8 月 8 日略有不同。

8 月 8 日显示的是:

网站存在安全隐患

而 8 月 14 日显示的是:

该页面可能存在违法信息

并提到虚假宣传、欺骗消费者等风险内容。

虽然文字不同,但我目前更倾向于认为:

两次警告本质上可能仍然属于同一类网站安全或信誉风险标记。

所以我并不准备因为停用 Adsterra 6 天以后警告还没有消失,就反过来认为:

“那看来警告肯定与 Adsterra无关。”

我觉得现在下这个结论还太早。

这里至少存在两种可能。

第一种可能:安全风险记录存在时间滞后

网站之前如果真的因为第三方广告跳转等行为被某个平台记录为高风险网站,那么就算我今天已经删除相关代码,这种记录也未必会马上自动消失。

它可能需要一定时间重新检测和更新。

这与网页缓存不完全是一回事。

Adsterra 广告代码已经从网站中消失,并不代表所有浏览器或者安全平台的历史风险记录也会立即同步更新。

第二种可能:需要网站所有者主动申请复核

还有一种可能,是某些安全风险标记一旦生成以后,并不会仅仅因为问题消失就立即自动解除。

也许还需要站长主动提交申诉、恢复访问申请或者等待人工复核。

目前我还没有专门确认这个浏览器究竟使用哪一套安全检测体系,因此这里暂时只能作为后续排查方向。

但至少现在,我并不认为:

“警告还在 = Adsterra 与警告无关。”

恰恰相反。

结合 8 月 8 日出现过真实的异常跳转,以及停用之后跳转消失,我目前仍然高度怀疑 Adsterra 是整个问题的重要诱因之一。


八、移动端流量明显下降,也让我更加重视这些安全警告

另外,我后来还顺带注意到一个现象:

博客最近的移动端流量下降得比较厉害。

现在还不能证明这一定就是安全警告造成的。

但是从用户行为来看,如果一些手机浏览器、内置浏览器或者安全服务在访问网站时直接显示:

网站存在风险

或者:

页面可能存在违法信息

那么用户选择立即离开的概率显然会非常高。

甚至有些用户可能根本不会点击“继续访问”。

这意味着即使网站服务器本身运行正常,页面也能够正常打开,只要入口处被安全提示拦截,实际移动端访问量仍然可能受到明显影响。

因此,我后续除了要继续观察安全警告什么时候消失,也需要把移动端流量变化一起纳入观察。

如果未来安全警告解除以后,移动端访问量同时有所恢复,那么两者之间的相关性就会更加值得研究。


九、Adsterra 后台数据记录了缓存逐渐退出的过程

这次我还保留了 Adsterra 从部署开始一直到停用后的完整统计数据。

【图 7:Adsterra 从 7 月 26 日至 8 月 14 日的完整统计记录】
【图 7:Adsterra 从 7 月 26 日至 8 月 14 日的完整统计记录】

整个测试周期本来就只有二十天左右,因此这一次我直接把全部日期都截图保存了下来。

这张统计非常有意思。

8 月 8 日正式停用 Adsterra 以后,后台的 Impression 并没有立即变成 0。

例如:

Plaintext
8 月 8 日:17 Impressions
8 月 9 日:22 Impressions
8 月 10 日:13 Impressions
8 月 11 日:12 Impressions

然后到了:

Plaintext
8 月 12 日:0 Impressions
8 月 13 日:0 Impressions

这与我当时的处理方式基本吻合。

因为我没有主动清理缓存。

停用代码以后,部分已经生成的缓存页面仍然可能继续提供旧版本内容。

随着这些页面缓存逐渐自然过期,Adsterra 的展示量才最终降到了 0。

所以从数据上也能看到一条比较清晰的时间线:

Plaintext
8 月 8 日
停用全部 Adsterra Native Banner

8 月 9~11 日
仍存在少量历史展示

8 月 12 日以后
Impressions 降至 0

8 月 14 日
重新进行移动端测试

这也是为什么我没有在 8 月 8 日刚停用广告以后,就立即宣布问题已经解决。

等缓存自然退出以后再测试,结果会更有参考价值。


十、Adsterra 这次实际赚了多少钱?

从完整统计可以看到,这次 Adsterra 测试总共获得:

Plaintext
Impressions:221
Clicks:2
CTR:0.905%
Revenue:$2.60

整个测试周期只有二十天左右,而且展示量非常低,因此这组数据显然不足以评价 Adsterra 整个平台的长期收益水平。

从截图里还能看到,有些日期因为 Impression 极少,CPM 波动非常夸张。

这种情况下,单日 CPM 本身几乎没有太大的参考意义。

所以我不会根据这 221 次展示得出:

Adsterra 收益高。

或者:

Adsterra 收益低。

真正让我做出决定的,是另外一个问题:

为了这部分额外广告收入,我是否愿意承担潜在的异常跳转、用户信任和域名信誉风险?

经过这次实际经历以后,我的答案已经非常明确:

不愿意。

最终整个测试一共只有 $2.60 收入。

哪怕以后流量增加、收益有所提高,只要异常跳转这种问题存在可能性,对我来说风险仍然太高。


十一、AdSense 每千次展示收入仍然大约是 0.4

这里还有一个需要单独记录的问题。

在使用 Adsterra 期间,我发现 Google AdSense 的每千次展示收入从此前大约:

Plaintext
0.7

下降到了:

Plaintext
0.4

当时我也怀疑过:

Adsterra 会不会在一定程度上影响了 AdSense 的表现?

例如影响页面体验、用户停留、广告可见率等。

不过到了 8 月 14 日,停用 Adsterra 已经 6 天以后,AdSense 每千次展示收入仍然大约维持在:

Plaintext
0.4

并没有明显恢复到以前大约 0.7 的水平。

因此,目前不能得出:

停用 Adsterra 后,AdSense 收入马上恢复。

同样也不能根据现在的数据反过来证明:

Adsterra 与 AdSense RPM 下降完全没有关系。

6 天时间仍然比较短,而且 AdSense 收益本身就会受到很多变量影响。

所以这一部分,我准备继续观察,而不是现在就下结论。


十二、6 天后的阶段性结论

现在回头看 8 月 8 日出现的这些问题,我目前得到的阶段性结论主要有三个。

1. 异常自动跳转和短信发送流程已经消失

这是目前最明确的变化。

停用 Adsterra Native Banner,并等待缓存自然淘汰以后,微信再次打开博客文章,没有再发生之前那种自动跳向陌生域名、最终进入短信发送界面的情况。

因此我目前仍然:

高度怀疑此前的异常跳转与 Adsterra 有关。

虽然我暂时没有办法从技术链路上做到百分之百取证,但从实际网站运营角度,这已经足以支持我继续停用 Adsterra。

2. 系统浏览器安全警告仍然存在,但暂时不能因此排除 Adsterra

这是目前还没有彻底解决的问题。

8 月 14 日重新测试时,系统浏览器仍然对网站发出风险警告,只是提示文字发生了一些变化。

我目前更倾向于认为两次提示可能属于同一类风险标记。

警告为什么还没有消失,目前有两种值得继续验证的可能:

  • 风险记录更新存在时间滞后;
  • 网站所有者可能需要主动申请复核或者解除风险标记。

所以这一项目前的准确状态应该是:

异常行为已经消失,但浏览器侧的风险记录可能还没有同步解除。

而不是简单判断:

Adsterra 与安全警告无关。

3. AdSense RPM 暂时没有恢复

停用 Adsterra 以后,AdSense 每千次展示收入仍然大约在 0.4 左右。

这意味着目前还无法判断它和 Adsterra 之间到底有没有关系。

这部分只能继续通过更长时间的数据来观察。


十三、这次经历让我重新认识第三方广告真正的成本

刚开始接入一个新广告平台时,最容易关注的问题通常只有一个:

它能带来多少额外收入?

但经过这次实际测试以后,我发现对于一个长期运营的网站来说,还有很多东西比短期广告收入更加重要:

  • 域名信誉;
  • 用户信任;
  • 页面稳定性;
  • 移动端访问体验;
  • 搜索和安全平台的风险评价;
  • 网站长期品牌形象。

特别是技术博客。

用户本来只是搜索一个技术问题,然后进入网站阅读文章。

如果打开页面以后却:

  • 被浏览器提示网站存在风险;
  • 被自动带到陌生域名;
  • 最后甚至进入短信发送页面;

那么无论真正的问题最终出在哪一层,访客只会记住:

这个网站不安全。

相比之下,这次 Adsterra 测试总共带来的 $2.60 收入,就显得非常微不足道了。


结语

这次事情从 8 月 8 日开始,到 8 月 14 日完成了第一次阶段性复测。

目前得到的结果可以概括为:

Plaintext
系统浏览器出现安全警告

进一步使用微信测试

发现异常自动跳转

甚至进入短信发送流程

停用全部 Adsterra Native Banner

不主动清缓存,等待自然过期

Adsterra Impressions 最终降至 0

微信异常跳转消失

短信发送流程消失

但系统浏览器安全警告仍然存在

AdSense RPM 仍约为 0.4

所以目前我最关注的已经不是:

Adsterra 还能赚多少钱?

而是:

如何让此前产生的浏览器安全警告彻底消失?

从目前整个时间线来看,我仍然严重怀疑 Adsterra 是这次问题的重要诱因。

尤其是停用以后,最严重的自动跳转现象已经不再出现。

至于系统浏览器的安全警告为什么还在,我准备继续观察一段时间,并进一步确认是否存在安全记录更新延迟,或者是否需要由网站所有者主动申请复核。

另外,最近明显下降的移动端流量,也值得和这些安全警告放在一起继续观察。

这次 Adsterra 的测试,到这里基本可以告一段落。

但网站安全警告的问题,还没有真正结束。

需要长期技术维护或远程问题排查?

我是拥有 15+ 年经验的 PHP / Go 后端工程师,长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况,可以先从一次小问题排查开始合作:

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看:关于我 & 合作

微信:13980074657
邮箱:shuijingwanwq@gmail.com
Telegram:@shuijingwan
GitHub:https://github.com/shuijingwan

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理