前言

2022年了，隨著墻越來(lái)越高，以及部分運(yùn)營(yíng)商的墻中墻封鎖，不僅Steam社區(qū)無(wú)法正常訪問(wèn)，就連商店也時(shí)不時(shí)抽風(fēng)。
ASF的運(yùn)行需要訪問(wèn)Steam社區(qū)檢查游戲和掉卡情況，需要特殊手段才能訪問(wèn)到steam社區(qū)茍活。
好在Steam社區(qū)只是普通的封鎖，并不是實(shí)質(zhì)意義上的“墻”，實(shí)現(xiàn)訪問(wèn)。
筆者根據(jù)自己的實(shí)際例子介紹阻斷方式和解決方法，以及自己在部署時(shí)用到的ASF本地反代和https安全部署，希望有遇到同樣問(wèn)題的朋友可以有所幫助。
文章可能會(huì)有不嚴(yán)謹(jǐn)?shù)腻e(cuò)誤，請(qǐng)大家積極指出，我也會(huì)盡量完善。

縮寫(xiě)術(shù)語(yǔ)ASF（ArchiSteamFarm）

目前最主流的Steam掛卡程序，代碼完全開(kāi)源，不必?fù)?dān)心留有后門(mén)，可以在多個(gè)平臺(tái)上運(yùn)行，現(xiàn)已有中文WIKI。本文主要記錄在Ubuntu(Linux)服務(wù)器上的部署教程。但對(duì)于沒(méi)有用過(guò)ASF并不熟悉Nginx的萌新來(lái)說(shuō)，還是建議在Windows上調(diào)試成功后再轉(zhuǎn)到云服務(wù)器上。

HTTP（Hyper Text Transfer Protocol）

超文本傳輸協(xié)議，日常瀏覽的各種網(wǎng)頁(yè)都是通過(guò)HTTP協(xié)議傳輸，但是它的傳輸過(guò)程沒(méi)有加密，不安全，所以被HTTPS替代。
目前市面上所說(shuō)的支持HTTP一般是指HTTP和HTTPS功能都可以實(shí)現(xiàn)，而不是只支持HTTP。

TLS（Transport Layer Security）

安全傳輸層，它的前身是SSL，它實(shí)現(xiàn)了將報(bào)文加密后再交由TCP進(jìn)行傳輸?shù)墓δ?。即HTTP + TLS = HTTPS

SNI（Server Name Indication）

服務(wù)器名稱(chēng)指示，簡(jiǎn)單來(lái)說(shuō)，是用于在一臺(tái)服務(wù)器的相同端口上部署不同證書(shū)的方法。服務(wù)器根據(jù)收到請(qǐng)求中的SNI域名來(lái)處理相應(yīng)的請(qǐng)求，如果SNI域名為空，會(huì)按照預(yù)先設(shè)置好的默認(rèn)域名處理請(qǐng)求。

CDN（Content Delivery Network）

內(nèi)容分發(fā)網(wǎng)絡(luò)，各個(gè)地區(qū)部署的服務(wù)器在一起形成的高速網(wǎng)絡(luò)拓?fù)洌脩粼诿總€(gè)地區(qū)都能實(shí)現(xiàn)快速訪問(wèn)。CDN通過(guò)SNI響應(yīng)不同的網(wǎng)站，同時(shí)也保護(hù)根服務(wù)器的安全。

Nginx

主流的高性能開(kāi)源HTTP反向代理工具，主要用于反向代理、負(fù)載均衡和動(dòng)靜態(tài)資源分離。本文只用到了反向代理服務(wù)實(shí)現(xiàn)訪問(wèn)Steam社區(qū)和加防自己的ASF。

反向代理

在根服務(wù)器前部署一臺(tái)外層服務(wù)器做為網(wǎng)關(guān)，用戶只能訪問(wèn)到外層服務(wù)器，從而保護(hù)內(nèi)網(wǎng)服務(wù)器不被暴露。做為網(wǎng)關(guān)，也可以對(duì)報(bào)文分析和修改。
代理服務(wù)器和根服務(wù)器部署在一臺(tái)主機(jī)上稱(chēng)為本地反代。

1. ASF下載與安裝

1.1 ASF版本選擇

