用 Go uTLS 构建随机化 TLS 指纹客户端——绕过 Cloudflare 的反爬虫检测

在自动化访问被 Cloudflare 保护的站点时，最大的障碍往往不是 IP 封禁或验证码，而是 TLS 指纹检测。Cloudflare 会深入分析每个连接的 TLS Client Hello 报文特征，一旦发现指纹不属于真实浏览器，请求就会被直接拦截或降权。

本文分享一个实战中的解决方案：用原生 Go 语言编写一个共享库，通过 uTLS 实现随机化的 Chrome TLS 指纹，并以 HTTP/2 协议发起请求，从而最大限度地模拟真实浏览器行为。

为什么标准 HTTP 客户端会被识别？

当你用 Python 的 requests、Java 的 OkHttp 或 Go 标准库的 net/http 发起 HTTPS 请求时，TLS 握手阶段的 Client Hello 报文会暴露大量特征：

  • Cipher Suites 顺序：不同客户端的密码套件排列顺序不同
  • TLS 扩展列表：扩展的种类和顺序是强特征
  • 支持的曲线和点格式：椭圆曲线参数的选择
  • ALPN 协议列表：HTTP/2 (h2) 和 HTTP/1.1 的协商方式

Cloudflare 收集了几乎所有主流浏览器和 HTTP 库的 TLS 指纹。比如 Go 标准库的 crypto/tls 有着非常独特的 Cipher Suites 顺序和扩展排列，根本无法冒充浏览器——哪怕你把 User-Agent 伪装成了 Chrome。换言之，Cloudflare 的检测维度是 TLS 层而非 HTTP 层，User-Agent 字段的伪造对 TLS 指纹识别毫无影响。

JA3 与 JA4：TLS 指纹的量化算法

业界用标准化的算法将 Client Hello 特征提取为可比对的指纹值：

JA3（2017，Salesforce 提出）将 Client Hello 中的 5 个字段拼接后取 MD5 哈希：

1
JA3 = MD5(TLSVersion, CipherSuites, Extensions, EllipticCurves, ECPointFormats)

JA3 的局限在于它直接使用扩展的原始顺序。2023 年初，Chrome 108 开始对 TLS 扩展列表进行随机排列（Extension Permutation），同一版本的 Chrome 在每次连接时扩展顺序都不同。16 个扩展的全排列约为 16! ≈ 2×10¹³ 种组合，JA3 在 Chrome 上的区分能力急剧下降。

JA4（2023，FoxIO 提出）针对这一变化做了关键改进：

1
JA4 = (协议)(TLS版本)(SNI)(密码套件数)(扩展数)(ALPN)_排序后密码套件哈希_排序后扩展哈希

JA4 在哈希前先对 Cipher Suites 和 Extensions 进行排序归一化，无论客户端如何随机化扩展顺序，排序后的结果始终一致。同时 JA4 引入了 ALPN、SNI、协议类型等额外维度，产生一个 36 字符的结构化标识符。目前 Cloudflare、Akamai 等主流 CDN/WAF 均已集成 JA4 作为检测标准。

Go 的 TLS 指纹已被主动针对

值得注意的是，Go 标准库的 TLS 指纹问题并非理论风险。在反审查领域，GFW（Great Firewall）已经明确针对 Go 的 TLS 指纹进行识别和封锁。据 XTLS 项目作者 RPRX 在 XTLS/BBS#16 中确认，GFW 能够通过 Client Hello 特征直接区分 Go crypto/tls 与真实浏览器的流量。

这意味着所有基于 Go 标准 TLS 库的程序——无论是代理工具、爬虫还是 API 客户端——在面对具备 TLS 指纹检测能力的系统时，都会因为 Go 特有的 Cipher Suites 排列、扩展列表结构和椭圆曲线参数选择而被识别。Cloudflare 的 Bot Management 同样具备类似的检测能力。这正是我们选择 uTLS 的直接原因。

uTLS：在 Go 中复刻 Chrome 的 TLS 指纹

uTLS 是 Refraction Networking 团队维护的一个 Go 库，它是标准 crypto/tls 的一个 fork，核心能力是模拟任意浏览器的 TLS Client Hello 指纹。

