作为比较早加入Google+的人士，一直有研究防火长城对Google+的封锁方式，这也是对自己网络技术一个很好的锻炼机会 =w=
- Google+刚刚发布，也就是正在内测的时候，防火长城就已经率先下手：
错误101 (net::ERR_CONNECTION_RESET): 连接已重置
这是Chrome浏览器返回的错误信息，很明显，因为Google+强制使用TLS/SSL加密连接，就算用户使用普通连接也会被跳转到加密连接，这样做变相等于封死了Google+的访问。
对于技术，也就是服务器的IP地址同时在443端口上进行TCP传输层面的连接重置，也就是刚开始的状况。
- Google+正式开放注册的2011年9月21日时，封锁方式又发生了变化，当时访问Google+会获得如下错误信息：
错误 118 (net::ERR_CONNECTION_TIMED_OUT)：操作超时。
显然，此时无法正常访问的原因是数据包无法到达目标服务器，而与此同时访问普通连接却能正常跳转到加密连接，如此可看出这时服务器的443端口被丢包封锁了，也就是TLS/SSL加密连接必须使用的端口，这也变相等于阻断了加密连接。
说了这么多都是以前的信息，我也知道现在绝大多数人的观点也只停留在上面服务器443端口被封的阶段。但事实上，情况早已有所变化：
现在访问Google+获得的错误消息也还是：
错误 118 (net::ERR_CONNECTION_TIMED_OUT)：操作超时。
但事实却没这么简单。大家可以看一下这幅图：
你可能会说：这幅图能说明什么？
这幅截图能告诉我们的信息实在是太多了！
Windows下的命令是 nslookup flweihjgoiwplus.google.com 8.8.8.8
作用是向 8.8.8.8 这个地址发送DNS查询域名 flweihjgoiwplus.google.com
问题就出在这里：flweihjgoiwplus.google.com 根本就是不存在的子域名（Google也从来没有做过泛域名），怎么会有解析结果呢？这里大家可以参考维基百科上域名服务器缓存污染的条目：
在中国大陆，对于所有经过防火长城的在UDP的53端口上的域名查询进行IDS入侵检测，一经发现与黑名单关键词相匹配的域名查询请求，其会马上伪装成目标域名的解析服务器给查询者返回虚假结果。由于通常的域名查询没有任何认证机制，而且域名查询通常基于的UDP协议是无连接不可靠的协议，查询者只能接受最先到达的格式正确结果，并丢弃之后的结果。
显然，这就是防火长城发过来的虚假解析包。于为什么发过来的虚假解析包里的IP地址属于Google？这个大家可以向有关部门咨询。
而现在我知道的是，这两个IP地址的443端口被封了，所以事实上请求解析被投毒污染到这些IP地址上，等于无法正常访问，而因为IP地址是Google的，所以不明就里相信表面现象而得出的结果，大概也是人之常情了。
from iGFW http://igfw.net/archives/12519