ASF有著Steam賬號(hào)的高度控制權(quán)，所以安全部署尤為重要。
為保證程序不被惡意篡改，請(qǐng)務(wù)必在作者倉(cāng)庫(kù)上下載！
隨著ASF版本的不斷迭代，會(huì)修復(fù)許多安全漏洞，增強(qiáng)安全性，所以這里推薦使用最新穩(wěn)定版。
我在部署時(shí)使用的版本是5.2.3.7，本文的所有操作均已在這個(gè)版本試驗(yàn)通過(guò)。
ASF在每個(gè)版本號(hào)下根據(jù)系統(tǒng)的不同又分為不同的文件，根據(jù)系統(tǒng)和CPU制造商來(lái)選擇正確的版本，也可以直接下載源碼編譯。

我的服務(wù)器是跑在Intel CPU上的Ubuntu，所以下載ASF-linux-x64.zip文件。

1.2 ASF下載

Linux上下載方式很多，例如wget指令。
wget https://github.com/JustArchiNET/ArchiSteamFarm/releases/download/5.2.3.7/ASF-linux-x64.zip
由于不可描述的原因，Github在大陸下載緩慢甚至無(wú)法下載。解決方法網(wǎng)上也有很多，可以自己在電腦上下載后再上傳到云服務(wù)器，也可以通過(guò)鏡像站下載，這里不再過(guò)多贅述。

1.3 ASF安裝及使用

Linux使用unzip命令解壓zip文件。
筆者在當(dāng)前目錄下新建了asf文件夾，并解壓到里面。
mkdir asf
unzip ASF-linux-x64.zip ./asf/
解壓后，運(yùn)行ArchiSteamFarm文件即可。
如果顯示Permission denied或文件名為灰色，則需要執(zhí)行chmod +x ArchiSteamFarm獲取執(zhí)行權(quán)限。

如果顯示2022-03-16 15:29:39|ArchiSteamFarm-1377456|INFO|相關(guān)字段，說(shuō)明ASF已經(jīng)成功安裝。

2. Steam社區(qū)受屏蔽情況和理論解決方法（跳過(guò)也不影響）

起初，國(guó)內(nèi)通過(guò)DNS污染以及HTTP報(bào)文關(guān)鍵字檢測(cè)來(lái)攔截訪問(wèn)Steam社區(qū)內(nèi)容。
在DNS污染下，瀏覽器訪問(wèn)會(huì)出現(xiàn)ERR_CONNECTION_TIMED_OUT錯(cuò)誤，因?yàn)镈NS會(huì)被指向一個(gè)不可訪問(wèn)的地址，訪問(wèn)也就超時(shí)了。
解決方法就是在本地就做好解析，通過(guò)修改Hosts文件直連IP訪問(wèn)。
但是這不是重點(diǎn)，現(xiàn)在的Steam社區(qū)也不是這么簡(jiǎn)單的屏蔽方式。
2018年開(kāi)始，Steam社區(qū)默認(rèn)采用HTTPS鏈接，所有的瀏覽內(nèi)容都會(huì)被加密，報(bào)文關(guān)鍵字檢測(cè)的方法也就失效了。
隨后出現(xiàn)了更深層次的審查方法，也就是要詳細(xì)介紹的SNI檢測(cè)。

2.1 SNI

正常情況下，TLS握手需要經(jīng)歷以下幾個(gè)階段。

在Client Hello階段，由于雙方還未協(xié)商好加密方式，報(bào)文仍然是明文狀態(tài)，其中Extension字段包含了SNI信息，也就包含了當(dāng)前正在訪問(wèn)的域名steamcommunity.com，可以抓包獲取到。