核心原理

uTLS 预置了多个浏览器的 Client Hello 模板（Chrome、Firefox、Safari 等），在 TLS 握手时，用这些模板替代 Go 默认的 Client Hello 生成逻辑。这意味着服务器看到的 TLS 握手特征和真实的 Chrome 浏览器几乎一模一样。

在我们的实现中，使用的是 HelloChrome_Auto 模式：

1
utlsConn := utls.UClient(tcpConn, config, utls.HelloChrome_Auto)

HelloChrome_Auto 当前映射到 HelloChrome_133，会自动选择对应版本 Chrome 的完整 TLS 指纹配置。以下是 Chrome 133 Client Hello 的关键参数：

Cipher Suites（按 Chrome 原始顺序）：

1
2
3
4
5
6
7
8
9
10
11
12
TLS 1.3 套件（优先）：
├── 0x1302  TLS_AES_256_GCM_SHA384
├── 0x1303  TLS_CHACHA20_POLY1305_SHA256
└── 0x1301  TLS_AES_128_GCM_SHA256

TLS 1.2 向后兼容套件：
├── 0xc02c  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
├── 0xc02b  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
├── 0xc030  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
├── 0xc02f  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
├── 0xcca9  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
└── 0xcca8  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Supported Groups（密钥交换曲线）：

1
2
3
4
├── X25519MLKEM768（后量子混合密钥交换，Chrome 131+ 引入）
├── X25519
├── P-256
└── P-384

其中 X25519MLKEM768 是 Chrome 较新版本加入的后量子密钥协商算法，使用 ML-KEM（前身为 CRYSTALS-Kyber）与 X25519 的混合方案。这个参数在 Go 标准库和多数 HTTP 客户端中完全不存在，是一个极强的区分特征。

Signature Algorithms：ecdsa_secp256r1_sha256、rsa_pss_rsae_sha256、rsa_pkcs1_sha256 等，顺序和种类均与 Chrome 保持一致。

ALPN：h2, http/1.1（优先协商 HTTP/2）

GREASE 随机化——关键的反检测手段

GREASE（Generate Random Extensions And Sustain Extensibility）是 RFC 8701 定义的一种机制。真实的 Chrome 浏览器会在 Client Hello 中随机插入保留的”垃圾”值：

1
2
3
4
5
Client Hello 中随机插入保留值：
├── Cipher Suite: 0x0A0A（GREASE值，每次不同）
├── Extension: 0x1A1A（GREASE值，每次不同）
├── Supported Group: 0x2A2A（GREASE值，每次不同）
└── ALPN Protocol: GREASE值

这些 GREASE 值的意义在于：

  1. 防止指纹固化：每次握手的 Client Hello 都略有不同，让基于静态模式匹配的检测失效
  2. 符合 Chrome 真实行为：真实的 Chrome 本身就会发送 GREASE 值
  3. 保持协议兼容性：服务器应当忽略不认识的 GREASE 值

uTLS 的 HelloChrome_Auto 内置了 GREASE 随机化支持，每次 TLS 握手都会生成不同的 GREASE 值，完美模拟了 Chrome 的这一行为。

Extension Permutation——扩展顺序随机化

从 Chrome 106 开始，Chrome 在每次 TLS 连接时随机打乱扩展列表的顺序（pre_shared_key 除外，RFC 8446 要求它必须在最后）。这一机制与 GREASE 互补：

  • GREASE：在固定位置插入随机值
  • Extension Permutation：将扩展列表做随机排列

两者结合后，同一台机器上同一版本的 Chrome 在每次连接时产生的 Client Hello 报文都不同，使得基于静态指纹数据库的精确匹配变得不可能，检测方必须转向排序归一化后的 JA4 算法。

uTLS 从 HelloChrome_106_Shuffle 版本开始支持扩展排列，HelloChrome_Auto（当前映射 133）默认启用。

ECH GREASE——Encrypted Client Hello 的兼容性填充

Encrypted Client Hello（ECH）是 TLS 1.3 的一个扩展，用于加密 Client Hello 中的敏感元数据（主要是 SNI）。Chrome 即使在目标服务器不支持 ECH 的情况下，也会在 Client Hello 中携带一个伪造的 ECH 扩展（即 ECH GREASE），其内容为随机生成的密文。

