准备把之前用的一套(山寨)cdn用到博客和其他一堆乱七八糟的站上面，用了yoooo.us(4个o)来做cname。主要现在的yooooo.us还依赖cloudflare的服务没法搬，所以另外注册了一个放到cloudxns上根据运营商区分解析。现在电信走的是idcf；联通移动和港澳台小伙伴是vultr日本；国外是cc的lax。韩国kt用来做冗余。
所以对于你们来说，每次打开我的博客的时候，可以至少省一个字节的流量了。
使用非443端口转发https流量扶墙（二）
使用非443端口转发https流量扶墙（一）
试试看见光了多久死hhhhhh
原理
实验表明，我国自主研发的高科技防火墙型网络设备（以下简称GFW）具有以下特征：
- 对所有目标端口上的流量存在字符串过滤，如HTTP和明文的邮件消息
- 对443端口存在主动探测或举报机制（具体情况不明），表现为具有包括Google、Twitter等的CN在内的证书的ip会在半个月后被墙
- 目前，GFW对非443端口上流经的HTTPS流量不存在第2条所述的措施
注：也可以是用SNI Proxy来隐藏证书，主动探测一般情况下不会使用SNI扩展来探测443端口的证书。可以使用这篇博客中提到的项目lua_resty_sniproxy。
GFW6使用心得 一
最近一直在使用gfw6，感觉不错。
试着做如下黑箱分析：
- 阻断ipv6反向代理地址的工作方式：阻断地址通过计算获得：RFC 6147中指出，dns64反向代理服务器返回的ip由服务器决定，“一般情况下，返回一个带ipv6固定前缀的地址”；现在看来大部分dns64服务器都是按照“一般情况”，GFW6只要将所有ipv6请求目标地址和源地址某两个块（一般为最后两个块）倒推成ipv4地址，即可选择性地发送RST包。如此土豪的方式，果然是一坨曙光计算机撑腰的大项目啊（笑）。
- 阻断固定ipv6地址的工作方式：和以前ipv4的时候是一样的，RST攻击。
- 开始污染DNS64解析感觉这个没啥作用
- 有两点值得注意：对反向代理，似乎只对请求方发送RST包；https连接没有被RST。
