前言

这几日,由于遭到他人的恶意投诉举报,导致了微信中阅读业务的根域名被屏蔽,提示如图

由于我司是做网络文学的,作者的内容中不可避免地会出现些微露骨的内容,但是这些内容是经过了编辑审核之后才公开的,也不至于太露骨,但举报就被封禁了。

公司的用户有很多是通过微信公众号进行阅读,这一封,就许多用户过来反馈了。

切换域名之痛

既然根域名被封了,就只能切换域名了,因为之前代码中有不少的地方域名写死了,没有提取成公共变量,改了好久,才替换成了新的域名。

眼看已经修改完了,线上也正常了,都已经晚上9点多,准备下班回家了。就这时候,群里又反馈网站进不去了,打开一开,又**被封了,当时的心情真是想问候一下恶意举报人的全家了!

没法子,继续换域名,还好之前提前备案了几个域名,没想到现在全用上了。

有了上一次的经验,现在修改起来也快多了,修改上线完事都已经 10 点多了,恶意举报的人这时候也消停了下来没有继续投诉了,我们也终于可以下班,害的我们大周六的过来加了一天的班!

第二天,也就是周日。群里又反应被封了,真是崩溃。
最开始的域名被微信封禁后,公司第一时间进行了申诉,此时收到通知,说检测后没有违规内容,就进行了解封。
可能是别人恶意利用了微信的封禁系统,此时觉得微信的这套系统做的真烂!于是我们开发人员又是一番替换,把现在被封的域名切换了回去。

经过这几波操作,这两天网站的收入骤减,那帮使坏的人是趁你病要你命的节奏!

痛定思过

总结了一下这次事件的教训,主要的原因就是因为小说的内容页被频繁恶意举报导致域名被封。 这就导致了即使换了域名,比如支付,登录都受到了影响,而且微信支付限制了每个月修改支付域名的次数,不得已我们只好换了另外一个服务号才重新打通了支付。

接下来需要做的就是,将可能还会被举报的小说内容页的域名拆分出去,不和网站主要域名一样。

比如首页、个人中心是 m.aaa.com, 将内容页的域名修改成 m.bbb.com

我们的阅读页 URL 地址为 https://m.aaa.com/book/1010545066/385773672,则在 nginx 匹配到 ^/book/([0-9]+)/([0-9]+) 就进行跳转到 http://m.bbb.com/book/1010545066/385773672,于是,修改 nginx 的配置,对 URL 进行匹配。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
server {
listen 443;
server_name m.aaa.com;

# ...
set $temp_content_host "http://m.bbb.com";
location ~ ^/book/([0-9]+)/([0-9]+) {
# If WeChat browser, jump to temporary domain name
if ($http_user_agent ~* (Micromessenger) ) {
return 301 $temp_content_host$request_uri;
}
proxy_pass http://domainAserver;
}

location / {
proxy_pass http://domainAserver;
}
}

server {
listen 80;
server_name m.bbb.com;

# ...

location / {
proxy_pass http://domainAserver;
}
}

因为只有在微信浏览器内部,才存在被封禁的风险,而在其他浏览器内没有,一旦被微信封禁,内容页的域名需要一起更换,这样可能会不利于搜索引擎的收录,因此加了一个判断
浏览器 UA,微信的 UA 是 Micromessenger 如果是在微信浏览器内部,nginx 才 301 跳转到 m.bbb.com,如果不是,则保持之前的域名不变。

这样就解决了问题,一旦 m.bbb.com 域名被封禁了,就是 aaa 域名的 nginx 修改 $temp_content_host 这个变量的值为新的域名然后 reload 一下 nginx 即可。

总结

可能是公司战略上的问题,太过于依赖微信的公众号,在微信的生态中,微信想弄死你轻而易举,你却无可奈何,尽量把用户引导到客户端上才是上上策。

参考