跳至主要内容

NaiveProxy 深度剖析：基於 Chromium 內核的極致流量偽裝藝術

· 閱讀時間約 8 分鐘
w0x7ce
w0x7ce
MySelf

发布于 2026-01-22 20:30:22（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 3774 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

術 originalwθx7ce EI V1ajero2826年1月22日26:30美国 “If you can't beat them,join then."—NaiveProxy 的股哲學

preert,poting. Nalve Server Server Padkit Lergh Padcing Lsyer

CadR

在翔络安全與隔私保满的長期博奔中,各频流量种發工具(Shadowsocks以及VMess, Trojan等協)都在试图战計一橙“特微不明*的私有罐。然而,随著深度包檐测(DPI) 奥流量特微别技術的进化,基於模凝的罐始避以完全消除指紋。 NaiveProxy遥捶了一截然不同的技術路線:它不模凝Chrome测實器,它直接用了 Chrome的钢横。 本文将基於src/net/Lopls/naive/源码,為您呈现一份最鲜重、最硬核的 NaiveProxy 技術内幕剖析,探其在阐混滑與抗干方面的卓越投計。 架構設計之美(Architecture)

1.1為何選挥ChromiumPatchset?​

NaiveProxy 不是一個立阿發的钢然,它的本質是Chromium测宽器斓棱(Network Stack)的一個捕丁集(Patchset)。 这是一個天才般的投計决策,原因如下:

  • 指纹一致性(Fingerprint Consistency):

  • TLS 指紋(JA3):CL1ent Hello 中的加密套件(C1pher Suites)、摘展

(Extensions)、ALPN 颠序等,是由 Chromium底层的//net虚决定的。 NaiveProxy直接编露了这固障,因此它的TLS指纹與全球數十像用户使用的 Chrome 浏質器完全一致

  • HTTP/2 行為:流控窗口(FLowControlWindow)、帕發送顺序、跟部墨缩

(HPACK)策略,全部德用Chrome的通辑。

  • 维罐成本(Maintenance):

  • 每墨Chrone升级支持新(如 HTTP/3,QUIC,TLS 1.3 的新特性),

NaiveProxy通通代碼rebase 即可自動承最新的安全特性與性能優化.

1.2横建系統(BuildSystem)​

