wreq：实践指南

面对实际交付，我看wreq的重点不在星标，而在这项能力：符合人体工程学、具有隐私意识的 Rust HTTP 客户端。实际做日常自动化时，经常会碰到输入边界、依赖和失败处理如果不清楚就很难稳定复用，所以功能列表并不能代替验证。更实际的做法是用一项范围明确的真实任务完成最小试跑，同时核对配置时间、输出质量、异常信息和维护痕迹，不要直接在关键项目上。对愿意先做小范围验证并复查原始文档的团队来说，这个仓库值得继续验证；只求即装即用的人则要先看维护成本。

雷克

![Discord ch@t][discord-badge]

帮助我与 赞助我的 GitHub 的开源共享无缝协作

符合人体工程学的模块化 Rust HTTP 客户端，用于高保真协议匹配，具有可定制的 TLS、JA3/JA4 和 HTTP/2 签名功能。

特点

• 普通主体，JSON，urlencoded，多部分
• HTTP 拖车
• 饼干店
• 重定向策略
• 原始标题
• 轮换代理
• 塔式中间件
• WebSocket 升级
• HTTPS 通过 BoringSSL
• HTTP/2 超过 TLS 奇偶校验
• 证书存储（CAs 和 mTLS）
• 多个运行时（Tokio、Compio）

示例

以下示例使用 Tokio 运行时，通过将其添加到 Cargo.toml 来启用可选功能：

[dependencies]
tokio = { version = "1", features = ["full"] }
wreq = "6.0.0-rc"
wreq-util = "3.0.0-rc"

然后是代码：

use wreq::Client;
use wreq_util::Emulation;

#[tokio::main]
async fn main() -> wreq::Result<()> {
    // Build a client
    let client = Client::builder()
        .emulation(Emulation::Safari26)
        .build()?;

    // Use the API you're already familiar with
    let resp = client.get("https://pingly.us.kg/api/all").send().await?;
    println!("{}", resp.text().await?);
    Ok(())
}

行为

• HTTP/1 优于 TLS

在 Rust 生态系统中，大多数 HTTP 客户端依赖于 http 库，该库性能良好，但不保留标头大小写。这会导致一些 WAFs 拒绝带有小写标头的 HTTP/1 请求（请参阅 讨论）。 wreq 通过完全支持 HTTP/1 标头区分大小写来解决此问题。

• HTTP/2 优于 TLS

由于 TLS 加密的复杂性以及 HTTP/2 的广泛采用，浏览器指纹（例如 JA3、JA4 和 Akamai）无法使用简单的指纹字符串进行可靠模拟。 wreq 不是解析和模拟这些基于字符串的指纹，而是提供对 TLS 和 HTTP/2 扩展和设置的细粒度控制，以实现精确的浏览器行为模拟。

• 设备仿真

TLS 和 HTTP/2 指纹在各种浏览器模型中通常是相同的，因为这些底层协议的发展速度慢于浏览器发布周期。 wreq-util 中维护着 100 多个浏览器设备仿真配置文件。

建筑

与 openssl-sys 一起编译可能会导致与 boringssl 发生符号冲突，从而导致 链接失败，并且在 Linux 和 Android 上，可以通过启用 prefix-symbols 功能来避免这种情况。

安装 BoringSSL 构建依赖项 并使用以下命令构建：

sudo apt-get install build-essential cmake perl pkg-config libclang-dev musl-tools git -y
cargo build --release

此 GitHub 操作 工作流程 可用于在 Linux、Windows 和 macOS 上编译项目。

服务

通过寻求 商业支持 来帮助维持这个开源项目的持续开发。接受私人指导、专家评审或直接联系维护人员，并根据您的需求提供个性化的技术帮助。

荣誉

的硬分叉要求。