正常情況下，服務(wù)端根據(jù)這個(gè)域名發(fā)送相應(yīng)的域名證書(shū)，進(jìn)行接下來(lái)的握手步驟，在協(xié)商完后開(kāi)始使用加密通信。
但是，SNI已經(jīng)暴漏，審查機(jī)構(gòu)會(huì)對(duì)當(dāng)中的域名進(jìn)行檢測(cè)和阻斷，也就是TCP重置攻擊，通過(guò)對(duì)雙方瘋狂發(fā)送RST報(bào)文使連接重置，如果是瀏覽器訪問(wèn)就會(huì)出現(xiàn)ERR_CONNECTION_RESET錯(cuò)誤。
看完了可能會(huì)困惑，為什么要有SNI這個(gè)東西存在，握手過(guò)程沒(méi)有它不也沒(méi)有影響嗎？
是的，在以前，每個(gè)服務(wù)器只會(huì)綁定一個(gè)域名，SNI完全沒(méi)有存在的必要，訪問(wèn)某個(gè)服務(wù)器也一定只訪問(wèn)這個(gè)域名。
但是隨著CDN的迅速發(fā)展，大多數(shù)網(wǎng)站為了提升響應(yīng)速度和安全等級(jí)，都會(huì)將服務(wù)交給CDN托管，也就是說(shuō)每個(gè)CDN服務(wù)器都會(huì)為多家網(wǎng)站提供服務(wù)，例如Steam就將業(yè)務(wù)部署在CDN服務(wù)商Akamai上。
CDN服務(wù)器會(huì)根據(jù)用戶要訪問(wèn)的域名提供相應(yīng)的內(nèi)容，也就是識(shí)別SNI中的域名返回相應(yīng)的頁(yè)面。所以SNI對(duì)于現(xiàn)在的互聯(lián)網(wǎng)環(huán)境已經(jīng)不可或缺了。

2.2 那么有什么辦法可以解決呢？

答案很碰巧，就是在Client Hello階段不攜帶SNI或者攜帶無(wú)效的SNI，隱藏真實(shí)的連接網(wǎng)站來(lái)規(guī)避互聯(lián)網(wǎng)審查。
當(dāng)CDN檢測(cè)到無(wú)效的SNI，會(huì)返回一張默認(rèn)證書(shū)以便能夠繼續(xù)連接。碰巧的是，Akamai所返回的默認(rèn)證書(shū)就是Steam的泛域名證書(shū)（畢竟Steam是最大的客戶）。
這種技術(shù)叫做域前置，截至目前對(duì)Steam、Pixiv、Github等大型網(wǎng)站都有效。
下面就來(lái)介紹具體的實(shí)施過(guò)程。

3. 配置Nginx本地反向代理連接Steam社區(qū)（國(guó)外云服務(wù)器跳過(guò)）

好在這種阻斷方式只是普通的封鎖，并不是實(shí)質(zhì)意義上的“墻”，可以通過(guò)本地反向代理繞過(guò)審查。
Windows端可以通過(guò)steamcommunity 302輕松解決（羽翼城大佬YYDS）。
Linux端可以參考他的文章 steamcommunity 302 V2(steam118錯(cuò)誤修復(fù)工具) v12.1.25 綠色免費(fèi)版
鑒于Nginx是主流以及它還跑有其他服務(wù)，這里根據(jù)大佬的思路在Nginx上實(shí)現(xiàn)。

將Steam社區(qū)等域名添加到Hosts文件中并指向localhost，這里的localhost僅做為一個(gè)本地安全跳板，供Nginx正常監(jiān)聽(tīng)的同時(shí)又能防止流量外泄。Nginx將監(jiān)聽(tīng)到的數(shù)據(jù)中的SNI信息去除，再送向CDN的IP，使用IP而不使用域名是為了防止DNS污染，既實(shí)現(xiàn)完整通信又不被互聯(lián)網(wǎng)審查到。

3.1 配置Host

將訪問(wèn)困難的域名添加到Hosts文件中，配置如下：

127.0.0.1 steamcommunity.com
127.0.0.1 www.steamcommunity.com
127.0.0.1 store.steampowered.com
127.0.0.1 api.steampowered.com

一些云服務(wù)器在每次重啟后會(huì)恢復(fù)默認(rèn)Hosts，服務(wù)器提供商不同解決辦法也不同，具體操作請(qǐng)自行百度。
下面的Nginx配置也會(huì)用到這些域名。

3.2 生成并安裝證書(shū)

整個(gè)通信過(guò)程必須使用HTTPS加密協(xié)議，一是為了避免審查機(jī)構(gòu)的報(bào)文關(guān)鍵字檢測(cè)，二是Steam禁止明文HTTP訪問(wèn)，會(huì)自動(dòng)跳轉(zhuǎn)到HTTPS訪問(wèn)。
作為本地反代服務(wù)器，Nginx將監(jiān)聽(tīng)的報(bào)文頭處理后再發(fā)送給CDN，但是此時(shí)的Nginx服務(wù)器在宿主機(jī)看來(lái)是“不可信”的，除非強(qiáng)制讓其可信，也就是在主機(jī)安裝CA根證書(shū)，同時(shí)HTTPS反代也需要部署中間證書(shū)。