NaiveProxy 的模建深度集成尬 Chromium 的 GN(Generate Ninja)系统中。在sr c/net/BUILD.gn中,我们可以看到其定裁: (aATeu1qe1naxa sources = [ "tools/naive/nalve_protocol.cc*, 其他核心文件 1 = sdap 强接Chronium核心螺结序 "net", 键接Chroniun基硬座(馥程,内存管理) "//base", "//url", 建接URL解析罩

这意味著NaiveProxy二进制文件本質上就是由GoogLe的编温键生出来的,速端参数 優化都奥Chrome 保持一致。 協定羲與線路格式(ProtocolInternals) 这是NaiveProxy能狗實现致装的核心技術。即使流量经返TLS加密,數據包長度 (PacketLength)依然是明文可見的。传统的随道往往忽路了这一點,導致被流量分 析模型滋别。

2.1流量填充機制(Padding Mechanism)​

在源碼 src/net/tools/naive/naive_padding_franer.cc 中,NaiveProxy 黄现了一套字 前级的填充機制。 常速接建立,封於前8個数據包(涵蒸了TLS提手完墨後的HTTP/2设置帕與首個清 求),媒言强行插入填充数據。 線路格式(Wire Format)到底是怎檬的?很多人maive_protocal.h裡注释摔的结福 感到困恶。實际上,C++中為了證免内存封密問题,通常不會直接傳輸结體,而是逐字前 客入,真實的二进制流结標如下: L.每個HTTP/2 DATA帧的负鞋(PayLoad)被重新封装:

  • 2字廊:真實数擦侵度(Big Endian)。

  • 1字:填充侵度(Padding Size,投為 P)。

  • N字:真實数據

  • P字廊:全θ填充数

2.遍個P是一個[0,255]赢随的髓機数(由base::randInt生成)。遍意味著,哪​

怕原本是固定长度的握手包,經過这唇”充氯“後,长度也會得随機不可预测。

3.封装:上述二进制流被放入福革的HTTP/2DATA帧中俩输。​

1.外:HTTP/2领再被 TLS1.3 加密。​

果:中開人投借看到的只是一德标弹的、長度随机的TLS流量,無法遵遇包長度特微进行额 Bl。

2.2應用前置(Application Fronting)​

為了防繁主勐探测(Active Prob1ng ),Na1veProxy 探用了Application Fronting 架横。通遇部署Caddy(Web Server)进行分流 源碼src/net/tools/nalve/http_proxy_server_socket.cc展示了服榜端校验退辑: 1//罐取求验中的Proxy-Authorzation proxy_auth = headers.GetHeader(HttpRequestHeaders:kProxyAuthorization) 4// 翼预证的 Basic Auth 哈希比對 5 if (proxy auth != basic_auth_) { return ERR_INVALID_ARGUMENT; // 返图端, Coddy 回落到 filc_scrVcr

  • 场景A:外部摄描/爬数

  • 發送標HTTPS請求,但不带密碼(或密碼錯误)。

  • Caddy判定爲非法代理請求->路由到静文件服器。

  • 果:描者收到一個真實的index.html網真。網絡行為特微顯示這是一個正常的

Web服務。

  • 場景B:Naive客户端

  • 發送請求,頭部包含Proxy-Authorization:Basic<hash>。

  • Caddy驗證通過->路由到naive代理模瑰。

  • 結果:建立蔽隧道,進行跨網絡通信。

傳輸層協對比一HTTPSVSQUIC 在config.json中配置的協頭(https://或quic://)直接决定了Chromium網 絡機的行為。

3.1 HTTPS (TCP + TLS 1.3)​

  • 解發件:proxy:"https://..."

  • 底層實現:觸發ProxyServer::SCHEME_HTTPS。Chromium建立TCP連接->TLS

握手->HTTP/2CONNECT。

  • 技術特點:

  • 塞控制:默使用BBR(Google出品的塞控制算法),在複雜網絡環境下比傳統

CUBIC更好。

  • 穩定性:TCP與互聯網基設施兼容性最好,連營商QoS侵先級通常较高。

  • 缺陷:無法避免隧頭阻塞(HOLBLocking)。如果底層TCP丢了一個包,整個

HTTP/2隧列都要等待重傅,導致高延場景下出現抖動。

3.2 QUIC(UDP +HTTP/3)​

  • 解發件:proxy:"quic://..."

  • 底層實現:觸發ProxyServer::SCHEME_QUIC。Chromium建立UDP連接->QUIC

握手->HTTP/3CONNECT。

  • 技術特點:

  • 0-RTT連接:基於UDP,不需要TCP的三次握手,建立連接極快。

  • 獨立流控制:解决了TCP的隧頭阻塞問题。一個流丢包不會影響其他流(例如多路復用

時的互不干)。

  • 連接移(ConnectionMigration):客户端IP化(如網絡切換)時,QUIC

連接不會中。

  • 缺陷:UDPQoS策略。部分運營商網絡會對UDP持續流量進行限速或丢包抑制(判

為P2P下载或攻撃流量)。若發現連接不畅,建切换回HTTPS模式。 常見隧道協横向測(ComparativeAnaLysis) NaiveProxy在協混淆领域的表現如何?我們將其與其他常見協進行技術維度的對比: Protocol S ProtocolT ProtocolV NaiveProxy 维度 (Shadowso (VMess) (Trojan) cks) Chrome Network St Go net/htt 私有協 私有協(TC (TCP/mK 傅翰層 P/UDP) p (H2) CP/WS) ack (H2/H3) 较差(需依赖uTL TLS

一般(Go語​

無(通常不走 完美(Chrome

一致)​

指紋 言特微) S等外部庫) TLS) 無(長度特微 Paddi 随機长度填充(前8 無 無 包) 明) ng 完美(Caddy强分 優秀(Nginx 抗主動 较差(容易被

一般(路径分流)​

流) 探測) 探测 分流) 性能 極低(Rust/ 低(C++Native) 低(Go) 中(GoGC開) 銷 C) 部署 高 中 中 低 度 结:

  • NaiveProxy是目前匿性與抗干摄能力强的方案,適合對抗深度包检測技術。

  • 對於需要極致吞吐量且網絡環境较為寬的場景,其他輕量級協可能仍有其優势。

NaiveProxy亚不是一個網絡工具,它是一種協偽装技術的致體現。 其他的方案在辛苦地試模凝测質器的行為,修補TLS指紋的漏洞,而NaiveProxy直接使 用了器本身的核心代碼。這不保證了流量特微的完美融合,更站在了Google强大工程 能力的肩膀上,獲取了最先進的網絡傅輸性能。 對於追求極致穩定、安全與隐私保護的技術人員而言,NaiveProxy無疑是一個值得深入研究 的對象。

原始排版图​

NaiveProxy 深度剖析：基於 Chromium 內核的極致流量偽裝藝術：微信公众号导出原始排版图