本来 SS SSR 用的用的高高兴兴，结果从今年初开始，很多人反应 SS SSR 代理账号被封了，更换IP后又是很快GG，导致很多人纷纷逃离 SS SSR，转向 V2ray Brook 等代理软件了。
但同样，也有很多人反应一直相安无事没有被墙，我简单研究了下，大概和以下几点有关：
代理服务器地区(日本、美国等热门地区)
滥用、乱用、无脑用SS SSR的混淆
目录
代理服务器地区(日本、美国等热门地区)
经过我的观察(包括我自身情况)，大概可以得出：日本、美国热门地区的服务器被墙几率高于其他地区。正因为这些热门地区搭建代理的人多，所以GFW会重点关注这些地区，导致被墙几率相比其它地区会更高。
另外说一说我自身情况。
我手里有一些这几年买的自用服务器，一直以来搭建的都是 SSR，香港、日本、美国、欧洲、俄罗斯地区都有。
在今年之前，也就是 GFW1.0 的时候，都是敏感时期一波一波的封，偶尔可能会封我各香港、日本、美国的服务器，但是欧洲和俄罗斯的毛事没有。但是今年之后，日本和美国的服务器是遭了殃，频繁被墙，换IP也顶不了多长时间，最后只能无奈放弃日本、美国服务器了。不过很奇怪的是，我的香港服务器今年开始就一次都没有被墙过，很迷。而欧洲和俄罗斯这些相对冷门的地区依然是毛事没有。
再说说我分享的免费账号，今年之前，无论是美国还是加拿大的服务器都是一波一波的偶尔就会被墙一次，但是今年之后，美国服务器也是如上所述遭了殃，我陆续更换了很多美国地区都没什么卵用（目前都换到了欧洲），然而是加拿大的服务器今年开始一次都没有被墙过(和我自用的香港似的)，很迷。
综上所述，如果你使用某个地区的服务器频繁被墙，那么你 要么更换代理软件，要么就换其他地区试试，否则只能继续GG。
滥用、乱用、无脑用SS SSR的混淆
SS SSR都有混淆功能，不过我今天主要说 SSR，SS 用户可以参考下，而很多SSR脚本(包括我的脚本)默认的混淆参数都是 tls1.2_ticket_auth（前段时间两个脚本都改成默认 plain 了），而经过我的简单研究发现：只使用HTTP或HTTPS混淆的代理服务器被墙几率更高。
首先，无论是 SS 还是 SSR 的混淆，都属于伪混淆，即代理客户端将访问代理服务器的流量伪装成访问 HTTP HTTPS 网页的流量，但是如果你没有做真实网站(SSR 服务端的 redirect 参数)，那么这都是有可能被主动探测识破的。
SSR 的HTTP HTTPS混淆一开始的目的是针对那些被限速的地区(例如学校、公司)，混淆伪装为 HTTP HTTPS 即可避开限速。后来 HTTP HTTPS混淆就更偏向于让 GFW 难以发现(服务端 redirect 参数)，不过很多人依然是只选择 HTTP HTTPS 混淆插件，混淆参数也不填，服务端 redirect 参数也不做，端口也不是 80 443。
这样在外界看来，你的流量就是在访问 :4567 一样，看起来就很奇怪。
有的人可能还会填个混淆参数，不过填写的混淆域名也是各种逗比，有什么 bing.com 、www.icloud.com 之类的。。。我就很纳闷了，首先这种单纯混淆伪装的方式是没有真实域名解析的，即互联网中根本没有该域名解析为你的服务器IP的解析记录。其次你用个 Vultr 、搬瓦工，混淆个 微软、苹果 的域名，难道微软和苹果都已经差钱到只能买 Vultr、搬瓦工这等级的服务器维生了么？这也太假了吧，就不能站在 GFW 的角度想一想。。。
但是，就算你选个没毛病的域名来混淆伪装，结果被 GFW 一波主动探测识破根本没有网站，那岂不是直接明白你在用 SS 或 SSR 了吗？
综上所述，要么你搭配服务端的 redirect 参数做个真实网站，要么就干脆用原版混淆插件（ plain ）。
总结一下
首先 SSR 目前依然是可以正常使用的，不过在热门地区（日本、美国等）被墙几率会高一些。
很多人都是默认只用 HTTP HTTPS 混淆插件 ，或者再写个混淆参数 ，但是这样属于伪混淆 ，仅仅是将流量伪装成 HTTP HTTPS 流量，并没有真实网站，所以可以被主动探测识破。
因此，在热门地区（日本、美国等）搭建 SSR 代理的，建议要么搭配服务端的 redirect 参数做个真实网站（只能降低被墙记录，不能保证不被墙），要么就干脆用原版混淆插件（ plain ）。
毕竟，对于可以被主动探测的伪混淆，不做混淆反而被墙几率更低，只靠协议来降低流量特征减少被墙几率。