给目前正在使用 SSR 代理翻墙的人一点点建议(混淆方面)

经过我的观察(包括我自身情况)，大概可以得出：日本、美国热门地区的服务器被墙几率高于其他地区。

我也在 Telegram 做过一个两千人参与的哪些地区被墙次数最多的投票(仅供参考，不要杠)，结果香港、日本、美国加起来占了 86%，而美国就占了 48%，差不多一半。

或许有人会说什么基数，的确这种小规模投票不能代表所有人，但是我这个投票是选择你手里被墙次数最多的地区，这意味着如果一个人选择了美国，那么代表他的美国服务器被墙次数高于他手里的其他地区代理服务器。这不是什么大数据统计，但也能反映一些问题。至少比个人经验、看脸论强一些。

正因为这些热门地区搭建代理的人多，所以GFW会重点关注这些地区，导致被墙几率相比其它地区会更高。

另外说一说我自身情况。

我手里有一些这几年买的自用服务器，一直以来搭建的都是 SSR，香港、日本、美国、欧洲、俄罗斯地区都有。

在今年之前，也就是 GFW1.0 的时候，都是敏感时期一波一波的封，偶尔可能会封我各香港、日本、美国的服务器，但是欧洲和俄罗斯的毛事没有。但是今年之后，日本和美国的服务器是遭了殃，频繁被墙，换IP也顶不了多长时间，最后只能无奈放弃日本、美国服务器了。不过很奇怪的是，我的香港服务器今年开始就一次都没有被墙过，很迷。而欧洲和俄罗斯这些相对冷门的地区依然是毛事没有。

再说说我分享的免费账号，今年之前，无论是美国还是加拿大的服务器都是一波一波的偶尔就会被墙一次，但是今年之后，美国服务器也是如上所述遭了殃，我陆续更换了很多美国地区都没什么卵用（目前都换到了欧洲），然而是加拿大的服务器今年开始一次都没有被墙过(和我自用的香港似的)，很迷。

综上所述，如果你使用某个地区的服务器频繁被墙，那么你 要么更换代理软件，要么就换其他地区试试，否则只能继续送人头了。

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。

这样在外界看来，你的流量就是在访问 http://ip:4567 一样，看起来就很奇怪。

有的人可能还会填个混淆参数，不过填写的混淆域名也是各种逗比，有什么 bing.com 、www.icloud.com 之类的。。。我就很纳闷了，首先这种单纯混淆伪装的方式是没有真实域名解析的，即互联网中根本没有该域名解析为你的服务器IP的解析记录。其次你用个 Vultr 、搬瓦工，混淆个 微软、苹果 的域名，难道微软和苹果都已经差钱到只能买 Vultr、搬瓦工这等级的服务器维生了么？这也太假了吧，就不能站在 GFW 的角度想一想。。。

但是，就算你选个没毛病的域名来混淆伪装，结果被 GFW 一波主动探测识破根本没有网站，那岂不是直接明白你在用 SS 或 SSR 了吗？

综上所述，要么你搭配服务端的 redirect 参数做个真实网站，要么就干脆用原版混淆插件（ plain ）。