網(wǎng)上的許多教程都是用命令生成的證書(shū)，步驟比較復(fù)雜。不會(huì)操作的可以運(yùn)行steamcommunity 302自動(dòng)生成證書(shū)，上傳到服務(wù)器。
302工具第一次使用后會(huì)在根目錄生成一堆證書(shū)和密鑰。

只需要將steamcommunity.crt、steamcommunity.key和steamcommunityCA.pem三個(gè)文件上傳到服務(wù)器。

三個(gè)文件的作用

steamcommunityCA.pem：通過(guò)Openssl（302工具內(nèi)置了Openssl）自簽的CA根證書(shū)。只有在服務(wù)器中添加并信任根證書(shū)，它所簽發(fā)的二級(jí)證書(shū)才會(huì)被信任。
steamcommunity.crt和steamcommunity.key：上述CA根證書(shū)簽發(fā)的二級(jí)證書(shū)，Nginx在反代時(shí)使用該證書(shū)和私鑰對(duì)流量進(jìn)行加密。只有服務(wù)器信任了CA根證書(shū)，用二級(jí)證書(shū)加密的流量才會(huì)被視為安全。

將steamcommunity.crt和steamcommunity.key放在任意一個(gè)能讀取到的路徑就好。例如放在/etc/nginx/ca-certificates/下方便管理，在Nginx配置文件中也方便填寫(xiě)相對(duì)路徑。
不同的系統(tǒng)，安裝CA證書(shū)的方法也不同。
例如在Ubuntu中，將steamcommunityCA.pem命名為steamcommunityCA.crt扔進(jìn)/usr/local/share/ca-certificates/，然后執(zhí)行update-ca-certificates安裝。

3.3 配置Nginx參數(shù)

Nginx的配置文件位于/etc/nginx/nginx.conf，這里給出基本配置：

server {# 部署一個(gè)虛擬主機(jī)
        listen localhost:443 ssl;# 監(jiān)聽(tīng)localhost的443端口
        server_name steamcommunity.com;# 添加要監(jiān)聽(tīng)的域名，與Hosts文件里的域名一致
        server_name www.steamcommunity.com;
        server_name store.steampowered.com;
        server_name api.steampowered.com;
        ssl_certificate ca-certificates/steamcommunity.crt;# 設(shè)置證書(shū)，這里使用了相對(duì)路徑，絕對(duì)路徑也行
        ssl_certificate_key ca-certificates/steamcommunity.key;# 設(shè)置與證書(shū)匹配的密鑰，同上
        location / {# 當(dāng)監(jiān)聽(tīng)的端口檢測(cè)到通往上述域名的流量時(shí)，執(zhí)行下列操作
                proxy_pass https://223.119.248.24/;# 將流量送往223.119.248.24主機(jī)，理論上任何一個(gè)Akamai服務(wù)器IP都可以
                proxy_set_header Host $http_host;# 務(wù)必要加上，否則會(huì)報(bào)錯(cuò)URL非法
        }
}

做完后記得讓Nginx重新讀取配置，也就是找到Nginx的主程序然后nginx -reload。

問(wèn)：為什么要監(jiān)聽(tīng)443端口？
答：因?yàn)锳SF使用Https協(xié)議請(qǐng)求Steam獲取數(shù)據(jù)，也就是日常瀏覽網(wǎng)頁(yè)的方式。Https協(xié)議默認(rèn)通過(guò)443端口傳輸，所以proxy_pass https://223.119.248.24/;可以不加443。
問(wèn)：如果不配置證書(shū)或證書(shū)不可信會(huì)怎樣？
答：如果在是瀏覽器訪問(wèn)，會(huì)提示連接不安全，但仍可以訪問(wèn)。如果是ASF或Steam客戶端會(huì)默認(rèn)禁止SSL證書(shū)無(wú)效的連接。

4. ASF配置

所有配置文件都存放在ASF根目錄下的config文件夾。
如果目錄為空（初次安裝），ASF會(huì)走默認(rèn)配置；如果有配置文件，ASF會(huì)優(yōu)先走文件里的配置，文件里沒(méi)有寫(xiě)到的就走默認(rèn)配置。
大多數(shù)配置文件都可以直接文本編輯或者通過(guò)ASF-ui修改，還可以用官方編寫(xiě)的ASF配置文件生成器修改后上傳。
在官方Wiki上能找到所有的中文教程，這里只說(shuō)下基本配置。