这意味着如果你的客户端不发送 ECH 扩展，Client Hello 中就会缺失这个字段，与真实 Chrome 产生结构性差异。uTLS 在较新版本的 Chrome 模板（如 HelloChrome_120 及之后）中已包含 ECH GREASE 支持。

静态指纹 vs 动态特征：uTLS 的能力边界

需要明确的是，uTLS 的模拟范围仅限于静态指纹——即 Client Hello 报文中的固定参数。在 TLS 连接的完整生命周期中，还存在大量 uTLS 无法覆盖的动态特征：

维度 静态指纹（uTLS 覆盖） 动态特征（uTLS 不覆盖）
Client Hello 参数 Cipher Suites、扩展列表、Supported Groups、ALPN、GREASE 值 —
TLS 握手行为 — Server Hello 响应后的处理时序、TLS record 的分片大小与切换策略
TLS 会话层 — Session Resumption / PSK 的动态协商行为、各阶段的 timeout 特征
TCP 层交互 — 握手消息的 TCP 分包/粘包模式

这一局限源于根本性的技术约束：Go 的 TLS 运行时是 crypto/tls（即使被 uTLS fork 后），其内部的 record layer 实现、状态机、内存管理等行为与 Chrome 使用的 BoringSSL 存在本质差异。正如 XTLS 项目作者 RPRX 所指出的：除非将 BoringSSL 整体翻译为 Go，否则动态特征的完整模拟不可能实现。

这也是反审查社区所说的**”鹦鹉问题”（Parrot Problem）**的核心：你可以让 Go 程序在 Client Hello 阶段”说”Chrome 的话（静态指纹），但在后续的交互行为中它仍然”走路像 Go”（动态特征）。目前 Go 生态中没有比 uTLS 更好的原生替代方案，而主流代理内核和网络工具选择 Go 语言的原因在于其开发效率、跨平台编译和分发的便利性——Go 无法轻易集成 Chromium 或 Nginx 的原生网络栈，这是语言选型带来的先天取舍。

对于我们的 Cloudflare 绕过场景，这一局限的实际影响有限：Cloudflare 的 Bot Management 主要依赖 Client Hello 静态指纹（JA3/JA4）和 HTTP 层特征进行判定，对 TLS 动态特征的深度分析在商业 CDN 的大规模流量处理中成本过高。但在面对国家级审查系统时，静态指纹的正确性只是必要条件而非充分条件。

架构设计：Java → JNA → Go 三层调用链

在实际的项目中，业务逻辑是用 Java（Spring Boot）编写的，但 Java 生态没有成熟的 TLS 指纹模拟方案。因此我们选择了跨语言调用的架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌──────────────────────────────────────────────────────┐
│  Java 应用层 (Spring Boot)                            │
│  ├── DiscordHttpClient（构建请求头、管理Cookie）       │
│  └── UTlsHttpClient（OkHttp Request → JSON 序列化）   │
└────────────────────┬─────────────────────────────────┘
                     │ JNA (JSON 字符串传递)
                     ▼
┌──────────────────────────────────────────────────────┐
│  Go 共享库 (libtls_client.so)                         │
│  ├── main.go（CGO 导出函数，JSON 解析）               │
│  ├── client_pool.go（连接池，复用 HTTP/2 连接）       │
│  └── http_client.go（uTLS + HTTP/2 Transport）        │
└────────────────────┬─────────────────────────────────┘
                     │ HTTPS (TLS 1.3 + HTTP/2)
                     ▼
┌──────────────────────────────────────────────────────┐
│  目标服务器 (Cloudflare → Discord API)                │
└──────────────────────────────────────────────────────┘

Go 共享库的导出接口

Go 通过 CGO 编译为 .so 共享库，仅暴露三个函数：

1
2
3
4
5
6
7
8
//export MakeHttpRequest
func MakeHttpRequest(requestJson *C.char) *C.char

//export FreeString
func FreeString(str *C.char)

//export GetVersion
func GetVersion() *C.char

