GFW 的原理#
要與 GFW 對抗不能僅僅停留在什麼不能訪問了，什麼可以訪問之類的表面現象上。知道 youtube 不能訪問了，對於翻牆來說並無幫助。但是知道 GFW 是如何讓我們不能訪問 youtube 的，則對下一步的翻牆方案的選擇和實施具有重大意義。所以在討論如何翻之前，先要深入原理了解 GFW 是如何封的。
總的來說，GFW 是一個分佈式的入侵檢測系統，並不是一個嚴格意義上的防火牆。不是說每個出入國境的 IP 包都需要先經過 GFW 的首可。作為一個入侵檢測系統，GFW 把你每一次訪問 facebook 都看做一次入侵，然後在檢測到入侵之後採取應對措施，也就是常見的連接重置。
檢測有兩種方式。一種是人工檢測，一種是機器檢測。你去國新辦網站舉報，就是參與了人工檢測。在人工檢測到不和諧的網站之後，就會採取一些應對方式來防止國內的網民訪問該網站。對於這類的封鎖，規避檢測就不是技術問題了，只能從 GFW 採取的應對方式上採取反制措施。另外一類檢測是機器檢測，其檢測過程又可以再進一步細分：
重建是指 GFW 從網絡上監聽過往的 IP 包，然後分析其中的 TCP 協議，最後重建出一個完整的字節流。分析是在這個重建的字節流上分析具體的應用協議，比如 HTTP 協議。然後在應用協議中查找是不是有不和諧的內容，然後決定採用何種應對方式。
所以，GFW 機器檢測的第一步就是重建出一個字節流。那么 GFW 是如何拿到原始的 IP 包的呢？真正的 GFW 部署方式，外人根本無從得知。据猜測，GFW 是部署在國家的出口路由器的旁路上，用 “分光” 的方式把 IP 包複製一份到另外一根光纖上，從而拿到所有進出國境的 IP 包。下圖引在 gfwrev.blogspot.com：
但是 Google 在北京有自己的機房。所以聰明的網友就使用 Google 的北京機房提供的 GAE 服務，用 Goagent 軟件達到高速翻牆的目的。但是有網友證實 https://twitter.com/chengr28/status/260970749190365184，即便是北京的機房也會被骨幹網丟包。事實上 Google 在北京的谷翔機房有一個獨立的 AS（BGP 的概念）。這個 AS 與谷歌總部有一條 IPV6 的直連線路，所以通過這個機房可以用 IPV6 不受牆的限制出去。但是這個 AS 無論是連接國內還是國外都是要經過 GFW 的。所以機房在北京也不能保證國內訪問不被牆。GFW 通過配置骨幹網的 BGP 路由規則，是可以讓國內的機房也經過它的。另外一個例子是當我們訪問被封網站觸發連接重置的時候，往往收到兩個 RST 包，但是 TTL 不同。還有一個例子是對於被封的 IP，訪問的 IP 包還沒有到達國際出口就已經被丟棄。所以 GFW 應該在其他地方也部署有設備，據推測是在省級骨幹路由的位置。
對於 GFW 到底在哪這個話題，最近又有國外友人表達了興趣 https://github.com/mothran/mongol。筆者在前人的基礎上寫了個更完備的探測工具 https://github.com/fqrouter/qiang。其原理是基於一個 IP 協議的特性叫 TTL。TTL 是 Time to Live 的簡寫。IP 包在沒經過一次路由的時候，路由器都會把 IP 包的 TTL 減去 1。如果 TTL 到零了，路由器就不會再把 IP 包發給下級路由。然後我們知道 GFW 會在監聽到不和諧的 IP 包之後發回 RST 包來重置 TCP 連接。那么通過設置不同的 TTL 就可以知道從你的電腦，到 GFW 之間經過了幾個路由器。比如說 TTL 設置成 9 不觸發 RST，但是 10 就觸發 RST，那么到 GFW 就是經過了 10 個路由器。另外一個 IP 協議的特性是當 TTL 耗尽的時候，路由器應該發回一個 TTL EXCEEDED 的 ICMP 包，並把自己的 IP 地址設置成 SRC（來源）。結合這兩點，就可以探測出 IP 包是到了 IP 地址為什麼的路由器之後才被 GFW 檢測到。有了 IP 地址之後，再結合 IP 地址地理位置的數據庫就可以知道其地理位置。據說，得出的位置大概是這樣：
但是這裡檢測出來的 IP 到底是 GFW 的還是骨幹路由器的？更有可能的是骨幹路由器的 IP。GFW 作為一個設備用 “分光” 的方式掛在主幹路由器旁邊做入侵檢測。無論如何，GFW 通過某種神奇的方式，可以拿到你和國外伺服器之間來往的所有的 IP 包，這點是肯定的。更嚴謹的理論研究有：Internet Censorship in China: Where Does the Filtering Occur?
GFW 在擁有了這些 IP 包之後，要做一個艱難的決定，那就是到底要不要讓你和伺服器之間的通信繼續下去。GFW 不能太過於激進，畢竟全國性的不能訪問國外的網站是違反 GFW 自身存在價值的。GFW 就需要在理解了 IP 包背後代表的含義之後，再來決定是不是可以安全的阻斷你和國外伺服器之間的連接。這種理解就要建立在前面說的 “重建” 這一步的基礎上。大概用圖表達一下重建是在怎麼一回事：
重建需要做的事情就是把 IP 包 1 中的 GET /inde 和 IP 包 2 中的 x.html H 和 IP 包 3 中的 TTP/1.1 拼到一起變成 GET /index.html HTTP/1.1。拼出來的數據可能是純文本的，也可能是二進制加密的協議內容。具體是什麼是你和伺服器之間約定好的。GFW 作為竊聽者需要猜測才知道你們之間的交談內容。對於 HTTP 協議就非常容易猜測了，因為 HTTP 的協議是標準化的，而且是未加密的。所以 GFW 可以在重建之後很容易的知道，你使用了 HTTP 協議，訪問的是什麼網站。
重建這樣的字節流有一個難點是如何處理巨大的流量？這個問題在這篇博客 http://gfwrev.blogspot.tw/2010/02/gfw.html 中已經講得很明白了。其原理與網站的負載均衡器一樣。對於給定的來源和目標，使用一個 HASH 算法取得一個節點值，然後把所有符合這個來源和目標的流量都往這個節點發。所以在一個節點上就可以重建一個 TCP 會話的單向字節流。
最後為了討論完整，再提兩點。雖然 GFW 的重建發生在旁路上是基於分光來實現的，但並不代表整個 GFW 的所有設備都在旁路。後面會提到有一些 GFW 應對形式必須是把一些 GFW 的設備部署在了主幹路由上，比如對 Google 的 HTTPS 的間歇性丟包，也就是 GFW 是要參與部分 IP 的路由工作的。另外一點是，重建是單向的 TCP 流，也就是 GFW 根本不在乎雙向的對話內容，它只根據監聽到的一個方向的內容然後做判斷。但是監聽本身是雙向的，也就是無論是從國內發到國外，還是從國外發到國內，都会被重建然後加以分析。所以一個 TCP 連接對於 GFW 來說會被重建成兩個字節流。具體的證據會在後面談如何直穿 GFW 中詳細講解。
分析#
分析是 GFW 在重建出字節流之後要做的第二步。對於重建來說，GFW 主要處理 IP 協議，以及上一層的 TCP 和 UDP 協議就可以了。但是對於分析來說，GFW 就需要理解各種各樣的應用層的稀奇古怪的協議了。甚至，我們也可以自己發明新的協議。
總的來說，GFW 做協議分析有兩個相似，但是不同的目的。第一個目的是防止不和諧內容的傳播，比如說使用 Google 搜索了 “不該” 搜索的關鍵字。第二個目的是防止使用翻牆工具繞過 GFW 的審查。下面列舉一些已知的 GFW 能夠處理的協議。
對於 GFW 具體是怎麼達到目的一，也就是防止不和諧內容傳播的就牽涉到對 HTTP 協議和 DNS 協議等幾個協議的明文審查。大體的做法是這樣的。
像 HTTP 這樣的協議會有非常明顯的特徵供檢測，所以第一步就沒什麼好說的了。當 GFW 發現了包是 HTTP 的包之後就會按照 HTTP 的協議規則拆包。這個拆包過程是 GFW 按照它對於協議的理解來做的。比如說，從 HTTP 的 GET 請求中取得請求的 URL。然後 GFW 拿到這個請求的 URL 去與關鍵字做匹配，比如查找 Twitter 是否在請求的 URL 中。為什麼有拆包這個過程？首先，拆包之後可以更精確的打擊，防止誤殺。另外可能預先做拆包，比全文匹配更節省資源。其次，xiaoxia 和 liruqi 同學的 jjproxy 的核心就是基於 GFW 的一個 HTTP 拆包的漏洞，當然這個 bug 已經被修復了。其原理就是 GFW 在拆解 HTTP 包的時候沒有處理有多出來的 \r\n 這樣的情況，但是你訪問的 google.com 卻可以正確處理額外的 \r\n 的情況。從這個例子中可以證明，GFW 還是先去理解協議，然後才做關鍵字匹配的。關鍵字匹配應該就是使用了一些高效的正則表達式算法，沒有什麼可以討論的。
HTTP 代理和 SOCKS 代理，這兩種明文的代理都可以被 GFW 識別。之前筆者認為 GFW 可以在識別到 HTTP 代理和 SOCKS 代理之後，再拆解其內部的 HTTP 協議的正文。也就是做兩次拆包。但是分析發現，HTTP 代理的關鍵字列表和 HTTP 的關鍵字列表是不一樣的，所以筆者現在認為 HTTP 代理協議和 SOCKS 代理協議是當作單獨的協議來處理的，并不是拆出載荷的 HTTP 請求再進行分析的。
目前已知的 GFW 會做的協議分析如下：
DNS 查詢#
GFW 可以分析 53 端口的 UDP 協議的 DNS 查詢。如果查詢的域名匹配關鍵字則會被 DNS 劫持。可以肯定的是，這個匹配過程使用的是類似正則的機制，而不僅僅是一個黑名單，因為子域名實在太多了。證據是：2012 年 11 月 9 日下午 3 點半開始，防火長城對 Google 的泛域名 .google.com 進行了大面積的污染，所有以 .google.com 結尾的域名均遭到污染而解析錯誤不能正常訪問，其中甚至包括不存在的域名（來源http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E5%8A%AB%E6%8C%81）
目前為止 53 端口之外的查詢也沒有被劫持。但是 TCP 的 DNS 查詢已經可以被 TCP RST 切斷了，表明了 GFW 具有這樣的能力，只是不屑於大規模部署。而且 TCP 查詢的關鍵字比 UDP 劫持的域名要少的多。目前只有 dl.dropbox.com 會觸發 TCP RST。相關的研究論文有：
Hold-On: Protecting Against On-Path DNS Poisoning
The Great DNS Wall of China
HTTP 請求#
GFW 可以識別出 HTTP 協議，並且檢查 GET 的 URL 與 HOST。如果匹配了關鍵字則會觸發 TCP RST 阻斷。前面提到了 jjproxy 使用的構造特殊的 HTTP GET 請求欺騙 GFW 的做法已經失效，現在 GFW 只要看到 \r\n 就直接 TCP RST 阻斷了（來源https://plus.google.com/u/0/108661470402896863593/posts/6U6Q492M3yY）。相關的研究論文有：
The Great Firewall Revealed
Ignoring the Great Firewall of China
ConceptDoppler: A Weather Tracker for Internet Censorship
對翻牆流量的分析識別#
GFW 的第二個目的是封殺翻牆軟件。為了達到這個目的 GFW 採取的手段更加暴力。原因簡單，對於 HTTP 協議的封殺如果做不好會影響互聯網的正常運作，GFW 與互聯網是共生的關係，它不會做威脅自己存在的事情。但是對於 TOR 這樣的幾乎純粹是為翻牆而存在的協議，只要檢測出來就是格殺勿論的了。GFW 具體是如何封殺各種翻牆協議的，我也不是很清楚，事態仍然在不斷更新中。但是舉兩個例子來證明 GFW 的高超技術。
第一個例子是 GFW 對 TOR 的自動封殺，體現了 GFW 盡最大努力去理解協議本身。根據這篇博客 https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors。使用中國的 IP 去連接一個美國的 TOR 網橋，會被 GFW 發現。然後 GFW 回頭（15 分鐘之後）會親自假裝成客戶端，用 TOR 的協議去連接那個網橋。如果確認是 TOR 的網橋，則會封當時的那個端口。換了端口之後，可以用一段時間，然後又會被封。這表現出了 GFW 對於協議的高超檢測能力，可以從國際出口的流量中敏銳地發現你連接的 TOR 網橋。據 TOR 的同志說是因為 TOR 協議中的握手過程具有太明顯的特徵了。另外一點就表現了 GFW 的不辭辛勞，居然會自己偽裝成客戶端過去連連看。
第二個例子表現了 GFW 根本不在乎加密的流量中的具體內容是不是有敏感詞。只要疑似翻牆，特別是提供商業服務給多個翻牆，就會被封殺。根據這個帖子 http://www.v2ex.com/t/55531，使用的 ShadowSocks 協議。預先部署密鑰，沒有明顯的握手過程仍然被封。據說是 GFW 已經升級為能夠機器識別出哪些加密的流量是疑似翻牆服務的。
關於 GFW 是如何識別與封鎖翻牆伺服器的，最近寫了一篇文章提出我的猜想，大家可以去看看：http://fqrouter.tumblr.com/post/45969604783/gfw。
最近發現 GFW 對 OpenVPN 和 SSL 證書已經可以做到準實時的封 IP（端口）。原理應該是離線做的深包分析，然後提取出可疑的 IP 列表，經過人工確認之後封 IP。因為 OpenVPN 有顯著的協議的特徵，而且基本不用于商業場景所以很容易確認是翻牆服務。但是 SSL 也就是 HTTPS 用的加密協議也能基於 “證書” 做過濾不得不令人感到敬畏了。Shadowsocks 的作者 Clowwindy 為此專門撰文 “為什麼不應該用 SSL 翻牆 “：https://gist.github.com/clowwindy/5947691。
總結起來就是，GFW 已經基本上完成了目的一的所有工作。明文的協議從 HTTP 到 SMTP 都可以分析然後關鍵字檢測，甚至電驴這樣不是那麼大眾的協議 GFW 都去搞了。從原理上來說也沒有什麼好研究的，就是明文，拆包，關鍵字。GFW 顯然近期的工作重心在分析網絡流量上，從中識別出哪些是翻牆的流量。這方面的研究還比較少，而且一個顯著的特徵是自己用沒關係，大規模部署就容易出問題。我目前沒有在 GFW 是如何封翻牆工具上有太多研究，只能是道聽途說了。
措施#
封 IP#
一般常見於人工檢測之後的應對。還沒有聽說有什麼方式可以直接使得 GFW 的機器檢測直接封 IP。一般常見的現象是 GFW 機器檢測，然後用 TCP RST 重置來應對。過了一段時間才會被封 IP，而且沒有明顯的時間規律。所以我的推測是，全局性的封 IP 應該是一種需要人工介入的。注意我強調了全局性的封 IP，與之相對的是部分封 IP，比如只對你訪問那個 IP 封個 3 分鐘，但是別人還是可以訪問這樣的。這是一種完全不同的封鎖方式，雖然現象差不多，都是 ping 也 ping 不通。要觀摩的話 ping twitter.com 就可以了，都封了好久了。
其實現方式是把無效的路由黑洞加入到主幹路由器的路由表中，然後讓這些主幹網上的路由器去幫 GFW 把到指定 IP 的包給丟棄掉。路由器的路由表是動態更新的，使用的協議是 BGP 協議。GFW 只需要維護一個被封的 IP 列表，然後用 BGP 協議廣播出去就好了。然後國內主幹網上的路由器都好像變成了 GFW 的一份子那樣，成為了幫兇。
如果我們使用 traceroute 去檢查這種被全局封鎖的 IP 就可以發現，IP 包還沒有到 GFW 所在的國際出口就已經被電信或者聯通的路由器給丟棄了。這就是 BGP 廣播的作用了。
DNS 劫持#
這也是一種常見的人工檢測之後的應對。人工發現一個不和諧網站，然後就把這個網站的域名給加到劫持列表中。其原理是基於 DNS 與 IP 協議的弱點，DNS 與 IP 這兩個協議都不驗證伺服器的權威性，而且 DNS 客戶端會盲目地相信第一個收到的答案。所以你去查詢 facebook.com 的話，GFW 只要在正確的答案被返回之前搶答了，然後偽裝成你查詢的 DNS 伺服器向你發錯誤的答案就可以了。
TCP RST 阻斷#
TCP 協議規定，只要看到 RST 包，連接立馬被中斷。從瀏覽器裡來看就是連接已經被重置。我想對於這個錯誤大家都不陌生。據我個人觀感，這種封鎖方式是 GFW 目前的主要應對手段。大部分的 RST 是條件觸發的，比如 URL 中包含某些關鍵字。目前享受這種待遇的網站就多得去了，著名的有 facebook。還有一些網站，會被無條件 RST。也就是針對特定的 IP 和端口，無論包的內容就會觸發 RST。比較著名的例子是 https 的 wikipedia。GFW 在 TCP 層的應對是利用了 IPv4 協議的弱點，也就是只要你在網絡上，就假裝成任何人發包。所以 GFW 可以很輕易地讓你相信 RST 確實是 Google 發的，而讓 Google 相信 RST 是你發的。
封端口#
GFW 除了自身主體是掛在骨幹路由器旁路上的入侵檢測設備，利用分光技術從這個骨幹路由器抓包下來做入侵檢測 (所謂 IDS)，除此之外這個路由器還會被用來封端口 (所謂 IPS)。GFW 在檢測到入侵之後可以不僅僅可以用 TCP RST 阻斷當前這個連接，而且利用骨幹路由器還可以對指定的 IP 或者端口進行從封端口到封 IP，設置選擇性丟包的各種封禁措施。可以理解為骨幹路由器上具有了類似 “iptables” 的能力（網絡層和傳輸層的實時拆包，匹配規則的能力）。這個 iptables 的能力在 CISCO 路由器上叫做 ACL Based Forwarding (ABF)。而且規則的部署是全國同步的，一台路由器封了你的端口，全國的掛了 GFW 的骨幹路由器都會封。一般這種封端口都是針對翻牆伺服器的，如果檢測到伺服器是用 SSH 或者 VPN 等方式提供翻牆服務。GFW 會在全國的出口骨幹路由上部署這樣的一條 ACL 規則，來封你這個伺服器 + 端口的下行數據包。也就是如果包是從國外發向國內的，而且 src（源 ip）是被封的伺服器 ip，sport（源端口）是被封的端口，那麼這個包就會被過濾掉。這樣部署的規則的特點是，上行的數據包是可以被伺服器收到的，而下行的數據包會被過濾掉。
如果被封端口之後伺服器採取更換端口的應對措施，很快會再次被封。而且多次嘗試之後會被封 IP。初步推斷是，封端口不是 GFW 的自動應對行為，而是採取黑名單加人工過濾的方式實現的。一個推斷的理由就是網友報導，封端口都是發生在白天工作時間。
反向牆#
大部分機場使用的國內中轉伺服器，GFW 檢測到了十分異常的境外大流量，就會在特殊時期，如兩會和國慶期間，將該伺服器反向牆。具體表現為國外的伺服器無法訪問該被反向牆了的 IP。測該國內伺服器的 ping 就是國外一片紅，國內一片綠。解決方法不多，要麼更換 IP，或者等敏感時期過去，自動恢復。
翻牆原理#
前面從原理上講解了 GFW 的運作原理。翻牆的原理與之相對應，分為兩大類。第一類是大家普遍的使用的繞道的方式。IP 包經由第三方中轉已加密的形式通過 GFW 的檢查。這樣的一種做法更像 “翻” 牆，是從牆外繞過去的。第二類是找出 GFW 檢測過程中的一些 BUG，利用這些 BUG 讓 GFW 無法知道準確的會話內容從而放行。
基於繞道法的翻牆方式無論是 VPN 還是 SOCKS 代理，原理都是類似的。都是以國外有一個代理伺服器為前提，然後你與代理伺服器通信，代理伺服器再與目標伺服器通信。
除了基本的 http L2TP sock5 等代理協議外，現在主流的翻牆訪問境外網站的協議均為 ss,vmess,ssr,vless,trojan,kcp,hysteria 等。
協議（直連）#
Shadowsocks#
shadowsocks（ss）是一種基於 sock5 代理方式的加密傳輸協議。初代版本發布於 2012 年 4 月 20 日。Shadowsocks 使用自行設計的協定進行加密通信。加密演算法有 AES、Blowfish、ChaCha20、RC4 等，除建立 TCP 連接外無需握手，每次請求只轉發一個連接，無需保持一直連線的狀態，因此在流動裝置上相對較為省電。
現如今的該協議的現狀是被 GFW 檢測並且可以接著封禁，包括但不限於阻斷、封端口、封 IP 等。所以如果是直連 SS 的話，基本就是頭鐵硬剛了。
因為其低延遲的原因，仍是眾多主流機場的選擇。（機場都使用中轉，並非 ss 直連，所以封禁對其並無影響）
支持軟件#
其附帶的衍生軟件，shadowsocks 和 shadowsocksr 已基本被淘汰。
clash/v2rayn/v2rayng/shadowrocket/quantumultx 等主流軟件都兼容該協議
shadowsocksr#
可以說 shadowsocksr（ssr / 酸酸乳）是 ss 的升級版。SSR 是網名為 breakwa11 的用戶發起的 Shadowsocks 分支，在 Shadowsocks 的基礎上增加了一些資料混淆方式，稱修復了部分安全問題並可以提高 QoS 優先級。後來貢獻者 Librehat 也為 Shadowsocks 補上了一些此類特性，甚至增加了類似 Tor 的可插拔傳輸層功能。
支持軟件#
其附帶的衍生軟件，shadowsocks 和 shadowsocksr 已基本被淘汰。
clash/v2rayn/v2rayng/shadowrocket/quantumultx 等主流軟件都兼容該協議
VMess#
VMess 是一個基於 TCP 的加密傳輸協議，所有數據使用 TCP 傳輸。它分為入站和出站兩部分，通常作為 V2Ray 客戶端和伺服器之間的橋梁。基於 v2ray 內核。
VMess 依賴於系統時間，請確保使用 V2Ray 的系統 UTC 時間誤差在 90 秒之內，時區無關。在 Linux 系統中可以安裝 ntp 服務來自動同步系統時間。
因為其加密性，現在也是主流加密協議之一。搭建直連節點時主要使用 vmess + websocket + tls + nginx偽裝 協議，這樣理論上是最不容易被牆的協議之一。
vmess 協議的主要特點就是嚴加密，但是隨之而來的問題也很明顯，握手次數多了，相較於 ss/ssr，延遲自然也是提高了很多。但是其速度方面是比 ss/ssr 要快的（經測試，同伺服器 ss 和 vmess+ws 的速度比較得出，YouTube 也有測速比較視頻）。
支持軟件#
其附帶的衍生軟件，v2rayn/v2rayng 依舊十分常用，現均默認使用 xray-core。
clash/v2rayn/v2rayng/shadowrocket/quantumultx 等主流軟件都兼容該協議
Vless#
vless 也可以說是 vmess 的升級版，基於 xray 內核。VLESS 是一個無狀態的輕量傳輸協議，它分為入站和出站兩部分，可以作為 V2Ray 客戶端和伺服器之間的橋梁。與 VMess 不同，VLESS 不依賴於系統時間，認證方式同樣為 UUID，但不需要 alterId。
相較於 vmess，vless 的協議速度更快，延遲方面相差不多。
支持軟件#
vless 需要使用 xray-core 才能運行。
v2rayn/v2rayng/shadowrocket/quantumultx 等主流軟件兼容該協議。clash 很遺憾並不支持。
trojan#
與 Shadowsocks 相反，Trojan 不使用自定義的加密協議來隱藏自身。相反，使用特徵明顯的 TLS 協議 (TLS/SSL)，使得流量看起來與正常的 HTTPS 網站相同。TLS 是一個成熟的加密體系，HTTPS 即使用 TLS 承載 HTTP 流量。使用正確配置的加密 TLS 隧道，可以保證傳輸的
Trojan 不同於 vmess，可以自定是否加上 tls 加密，trojan 是強制使用 tls 加密的。也就是說 trojan 必須需要域名才能搭建。
速度方面，trojan 和 vmess 相差不多。但是 trojan 最大的優點就是對於伺服器端的佔用很小，十分的輕量，即使低配伺服器也能跑得很爽。
支持軟件#
clash/v2rayn/v2rayng/shadowrocket/quantumultx 等主流軟件兼容該協議。
Hysteria#
Hysteria 是一個功能豐富的，專為惡劣網絡環境進行優化的網絡工具（雙邊加速），比如衛星網絡、擁擠的公共 Wi-Fi、在中國連接國外伺服器等。基於修改版的 QUIC 協議。
Hysteria 這是一款由 go 編寫的非常優秀的 “輕量” 代理程序，它很好地解決了在搭建富強魔法伺服器時最大的痛點 —— 線路拉跨。
在魔法咏唱時最難的不是搭建維護，而是在晚高峰時期的交付質量。當三大運營商晚高變成了：奠信、連不通、移不動時，你我都有感觸。雖然是走的 udp 但是提供 obfs，暫時不會被運營商針對性的 QoS (不开 obfs 也不会被 QoS)。
這是最近十分火的新協議。主要優點就是即使線路不佳，也不用中轉或者 CF CDN，使用 hysteria 即可拯救。目前來看對於非國內優化線路還是十分友好的。
支持軟件#
v2rayn/shadowrocket 最新版已支持 hysteria
中轉#
說完了直連，那麼再說說中轉吧。
中轉主要是分為三種，一種就是國內大帶寬伺服器直接中轉。主要優點就是相較於直連，可以更好的符合國內複雜的運營商網絡情況。確定也很明顯，對於國外被牆的 IP 束手無策，也怕反向牆，而且並非一個國內伺服器就能拉得動所有國外伺服器。有的國外伺服器聯通友好的，用電信的伺服器去拉，很有可能就會很拉跨。
第二種就是隧道中轉，這也是近幾年才有的新的中轉方式。隧道中轉即一個國內伺服器一個國外伺服器。因為國外伺服器一般有 BGP session，對於複雜的網絡情況都可以比較好的應對，隧道的國外端到你的節點伺服器普遍線路會比較友好。而隧道國外端到國內端又會經過加密，這樣雖然也會略微增加延遲，但是可以無視國外機器被牆的情況。但是國內伺服器也會怕反向牆。使用隧道的話，基本一個隧道節點就能拉得動大部分的國外伺服器。
第三種就是專線中轉，也是最昂貴的。一條 G 口專線一個月基本 2.5w+ rmb，不是有錢的機場用不起的。其實專線和隧道比較類似，同樣也是分國內端和國外端。專線分為 IEPL 和 IPLC，對於這俩的定義可以參考 https://www.cheshirex.com/2005.html。專線最大的優點，就是延遲低，穩定，不過牆，所以也不用擔心節點伺服器被牆或者國內反向牆的問題，可以說除了機房的日常維護等特殊情況下，專線是基本永不掉線的。也正是因為這點備受青睞。
自建#
很多小白想要自己搭建節點，但是發現搭建完了以後不是斷流就是接著被牆了。在這裡統一推薦，使用 vmess+ws+tls+nginx偽裝 或者 vless+ws+tls+nginx偽裝 的搭建方式是比較合理的（沒有中轉的直連情況下）。對於動態 IP 的伺服器來說，使用 vmess+ws 即可，保證速度的同時也不會被阻斷。對於辣雞線路的小雞，可以使用 hysteria。
小結#
和 GFW 的鬥智鬥勇還在繼續～～～
轉載編輯補充自 http://www.oneyearago.me
https://cloud.tencent.com/developer/article/1740977