4.1 ASF.json配置

ASF.json存放ASF的全局配置，主要是程序上的配置，基本格式如下：

{
  "Headless": true,
  "IPCPassword": "網(wǎng)頁(yè)登入密碼",
  "SteamOwnerID": Steam帳號(hào)64位ID
}

請(qǐng)務(wù)必設(shè)置IPC密碼（IPCPassword），因?yàn)樗茿SF的最后一道防線！

4.2 IPC.config配置

IPC包括了各種ASF-api和ASF-ui界面，前者用于插件和界面的二次開(kāi)發(fā)；后者是ASF自帶的操作界面，默認(rèn)部署在localhost:1242端口上，通過(guò)瀏覽器就能訪問(wèn)。
IPC.config存放HTTP服務(wù)端的相關(guān)配置（就是ASF操作界面的IP、端口、證書(shū)相關(guān)配置），配置如下：

{
    "Kestrel": {
        "Endpoints": {
            "example-http4": {
                "Url": "http://127.0.0.1:1242"
            },
            "example-http6": {
                "Url": "http://[::1]:1242"
            },
            "example-https4": {
                "Url": "https://127.0.0.1:1242",
                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            },
            "example-https6": {
                "Url": "https://[::1]:1242",
                "Certificate": {
                    "Path": "/path/to/certificate.pfx",
                    "Password": "passwordToPfxFileAbove"
                }
            }
        }
    }
}

IPv6尚未普及，一般使用IPv4部署ASF。

5. ASF 安全部署方案

平常在電腦上安裝ASF，ASF-ui默認(rèn)監(jiān)聽(tīng)localhost:1242端口，考慮到僅在本地訪問(wèn)所以Http通信足矣。但如果是部署在服務(wù)器上，ASF-ui就要暴露在公網(wǎng)上被我們所訪問(wèn)。在公網(wǎng)上不能保證自己的IP不被監(jiān)聽(tīng)，如果繼續(xù)使用Http通信，流量中的明文密碼將會(huì)泄漏。
因此，我們要將明文流量通過(guò)TLS加密，也就是使用Https協(xié)議，這樣即使被別有用心的人監(jiān)聽(tīng)到也只是加密的數(shù)據(jù)，對(duì)方無(wú)法解密，也就確保了密碼相對(duì)安全。
ASF自身支持以Https方式啟動(dòng)ui，也可以使用Nginx本地反代Http協(xié)議下的ASF。

不管哪種方式，都需要申請(qǐng)ssl證書(shū)才能啟用HTTPS。而申請(qǐng)ssl證書(shū)需要一個(gè)合法域名。國(guó)內(nèi)幾乎申請(qǐng)不到免費(fèi)的域名，免費(fèi)方案下只能從外網(wǎng)免費(fèi)申請(qǐng)了，我用的是Freenom申請(qǐng)了一年的.ml后綴域名。
得到域名擁有權(quán)后再到國(guó)內(nèi)云服務(wù)商上申請(qǐng)國(guó)內(nèi)解析權(quán)，這樣解析速度就和國(guó)內(nèi)購(gòu)買(mǎi)的域名一樣了。

至于ssl證書(shū)申請(qǐng)，可以使用各大云免費(fèi)申請(qǐng)一年，提交申請(qǐng)后半小時(shí)內(nèi)就能下來(lái)。
如果域名備案了，就可以放心使用443端口，否則就會(huì)被互聯(lián)網(wǎng)審查機(jī)構(gòu)攔截阻斷。畢竟ASF一般都是私用，選擇默認(rèn)1242端口就好。使用其他自定義端口沒(méi)有實(shí)際增加安全性，但可以避免過(guò)于明顯的掃描。

一定要記得在服務(wù)器上放行相應(yīng)端口！

下面簡(jiǎn)述幾種常見(jiàn)的安全部署方案：

5.1 本機(jī)運(yùn)行 ASF（僅Http）

如果只部署在localhost，除非本機(jī)被攻破，否則ASF是安全的。
IPC.config配置如下：

{
        "Kestrel": {
                "Endpoints": {
                        "example-http4": {
                                "Url": "http://localhost:自定義端口"
                        }
                }
        }
}

5.2 公網(wǎng)運(yùn)行 ASF（僅Https）