核心思路是用 JSON 作为跨语言通信协议——Java 端将请求序列化为 JSON 字符串，通过 JNA 传入 Go 函数；Go 执行 HTTP 请求后，将响应序列化为 JSON 返回。这种设计避免了复杂的 C 结构体映射，简单可靠。

强制 HTTP/2 传输

HTTP/2 是现代浏览器的默认协议。如果你的客户端还在用 HTTP/1.1，这本身就是一个异常信号。我们的 Go 客户端强制使用 HTTP/2：

1
2
3
4
5
6
h2Transport := &http2.Transport{
    DialTLS: func(network, addr string, cfg *tls.Config) (net.Conn, error) {
        return dialTLSWithUtls(ctx, network, addr, proxyConfig)
    },
    DisableCompression: false,
}

http2.Transport 的 DialTLS 回调被替换为我们自己的 dialTLSWithUtls 函数，这样 HTTP/2 协议层和 uTLS 指纹层就无缝组合在了一起。同时在 uTLS 配置中将 ALPN 设置为仅 h2：

1
2
3
4
5
config := &utls.Config{
    ServerName: host,
    MinVersion: tls.VersionTLS12,
    NextProtos: []string{"h2"},
}

HTTP/2 帧级指纹

HTTP/2 层面同样存在指纹检测。Akamai 在 Black Hat EU 2017 提出了 HTTP/2 被动指纹方案，通过分析连接建立阶段的帧参数来识别客户端实现。其指纹格式为：

1
SETTINGS[;] | WINDOW_UPDATE | PRIORITY[,] | Pseudo-Header-Order

四个组成部分分别对应：

  1. SETTINGS 帧：连接初始化时客户端发送的参数集合，包括 HEADER_TABLE_SIZE、ENABLE_PUSH、MAX_CONCURRENT_STREAMS、INITIAL_WINDOW_SIZE、MAX_FRAME_SIZE、MAX_HEADER_LIST_SIZE
  2. WINDOW_UPDATE 帧：客户端在连接建立后发送的流量控制窗口增量值
  3. PRIORITY 帧：流优先级和依赖关系的声明
  4. 伪头部顺序：:method、:authority、:scheme、:path 的排列顺序

Chrome 的 HTTP/2 指纹（以 Chrome 133 为例）：

1
1:65536;2:0;4:6291456;6:262144 | 15663105 | 0 | m,a,s,p

各参数含义：

参数 Chrome 值 含义
HEADER_TABLE_SIZE (0x1) 65536 HPACK 头部压缩表大小
ENABLE_PUSH (0x2) 0 禁用服务器推送
INITIAL_WINDOW_SIZE (0x4) 6291456 初始流量控制窗口约 6MB
MAX_HEADER_LIST_SIZE (0x6) 262144 头部列表上限 256KB
WINDOW_UPDATE 15663105 会话级窗口增量约 15MB
PRIORITY 0 不发送 PRIORITY 帧
Pseudo-Header Order m,a,s,p :method, :authority, :scheme, :path

而 Go 标准库 golang.org/x/net/http2 的默认参数差异显著：

参数 Chrome Go 默认
HEADER_TABLE_SIZE 65536 4096
INITIAL_WINDOW_SIZE 6291456 4MB (4194304)
MAX_CONCURRENT_STREAMS 不发送 不发送
WINDOW_UPDATE 15663105 ~1MB
Pseudo-Header Order m,a,s,p m,p,s,a

需要注意的是，http2.Transport 目前不支持自定义 SETTINGS 帧参数和 WINDOW_UPDATE 增量值。在我们的实现中，TLS 层的指纹由 uTLS 完整覆盖，但 HTTP/2 帧级参数仍然使用 Go 的默认值。这是一个已知的局限——在对抗 Akamai 级别的 HTTP/2 指纹检测时，可能需要使用 curl-impersonate 等支持自定义 HTTP/2 参数的方案，或者 fork http2.Transport 修改其初始化逻辑。

在实际对 Discord（Cloudflare 代理）的测试中，TLS 指纹的正确性权重远高于 HTTP/2 帧级参数，当前方案足以通过检测。

请求头的完美伪装

仅有正确的 TLS 指纹还不够，请求头的构造同样是检测维度之一。Cloudflare 和 Discord 会检查 HTTP 请求头的内容和顺序是否符合真实浏览器的模式。

