搞移動(dòng)端開(kāi)發(fā)的人幾乎都繞不過(guò)抓包這一步。前陣一個(gè)朋友發(fā)消息問(wèn)我用 Charles 抓手機(jī)包的時(shí)候?yàn)槭裁从械陌苷Ｗサ接械膮s顯示 unknown他說(shuō)自己對(duì)著同一個(gè) App 翻來(lái)覆去刷大部分接口都能看到 JSON 響應(yīng)可個(gè)別接口在列表里只剩一個(gè)帶 unknown 標(biāo)識(shí)的深色條目點(diǎn)開(kāi)以后沒(méi)有 URL、沒(méi)有請(qǐng)求頭、沒(méi)有響應(yīng)體。這個(gè)問(wèn)題我剛上手 Charles 時(shí)也撞見(jiàn)過(guò)而且當(dāng)時(shí)還以為是手機(jī)代理沒(méi)配好折騰了大半宿。后來(lái)把原理弄清楚了才發(fā)現(xiàn)答案一直都很明確網(wǎng)上的說(shuō)法是“HTTPS 要裝證書(shū)”但真正的原因往往比這一句話更細(xì)。這篇文章不打算從零教你怎么配置代理而是把所有可能讓某個(gè)包顯示成 unknown 的原因一條條捋清楚再給你一套可以直接照著做的排查步驟。不管你是剛?cè)腴T(mén)的 Android 開(kāi)發(fā)、正在做前后端聯(lián)調(diào)還是偶爾要看看線上接口的測(cè)試同學(xué)后面這些內(nèi)容應(yīng)該都能幫你省下不少時(shí)間。1. 先搞清楚 Charles 的工作原理再看 unknown 從哪來(lái)1.1 HTTP 是明文Charles 當(dāng)然看得懂抓包之所以能成功本質(zhì)上是手機(jī)把流量交到了 Charles 手里。你在 Wi-Fi 設(shè)置里填代理 IP 和端口之后App 發(fā)出的每一個(gè) HTTP 請(qǐng)求都會(huì)先到電腦上的 Charles 進(jìn)程然后由 Charles 轉(zhuǎn)發(fā)給真正的服務(wù)器。這個(gè)“轉(zhuǎn)發(fā)”的動(dòng)作非常關(guān)鍵。HTTP 協(xié)議是明文傳輸?shù)恼?qǐng)求行、請(qǐng)求頭、請(qǐng)求體都沒(méi)有加密Charles 作為一個(gè)中間代理完全可以在這個(gè)轉(zhuǎn)發(fā)過(guò)程中把完整報(bào)文復(fù)制一份給你看。所以你抓到的 HTTP 接口URL、Headers、參數(shù)、JSON 響應(yīng)體都能清清楚楚展示出來(lái)這也是很多人對(duì)抓包的第一印象好像只要代理配好什么都能看。但這里有個(gè)容易被忽略的事實(shí)Charles 能解密 HTTP不是因?yàn)槭裁春谀Хǘ且驗(yàn)閰f(xié)議本身就沒(méi)有加密。它只需站在客戶(hù)端和服務(wù)器之間把流量原樣過(guò)一遍。到了 HTTPS 這里情況就完全不同了。1.2 HTTPS 包CONNECT 隧道后面的黑盒HTTPS 不是一個(gè)單獨(dú)的協(xié)議而是 HTTP 跑在 TLS/SSL 加密層之上。手機(jī)上的 App 要和服務(wù)器建立 HTTPS 連接時(shí)雖然也要先經(jīng)過(guò) Charles但事情變得復(fù)雜了。第一步客戶(hù)端會(huì)發(fā)給 Charles 一個(gè) CONNECT 請(qǐng)求意思是“喂我要和某個(gè)域名加端口的服務(wù)器建立一條隧道你幫我搭個(gè)橋之后的數(shù)據(jù)你別動(dòng)”。這個(gè) CONNECT 請(qǐng)求本身是明文所以 Charles 能看到目標(biāo)域名和端口比如api.example.com:443。關(guān)鍵在第二步。隧道建立之后客戶(hù)端和服務(wù)器之間開(kāi)始進(jìn)行 TLS 握手。如果 Charles 沒(méi)有在這個(gè)環(huán)節(jié)介入那么隧道里流動(dòng)的全是加密后的密文Charles 作為一個(gè)“管道工”只能看到一大堆看不懂的二進(jìn)制數(shù)據(jù)。這時(shí)候 Charles 會(huì)怎么標(biāo)記這一條流量如果它完全無(wú)法解析就會(huì)直接顯示為unknown。你點(diǎn)進(jìn)去能看到的大概只有目標(biāo)主機(jī)和端口其它什么都看不了。簡(jiǎn)單來(lái)說(shuō)對(duì) Charles 而言u(píng)nknown 就是“我確認(rèn)這條連接是從你這臺(tái)手機(jī)發(fā)出去的但我沒(méi)能解密它”。1.3 “unknown” 這個(gè)詞只代表 Charles 沒(méi)能解密很多人看到 unknown 第一反應(yīng)是網(wǎng)絡(luò)問(wèn)題或者 App 有問(wèn)題其實(shí)都不對(duì)。unknown 不是報(bào)錯(cuò)它只是一個(gè)狀態(tài)標(biāo)識(shí)代表 Charles 未能成功介入 TLS 握手自然也就沒(méi)有拿到可以解密會(huì)話的鑰匙。TLS 握手的簡(jiǎn)要流程是客戶(hù)端先發(fā)送 ClientHello里面寫(xiě)明支持的加密套件和希望訪問(wèn)的域名SNI之后服務(wù)器返回 ServerHello 和自己的證書(shū)客戶(hù)端驗(yàn)證證書(shū)后雙方再通過(guò)一系列密鑰交換算出同一個(gè)會(huì)話密鑰。Charles 如果想解密 HTTPS就必須在這中間扮演“假服務(wù)器”的角色客戶(hù)端來(lái)握手時(shí)Charles 不是把請(qǐng)求轉(zhuǎn)發(fā)給真實(shí)服務(wù)器而是自己先回應(yīng)一個(gè)證書(shū)。這個(gè)證書(shū)是 Charles 自己生成的如果客戶(hù)端信任了它也就是手機(jī)里裝了 Charles 的根證書(shū)雙方就能繼續(xù)協(xié)商密鑰Charles 在密鑰協(xié)商結(jié)束后便能解密所有往來(lái)數(shù)據(jù)。如果客戶(hù)端不信任這個(gè)證書(shū)握手會(huì)立刻失敗客戶(hù)端通常會(huì)表現(xiàn)出請(qǐng)求失敗或一直轉(zhuǎn)圈Charles 這邊則留下一個(gè)沒(méi)有解密能力的 unknown 條目。提示判斷一個(gè)包是不是因?yàn)椤皼](méi)解密”而變成 unknown最簡(jiǎn)單的方法是看 Charles 左邊列表里是否只剩下 CONNECT 請(qǐng)求或者一行 host:port。如果連域名都看不到說(shuō)明問(wèn)題大概率出在 TLS 介入失敗而不是域名解析失敗。把原理說(shuō)清楚以后下面就可以按“三家分鍋”的思路來(lái)排查了。2. 三家分鍋?zhàn)C書(shū)、SSL 代理規(guī)則、應(yīng)用校驗(yàn)2.1 最常見(jiàn)證書(shū)沒(méi)裝或沒(méi)打開(kāi)完全信任第一個(gè)鍋也是最常見(jiàn)的鍋是手機(jī)根本沒(méi)有信任 Charles 的根證書(shū)。Charles 自帶一個(gè)根證書(shū)用來(lái)生成每個(gè)網(wǎng)站對(duì)應(yīng)的“假證書(shū)”。你需要在計(jì)算機(jī)上先安裝 Charles 的根證書(shū)再把它裝進(jìn)手機(jī)。很多教程會(huì)告訴你“在手機(jī)瀏覽器里打開(kāi) chls.pro/ssl 下載安裝”但這只是第一步。重點(diǎn)提醒一下iOS 用戶(hù)裝完描述文件以后還必須去“設(shè)置 - 通用 - 關(guān)于本機(jī) - 證書(shū)信任設(shè)置”里面把 Charles CA 打開(kāi)完全信任。這一步很多教程不會(huì)寫(xiě)漏掉之后 Charles 依然會(huì)顯示 unknown。Android 的情況更麻煩。Android 7.0 之后系統(tǒng)默認(rèn)不信任用戶(hù)自己安裝的 CA 證書(shū)只有目標(biāo) SDK 版本較低的 App 才會(huì)兼容用戶(hù)證書(shū)。也就是說(shuō)你把證書(shū)裝進(jìn)手機(jī)瀏覽器可能能用但很多正經(jīng) App 根本不會(huì)用它結(jié)果就是你看到某個(gè)域名的包始終 unknown。2.2 次常見(jiàn)SSL Proxying 規(guī)則沒(méi)加全第二個(gè)鍋是 Charles 的 SSL Proxying 規(guī)則沒(méi)配置或者配置得不夠全。Charles 不是裝完證書(shū)就會(huì)自動(dòng)解密所有 HTTPS 流量你必須在Proxy - SSL Proxying Settings里添加需要解密的域名和端口規(guī)則。如果你把這個(gè)頁(yè)面完全空著或者只填了某個(gè)具體域名那么其它域名的 HTTPS 包就會(huì)保持 unknown。很多第一次用 Charles 的人會(huì)把 Host 填成www.example.com、端口填 443 這種精確規(guī)則結(jié)果同一個(gè) App 里換了一個(gè)子域名就又開(kāi)始 unknown。在做全面調(diào)試的時(shí)候我通常建議直接加一條* : 443先把最常見(jiàn)的 HTTPS 端口全覆蓋。等確認(rèn)問(wèn)題后再逐步收窄到具體域名。注意 Host 和 Port 是分開(kāi)填的兩列很多人會(huì)在這里填錯(cuò)格式。2.3 最難搞應(yīng)用做了證書(shū)校驗(yàn)第三個(gè)鍋是 App 自身做了證書(shū)校驗(yàn)行業(yè)內(nèi)通常叫 SSL Pinning。這種情況最棘手因?yàn)樗?Charles、和手機(jī)系統(tǒng)都沒(méi)有直接關(guān)系。SSL Pinning 的意思是App 在代碼里寫(xiě)死了它信任的服務(wù)器證書(shū)或公鑰。即使你往手機(jī)里裝了 Charles 的根證書(shū)App 依然只認(rèn)自己內(nèi)置的那張服務(wù)器證書(shū)看到 Charles 發(fā)來(lái)的“假證書(shū)”時(shí)會(huì)直接拒絕握手。表現(xiàn)出來(lái)就是你證書(shū)裝好了、SSL Proxying 也開(kāi)了但某個(gè) App 的所有請(qǐng)求全部 unknown或者整個(gè)頁(yè)面干脆無(wú)法加載。銀行類(lèi)、支付類(lèi)、大廠的 App 基本都是這種策略。遇到這類(lèi) App首先不要懷疑自己的抓包步驟這屬于 App 安全策略的一部分。如果是你自己開(kāi)發(fā)的 App可以在 debug 包里程時(shí)關(guān)閉 Pinning或者用一個(gè)專(zhuān)門(mén)的測(cè)試包。如果是第三方 App就需要通過(guò) hook 等方式繞過(guò)校驗(yàn)但這已經(jīng)超出了“配證書(shū)”的范疇且只建議在你有合法授權(quán)的前提下使用。2.4 容易被忽略非標(biāo)準(zhǔn)端口與 UDP/QUIC最后一種情況很多人栽過(guò)跟頭但從未想到過(guò)App 根本不走 443 端口或者壓根不是 TCP 協(xié)議。有些 App 為了防抓包或者因?yàn)闅v史原因HTTPS 服務(wù)跑在 8080、8443、9090 這種自定義端口上。你的 SSL Proxying 規(guī)則只加了*:443它自然不在覆蓋范圍內(nèi)Charles 就顯示 unknown。排查辦法很簡(jiǎn)單看看列表里 unknown 條目后面的端口號(hào)再把 SSL Proxying 規(guī)則加上那個(gè)端口即可。至于 UDP 上的 QUIC/HTTP3那是另一個(gè)層面的問(wèn)題。Charles 默認(rèn)的抓包機(jī)制建立在 TCP 代理之上UDP 流量它根本不會(huì)完整接手。如果你發(fā)現(xiàn)某個(gè) App 的部分流量在 Charles 里徹底消失而系統(tǒng)網(wǎng)絡(luò)層面又能看到 UDP 報(bào)文那基本可以判斷是 QUIC 或自定義 UDP 協(xié)議。這種流量不是 unknown而是“不可見(jiàn)”。3. 完整實(shí)操把 unknown 變成可讀包3.1 確認(rèn)代理鏈路是否通先看這個(gè)淺淺的連接很多人在調(diào)整證書(shū)之前應(yīng)該先確認(rèn)手機(jī)流量到底有沒(méi)有經(jīng)過(guò) Charles。我見(jiàn)過(guò)太多案例折騰半天發(fā)現(xiàn)手機(jī)走的是 4G/5G 網(wǎng)絡(luò)跟電腦根本沒(méi)處在同一個(gè)局域網(wǎng)Charles 當(dāng)然什么都看不到。先做三件事。第一手機(jī)和電腦連到同一個(gè) Wi-Fi。第二在手機(jī) Wi-Fi 的代理設(shè)置里填寫(xiě)電腦的局域網(wǎng) IP 和端口 8888。第三在電腦上打開(kāi) Charles 的Proxy - Proxy Settings確認(rèn)勾選了 HTTP Proxy。之后隨便打開(kāi)一個(gè)網(wǎng)頁(yè)看 Charles 里會(huì)不會(huì)立刻出現(xiàn)流量條目。如果你看到大量流量進(jìn)來(lái)但有些顯示 unknown那說(shuō)明鏈路是通的問(wèn)題在解密層面。如果連一條流量都沒(méi)有優(yōu)先檢查電腦防火墻是不是把 8888 端口堵了或者手機(jī)代理 IP 填錯(cuò)了。3.2 在兩套系統(tǒng)上正確安裝證書(shū)確認(rèn)鏈路通之后再處理證書(shū)。電腦端先裝一份打開(kāi) Charles菜單欄選擇Help - SSL Proxying - Install Charles Root Certificate然后到系統(tǒng)鑰匙串里把證書(shū)設(shè)為始終信任。電腦端證書(shū)主要是為了讓 Charles 代理桌面端瀏覽器流量時(shí)不會(huì)被瀏覽器攔下來(lái)抓手機(jī)包時(shí)其實(shí)用不到但建議還是裝上后面做題省事。手機(jī)端分系統(tǒng)操作。iOS 的流程先是手機(jī)瀏覽器訪問(wèn)chls.pro/ssl下載描述文件然后去“設(shè)置 - 已下載描述文件”安裝裝完以后一定不要忘了去“設(shè)置 - 通用 - 關(guān)于本機(jī) - 證書(shū)信任設(shè)置”把 Charles CA 底下的開(kāi)關(guān)打開(kāi)。iOS 如果不做這最后一步系統(tǒng)并不認(rèn)為這個(gè)證書(shū)是受信任的TLS 握手照樣失敗。Android 的流程手機(jī)瀏覽器訪問(wèn)同樣的地址下載證書(shū)然后到“設(shè)置 - 安全 - 加密與憑據(jù) - 安裝證書(shū)”中選擇 CA 證書(shū)選擇用戶(hù)憑據(jù)完成安裝。裝完之后最好到“信任的憑據(jù) - 用戶(hù)”里確認(rèn)能看到 Charles CA。Android 7.0 以上的目標(biāo) App 默認(rèn)不信任用戶(hù)證書(shū)這一步屬于已知限制后面單獨(dú)說(shuō)怎么繞。3.3 配置 SSL Proxying 并添加精準(zhǔn)匹配證書(shū)裝好、信任開(kāi)關(guān)打開(kāi)接下來(lái)要告訴 Charles 它可以去解密哪些域名。打開(kāi)Proxy - SSL Proxying Settings先把Enable SSL Proxying勾上。然后在 Locations 區(qū)域點(diǎn)擊 Add按你的目標(biāo)添加規(guī)則。命令格式是 Host 和 Port 兩列Host 填*Port 填443就能覆蓋絕大多數(shù) HTTPS 流量。如果 App 用了自定義端口就把那一行再?gòu)?fù)制一條Port 改成實(shí)際端口。如果 App 的所有請(qǐng)求都直連某個(gè) IP而不是走域名那么 Host 也可以直接填那個(gè) IP 地址。我習(xí)慣在初次調(diào)試項(xiàng)目時(shí)直接加*:443看到流量后再針對(duì)重點(diǎn)域名做精細(xì)化配置。因?yàn)槟銓?xiě)太多精確規(guī)則漏掉任何一個(gè)子域都會(huì)讓人誤以為抓包失敗。注意Host 里的*是通配符不是讓你隨手填一個(gè)假的域名。很多人把 host 填成*:443一整串這就是完全搞錯(cuò)了列的含義規(guī)則不會(huì)生效。3.4 右鍵 unknown 項(xiàng)臨時(shí)開(kāi)啟解密有一種操作很多人不知道在 Charles 列表里選中一個(gè) unknown 條目然后右鍵選擇Enable SSL Proxying。Charles 會(huì)自動(dòng)幫你把這條流量的 Host 和 Port 加入 SSL Proxying 規(guī)則。然后你回到 App 里重新觸發(fā)一次請(qǐng)求就能看到原本 unknown 的條目被解密變成完整的 HTTPS 請(qǐng)求。這個(gè)操作的好處是精確、直接適合目標(biāo)域名不明確或者不確定端口的場(chǎng)景。我當(dāng)時(shí)處理那個(gè)朋友的 unknown 問(wèn)題用的就是這一招。他在 Charles 里右鍵某個(gè) unknown 條目Charles 自動(dòng)加了規(guī)則刷新頁(yè)面后綠色的 JSON 包立刻出現(xiàn)。需要提一句右鍵開(kāi)啟解密只對(duì)“Charles 能感知到但沒(méi)解密”的連接有效。如果 App 根本沒(méi)走 Charles 代理或者握手已經(jīng)被 App 自己攔截右鍵也不會(huì)生效。3.5 遇到校驗(yàn)型 App 該怎么辦如果你把證書(shū)、SSL 規(guī)則都配好了某個(gè) App 的請(qǐng)求還是 unknown那基本可以確認(rèn)它是校驗(yàn)型應(yīng)用。這種情況下正路有兩條。第一條針對(duì)你自研的 App在 build.gradle 或者對(duì)應(yīng)的網(wǎng)絡(luò)層配置里為 debug 版本關(guān)閉證書(shū)校驗(yàn)或者放寬網(wǎng)絡(luò)安全策略。具體做法是在 Android 的network_security_config.xml里給 debug 構(gòu)建加一個(gè)信任用戶(hù)證書(shū)的配置開(kāi)發(fā)階段可以臨時(shí)信任 Charlesrelease 版本恢復(fù)嚴(yán)格校驗(yàn)。iOS 同理用 NSURLSession 的 delegate 在開(kāi)發(fā)階段繞過(guò)攔截校驗(yàn)。第二條針對(duì)第三方 App只能借助 hook 工具繞過(guò)其 Pinning 邏輯。這類(lèi)工具本身是合法的安全研究工具但請(qǐng)不要用它去干任何越界的事情。如果你只是調(diào)試自己手機(jī)、自己設(shè)備范圍內(nèi)的應(yīng)用社區(qū)里有很多資料可以參考如果是商業(yè)軟件的逆向注意遵守相關(guān)規(guī)則和授權(quán)邊界。4. 排查實(shí)錄從數(shù)據(jù)看到的現(xiàn)象倒推原因4.1 只看到 IP 和端口域名全沒(méi)了一個(gè)很典型的現(xiàn)象Charles 左邊明明有流量但顯示的是111.222.333.444:443這種格式而不是api.example.com:443。你以為是 DNS 解析問(wèn)題其實(shí)不是。產(chǎn)生這個(gè)現(xiàn)象的原因通常是兩類(lèi)。一類(lèi)是 App 直接寫(xiě)死了服務(wù)器 IP不走域名這種情況下 TLS 握手里沒(méi)有 SNICharles 自然不知道域名只能顯示 IP。另一類(lèi)是 App 使用自定義 DNS 或者內(nèi)部網(wǎng)絡(luò)代理獲得的域名解析結(jié)果只能拿到 IP。處理辦法把這個(gè) IP 填到 SSL Proxying 規(guī)則里而不是填域名。如果你確定請(qǐng)求走的是域名但 Charles 只顯示 IP可以檢查一下是不是開(kāi)了 Charles 里的某個(gè)域名映射功能或者手機(jī)的 DNS 設(shè)置了特殊解析。4.2 證書(shū)信任了但部分頁(yè)面仍失敗這種情況最多見(jiàn)于混合內(nèi)容頁(yè)面App 一部分接口走正常的 HTTPS 443 端口另一部分走 WebSocket 或者流量被換成 QUIC。所以你看到“有的包能抓到有的 unknown”而且各自還很有規(guī)律。先說(shuō) WebSocket。App 先發(fā)起一個(gè)普通的 HTTP GET 請(qǐng)求帶有Upgrade: websocket頭服務(wù)器返回 101 狀態(tài)碼表示切換協(xié)議。之后雙方就在這個(gè) TCP 連接上持續(xù)收發(fā)數(shù)據(jù)幀Charles 對(duì)這個(gè)通道默認(rèn)只能看到握手之前的請(qǐng)求后續(xù)幀不會(huì)以 HTTP 請(qǐng)求的形式呈現(xiàn)很多就直接歸類(lèi)到 unknown 或 WebSocket 分類(lèi)下。再看端口規(guī)律。如果 unknown 條目清一色集中在某個(gè)端口比如 8443那就是 SSL Proxying 規(guī)則漏了端口。直接在設(shè)置里補(bǔ)一條*:8443就能解決。4.3 解出來(lái)的響應(yīng)全是亂碼和二進(jìn)制還有一種讓人摸不著頭腦的情況unknown 的問(wèn)題解決了包也確實(shí)被解密了但是響應(yīng)體看過(guò)去全是亂碼。先別急著懷疑解密失敗。很多后端接口為了節(jié)省流量會(huì)用 gzip、brotli 壓縮響應(yīng)體或者用 protobuf 這類(lèi)二進(jìn)制序列化格式。Charles 原樣顯示這些壓縮后的字節(jié)自然就是亂碼。你可以把響應(yīng)切換到 Hex 視圖看是否真是一堆字節(jié)也可以嘗試在 Charles 的 View 菜單里手動(dòng)選擇 JSON 來(lái)查看。如果是 protobuf還得配合對(duì)應(yīng)的 schema 才能解析。這類(lèi)包其實(shí)不算 unknown但容易讓人誤以為“還是沒(méi)有解密成功”。我的判斷習(xí)慣是如果 Charles 里能看到完整的請(qǐng)求頭和狀態(tài)碼說(shuō)明解密已成功展示層的問(wèn)題不影響調(diào)試。4.4 處理 HTTP/2、WebSocket 與 QUIC最后把新協(xié)議單獨(dú)說(shuō)一下。HTTP/2 基于 TCPCharles 是可以解密的。不過(guò)由于 HTTP/2 的二進(jìn)制分幀特性Charles 展示內(nèi)容和 HTTP/1.x 有些差別響應(yīng)頭分布在 Decoded 頁(yè)簽下很多人不熟悉會(huì)誤以為抓到的包不完整。其實(shí)該有的細(xì)節(jié)都在。WebSocket 和 HTTP/2/3 不一樣它一旦切換協(xié)議就是純二進(jìn)制幀。Charles 新版本支持顯示 WebSocket 的收發(fā)明文幀但如果 App 發(fā)送的是經(jīng)過(guò)壓縮或者自定義編碼的數(shù)據(jù)表現(xiàn)依然是無(wú)法閱讀。這種請(qǐng)配合其它客戶(hù)端工具做協(xié)議分析。QUIC/HTTP3 走 UDPCharles 默認(rèn)的 TCP 代理機(jī)制對(duì)它無(wú)效。如果你確定 App 在手機(jī)上啟用了 HTTP/3一個(gè)臨時(shí)餿主意是想辦法讓服務(wù)器端返回的 Alt-Svc 頭降級(jí)為 HTTP/2或者干脆在調(diào)試設(shè)備上禁用 UDP 443 端口讓流量強(qiáng)制退回 TCP。這個(gè)思路在不少調(diào)試場(chǎng)景里都有用。最后分享一點(diǎn)個(gè)人經(jīng)驗(yàn)。我現(xiàn)在每次抓包都按固定順序走先看手機(jī)代理有沒(méi)有生效再看電腦和手機(jī)兩端的證書(shū)是否完整信任接著確認(rèn) SSL Proxying 規(guī)則覆蓋了目標(biāo)域名和端口最后才去懷疑 App 是不是做了 Pinning。這個(gè)順序看上去簡(jiǎn)單但能把最容易踩的坑提前排掉。尤其是 iOS 的“證書(shū)信任設(shè)置”開(kāi)關(guān)很多人裝完描述文件就以為完事了其實(shí)還差最后一下Android 那邊則最容易卡在用戶(hù)證書(shū)不被高級(jí)別 App 信任。如果你把這些步驟全走了一遍某個(gè)包依舊 unknown那大概率不是 Charles 壞了而是這個(gè) App 在傳輸層做了文章。與其半夜刪了重裝再試不如按上面幾條逐項(xiàng)自查基本十分鐘內(nèi)能把問(wèn)題定位到具體環(huán)節(jié)。