準備把之前用的一套(山寨)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。