Chrome Client Hints

现代 Chrome 会在请求中携带 Client Hints 头，这是一组描述客户端能力的结构化字段：

1
2
3
4
Sec-CH-UA: "Chromium";v="138", "Not=A?Brand";v="24", "Google Chrome";v="138"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Linux"
Sec-CH-UA-Platform-Version: "6.12.0"

注意 Sec-CH-UA 中 Not=A?Brand 的格式——Chrome 每个大版本的这个字段写法都不同，这是一个强特征。如果你的请求中缺少 Client Hints 或者格式不对，会被立刻识别为非浏览器客户端。

X-Super-Properties：Discord 的隐藏指纹

Discord 有一个独特的反检测机制——X-Super-Properties 请求头。它是一个 Base64 编码的 JSON 对象，包含了完整的客户端环境信息：

1
2
3
4
5
6
7
8
9
10
{
  "os": "Linux",
  "browser": "Chrome",
  "browser_version": "138.0.7204.141",
  "os_version": "6.12.0",
  "release_channel": "stable",
  "client_build_number": 484344,
  "client_launch_id": "uuid-v4",
  "has_client_mods": false
}

其中 client_build_number 是关键——这是 Discord Web 客户端的构建版本号，会随着 Discord 前端的更新而变化。如果你发送的是一个过期的版本号，Discord 会认为你的”浏览器”太旧，触发额外的验证。

我们的系统会每 6 小时自动从 Discord 官网获取最新的 build number，保持与真实客户端同步。

浏览器指纹池

为了进一步增加随机性，系统维护了一个包含 200 个预定义 Chrome 配置的指纹池：

  • 10 个 Chrome 版本（138 ~ 142），每个版本有独立的 Sec-CH-UA 格式
  • 20 个美国城市，对应不同的时区（America/New_York, America/Chicago 等）

每个 Discord 账号会被分配一个固定的浏览器配置，确保同一账号的所有请求保持一致的指纹特征，避免同一会话中指纹突变触发风控。

连接池与性能优化

频繁创建新连接意味着频繁的 TLS 握手，这不仅慢，还不符合真实浏览器的行为模式。真实的 Chrome 会复用 HTTP/2 连接来发送后续请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var (
    clientPool = make(map[string]*HttpClient)
    poolMutex  sync.RWMutex
)

func GetOrCreateClient(config *ClientConfig, proxy *ProxyConfig, accountKey string) *HttpClient {
    key := generateClientKey(config, proxy, accountKey)
    // 读写锁保护的双重检查模式
    poolMutex.RLock()
    if client, exists := clientPool[key]; exists {
        poolMutex.RUnlock()
        return client
    }
    poolMutex.RUnlock()
    // ...创建新客户端
}

连接池的 Key 由 账号标识 + 超时配置 + 代理地址 组成，这意味着：

  • 同一账号的请求复用同一个 HTTP/2 连接（模拟真实浏览器行为）
  • 不同账号之间完全隔离（避免指纹交叉污染）
  • 代理变更时自动创建新连接（适配代理轮换场景）

性能上，首次请求（含 TLS 握手）耗时约 210-680ms，后续请求复用连接后降至 140-420ms，快了约 30-40%。

代理支持：SOCKS5 与 HTTP CONNECT

对于需要通过代理访问的场景，我们的实现支持 SOCKS5 和 HTTP CONNECT 两种代理协议。关键在于代理连接必须在 uTLS 握手之前完成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func dialTLSWithUtls(ctx context.Context, network, addr string,
    proxyConfig *ProxyConfig) (net.Conn, error) {

    var tcpConn net.Conn
    if proxyConfig != nil {
        if proxyConfig.Type == "socks5" {
            // SOCKS5 代理拨号
            dialer, _ := proxy.SOCKS5("tcp", proxyAddr, auth, proxy.Direct)
            tcpConn, _ = dialer.Dial(network, addr)
        } else {
            // HTTP CONNECT 隧道
            tcpConn, _ = dialThroughHTTPProxy(proxyConfig, addr)
        }
    } else {
        tcpConn, _ = net.Dial(network, addr)
    }

    // 在代理建立的 TCP 连接上执行 uTLS 握手
    utlsConn := utls.UClient(tcpConn, tlsConfig, utls.HelloChrome_Auto)
    utlsConn.HandshakeContext(ctx)
    return utlsConn, nil
}

