事情是這樣的，之前給別人寫的一個(gè)單子，爬數(shù)據(jù)的請(qǐng)求給檢測(cè)到了。

當(dāng)時(shí)我還是用的C# 自帶Httpwebrequest 來請(qǐng)求的。

但是，我封裝的請(qǐng)求本身沒有異常，放到Postman來請(qǐng)求可以通過，所有覺得是更底層的東西被檢測(cè)，期間我更是用三種抓包軟件來代理，發(fā)現(xiàn)一樣的數(shù)據(jù)，在fiddler和charles是不通過，而在mitmproxy則能通。后來又通過wireshark，來分析了兩者的不同，發(fā)現(xiàn)是在tls那塊不同，

也就是?cipher suite（密鑰套件）長(zhǎng)度不一樣，這玩意我也第一次接觸，問題是找到了。

C#的Httpwebrequest 短時(shí)間我是不知道怎么處理cipher suite了，花了些時(shí)間找合適的http庫，找到了一個(gè)大佬們經(jīng)常用的curl。我自己用也是第一次，開始是先在cmd測(cè)試，我用最新的windows版本(7.87.0)也不通過，但是換成(7.70.0)就通過，當(dāng)時(shí)還沒想著改ciphers。

庫是找到了，當(dāng)時(shí)就蠢著直接封裝cmd執(zhí)行請(qǐng)求然后返回結(jié)果。沒跑多久就爆了，無奈之下只能去用libcurl，之前是想著封裝一下libcurl，結(jié)果剛起頭就覺得太麻煩不弄了。

最終在GitHub上找到了一個(gè)現(xiàn)成的（https://github.com/stil/CurlThin），不過因?yàn)橛悬c(diǎn)舊的原因，并不能直接跑起來。

會(huì)報(bào)錯(cuò)->訪問保護(hù)的內(nèi)存。

解決方法：

原代碼：[DllImport(LIBCURL, EntryPoint = "curl_easy_getinfo")]

修改后：[DllImport(LIBCURL, EntryPoint = "curl_easy_getinfo", CallingConvention = CallingConvention.Cdecl)]

能用libcurl后，跑了2天又噶了。

我就在想我用同一個(gè)ciphers是不是給抓特征了，于是乎整了一大堆，每次請(qǐng)求隨機(jī)組合。雖然又行了，但沒多久就有噶了。

這次沉下心來查資料，果然還是給我找到了，在GitHub上找到一個(gè)以curl為基礎(chǔ)，完全模擬瀏覽器請(qǐng)求的項(xiàng)目（https://github.com/lwthiker/curl-impersonate）。

仔細(xì)看了，發(fā)現(xiàn)每個(gè)瀏覽器的ciphers都不同，但都是固定，我就拿了chrome的ciphers，能在原生libcurl改的參數(shù)都改了。好在到現(xiàn)在還沒噶，等噶了再說吧。