這種情況下，ASF將暴露到整個(gè)網(wǎng)絡(luò)，必須配置SSL證書(shū)+Https協(xié)議，否則在數(shù)據(jù)傳輸過(guò)程中IPC密碼將以明文顯示，有被監(jiān)聽(tīng)走的風(fēng)險(xiǎn)。
在申請(qǐng)的證書(shū)中下載pfx格式證書(shū)，然后在IPC.config中添加pfx證書(shū)和相應(yīng)的私鑰字符串。
IPC.config配置如下：

{
        "Kestrel": {
                "Endpoints": {
                        "example-https4": {
                                "Url": "https://自定義域名或IP:端口",
                                "Certificate": {
                                        "Path": "config/我的域名證書(shū).pfx",
                                        "Password": "pfx證書(shū)附帶的私鑰"
                                }
                        }
                }
        }
}

如果使用相對(duì)路徑，以ASF主程序的同級(jí)目錄為當(dāng)前路徑。

5.3 公網(wǎng)運(yùn)行 ASF（Http + Nginx Https反代）

此時(shí)的IPC.config配置可以默認(rèn)，默認(rèn)了話就是監(jiān)聽(tīng)本地1242端口，然后通過(guò)Nginx監(jiān)聽(tīng)公網(wǎng)443端口。
nginx.conf配置如下：

server {
        listen 443 ssl;# 監(jiān)聽(tīng)443端口，這里就包括了公網(wǎng)訪問(wèn)進(jìn)來(lái)的端口
        server_name www.我的域名.com;#添加要監(jiān)聽(tīng)的域名，也就是申請(qǐng)的域名
        ssl_certificate /etc/nginx/ca-certificates/我的域名SSL證書(shū).crt;# 添加crt證書(shū)路徑，絕對(duì)路徑也可
        ssl_certificate_key ca-certificates/我的域名SSL證書(shū).key;# 同上
        location / {# 當(dāng)監(jiān)聽(tīng)到上述域名的流量時(shí)，執(zhí)行下列操作
                proxy_pass https://localhost:1242/;# 將流量送往ASF監(jiān)聽(tīng)的端口，默認(rèn)是localhost:1242
                # 使用下列的配置，ASF能正確檢測(cè)到發(fā)送請(qǐng)求用戶的IP地址
                # 使ASF能夠封禁真正的攻擊者而非Nginx反代服務(wù)器
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Host $host:$server_port;
                proxy_set_header X-Forwarded-Host $host:$server_port;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Real-IP $remote_addr;
        }
}

若訪問(wèn)頁(yè)面出現(xiàn)502 Bad Gateway，說(shuō)明Nginx反代正常，但未監(jiān)聽(tīng)到ASF流量，請(qǐng)檢查IPC是否開(kāi)啟以及l(fā)ocation匹配是否正確。

6. 結(jié)束語(yǔ)

這篇文章也是我查了很多資料后才寫(xiě)出來(lái)的，為了講清楚從SNI檢測(cè)到屏蔽手段也是把各種協(xié)議都復(fù)習(xí)了一遍，甚至還通過(guò)抓包來(lái)證明自己的理解，如果有錯(cuò)誤希望大佬們指出。
最后，希望這篇文章能幫助到需要的人。

參考文章

1. Linux/Macos環(huán)境下使用 steamcommunity 302 教程
2. ArchiSteamFarm wiki
3. 云服務(wù)器ASF掛卡——steamcommunity社區(qū)本地反代
4. 在手機(jī)上訪問(wèn)discord和pixiv的正確姿勢(shì)
5. 淺談asf ipc于服務(wù)器部署之安全方案
6. 針對(duì)庫(kù)存被盜帖，討論 ASF 部署的安全性
7. ASF IPC網(wǎng)頁(yè)管理界面Nginx反代教程（帶Https）
8. 從 pixiv 免代理直連看 SNI 阻斷及其繞過(guò)方法——域前置
9. 自簽CA對(duì)Steam社區(qū)進(jìn)行反代
10. HTTPS 之 SSL/TLS 握手協(xié)議（Handshake Protocol）全過(guò)程解析
11. How does a TCP Reset Attack work?

到此這篇關(guān)于從Steam社區(qū)屏蔽分析繞過(guò)方法及ASF安全部署的文章就介紹到這了,更多相關(guān)Steam社區(qū)屏蔽內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論