整个流程是：先通过代理建立 TCP 隧道，然后在这条隧道上执行 uTLS 握手。对于目标服务器（Cloudflare）来说，它看到的 TLS Client Hello 完全来自 uTLS，而不是代理软件，因此代理的存在不会影响 TLS 指纹的有效性。

响应的完整处理

Go 端还处理了响应的解压缩，支持 gzip、deflate、br（Brotli）、zstd 四种编码。这是因为我们在请求头中声明了：

1
Accept-Encoding: gzip, deflate, br, zstd

这和真实 Chrome 的行为完全一致。如果你只声明了 Accept-Encoding: gzip 而不支持 Brotli，这本身就是一个异常信号。

实际效果

这套方案在实际项目中运行了数月，通过对 Discord API（经 Cloudflare 代理保护）的长期请求测试，表现稳定。关键指标：

  • 协议层面：所有请求均以 HTTP/2 协议完成（protocol: "h2"）
  • TLS 层面：每次握手的 Client Hello 特征符合 Chrome 最新版本
  • 请求头层面：完整的 Chrome Client Hints + Discord 专有头
  • 会话层面：Cookie 持久化 + 连接复用，模拟真实的浏览会话

总结

绕过 Cloudflare 等现代 WAF 的 TLS 指纹检测，核心思路可以归纳为：

  1. TLS 层：使用 uTLS 模拟 Chrome 的 Client Hello 指纹，覆盖 Cipher Suites、扩展列表、Supported Groups、Signature Algorithms 等全部参数，并启用 GREASE 随机化、扩展排列随机化和 ECH GREASE
  2. 协议层：强制 HTTP/2，注意 SETTINGS 帧、WINDOW_UPDATE、伪头部顺序等帧级参数同样是检测维度（当前方案使用 Go 默认值，在 Cloudflare 场景下足够，但在 Akamai 等更严格的检测下可能需要定制）
  3. 应用层：精心构造请求头，包括 Client Hints、时区、语言等所有细节
  4. 会话层：连接复用 + Cookie 持久化，保持与真实浏览器一致的会话生命周期
  5. 指纹多样性：维护浏览器指纹池，确保不同账号有不同但会话内一致的指纹

以上各层缺一不可。只做 TLS 指纹模拟但忽略请求头，或者只构造请求头但使用默认的 TLS 库，都会在某一检测维度上暴露。

检测对抗的演进趋势

从更宏观的视角来看，TLS 指纹检测只是对抗链条中的一环。参考反审查领域的实践经验（参见 XTLS/BBS#19 中 RPRX 的分析），检测手段存在一个明确的升级路径：

1
2
静态 TLS 指纹匹配 → TLS 动态行为分析 → HTTP/2 帧级指纹
→ 流量时序/统计特征 → SNI 白名单 → IP 白名单

每一级升级都意味着更高的检测成本和更大的误伤范围。对于 Cloudflare 这样的商业 CDN/WAF，其检测策略需要在准确率与大规模流量处理性能之间取得平衡，因此当前主要停留在 Client Hello 静态指纹 + HTTP 层特征分析的阶段。而国家级审查系统（如 GFW）则可能推进到更深层次的动态特征分析。

这意味着本文的方案在绕过商业 WAF 的反爬虫检测场景中是有效且充分的，但不应将其等同于对任意审查系统的通用解决方案。指纹模拟本质上是一种”足够好”的工程近似，其有效性取决于具体对手的检测深度和投入产出比考量。

本文涉及的技术仅用于学术研究和合法的自动化测试场景，请遵守相关平台的服务条款。

技术分享
#Go #TLS #HTTP/2 #反检测 #Cloudflare
用 Go uTLS 构建随机化 TLS 指纹客户端——绕过 Cloudflare 的反爬虫检测
https://blog.wolfric.cn/go-utls-bypass-cloudflare-tls-fingerprint/
作者
WolFric
发布于
2026年2月23日
许可协议