wreq is an Apache-2.0 licensed Rust HTTP client that provides high-fidelity protocol matching through customizable TLS, JA3/JA4, and HTTP/2 signature capabilities, and it is aimed at developers building crawlers, scrapers, and censorship-resistant clients that need to look like real browsers on the wire.

What it is

wreq is an ergonomic and modular HTTP client written in Rust, distributed as the wreq crate on crates.io and documented at wreq.org. It describes itself as a client for high-fidelity protocol matching, and it exposes fine-grained control over TLS and HTTP/2 extensions and settings rather than a single opaque fingerprint string. HTTPS is handled through BoringSSL, and the client supports multiple runtimes, currently Tokio and Compio.

The concrete problem it solves is fingerprint-based rejection. In the Rust ecosystem, most HTTP clients rely on the http library, which performs well but does not preserve header case, and some WAFs reject HTTP/1 requests carrying lowercase headers, a behavior documented in a linked reqwest discussion. wreq fully supports HTTP/1 header case sensitivity, replacing that default behavior. For HTTP/2 over TLS, the maintainers argue that browser fingerprints such as JA3, JA4, and Akamai cannot be reliably emulated using simple fingerprint strings, because TLS encryption is complex and HTTP/2 is widely adopted. wreq therefore gives direct control over the underlying TLS and HTTP/2 parameters instead of parsing string-based fingerprints.

Key capabilities

• Fine-grained TLS and HTTP/2 extension and setting controls for reproducing browser wire behavior, backed by the ja3, ja4, akamai, and fingerprint topics.
• HTTP/1 over TLS with full header case preservation, which the README presents as a direct fix for WAF rejection of lowercase headers.
• wreq-util maintains more than 100 browser device emulation profiles, selected through Emulation::Safari26 and similar values.
• Body handling for plain bodies, JSON, urlencoded, and multipart payloads, plus support for HTTP Trailer.
• Operational features including a Cookie Store, Redirect Policy, Original Header handling, rotating proxies, and Tower Middleware integration.
• Protocol and identity features including WebSocket Upgrade, a Certificate Store for CAs and mTLS, and HTTP/2 over TLS parity.
• Runtime flexibility through Tokio and Compio, and HTTPS delivered via BoringSSL.

Who uses it and how

• Scraping and crawling teams whose requests are blocked by WAFs that inspect header casing or TLS handshake shape.
• Engineers reproducing a specific browser's behavior on the wire, choosing among the 100-plus device emulation profiles in wreq-util instead of hand-tuning cipher lists.
• Services that need to route traffic through rotating proxies while retaining cookies and applying Tower middleware in the same client.
• Applications requiring mutual TLS or custom certificate authorities, which use the Certificate Store rather than shelling out to an external HTTP tool.
• Teams already standardized on Tokio, or on Compio, who can select the runtime without changing client code.

Getting started

Add tokio = { version = "1", features = ["full"] }, wreq = "0.16", and wreq-util = "0.2" to Cargo.toml, then build a client with Client::builder().emulation(Emulation::Safari26).build()? and call .send().await? on a request. Compiling from source requires BoringSSL build dependencies — build-essential cmake perl pkg-config libclang-dev musl-tools git on Debian-derived systems — followed by cargo build --release, and a GitHub Actions workflow in .github/compilation-guide/build.yml covers Linux, Windows, and macOS.

How it compares

The README positions wreq against the broader Rust HTTP client ecosystem, where most clients build on the http library and inherit its header-case behavior, and it links a reqwest discussion as evidence of the resulting WAF problems. The distinction wreq draws is not breadth of API but depth of protocol control: instead of accepting or parsing string-based JA3, JA4, and Akamai fingerprints, it exposes the TLS and HTTP/2 extensions and settings that produce them. No commercial products are named as targets for replacement.

When to use it — and when not to

A self-hoster takes on the BoringSSL toolchain: the README warns that compiling alongside openssl-sys can cause symbol conflicts that lead to link failures, avoidable on Linux and Android by enabling the prefix-symbols feature. Developers who only need straightforward JSON requests over HTTPS may find a lighter client sufficient, since the emulation machinery and BoringSSL dependency exist for fingerprint-sensitive traffic. Those wanting private guidance, expert review, or direct maintainer access are directed to commercial support by email, which indicates that support otherwise runs through community channels such as the linked Discord.

[dependencies]
tokio = { version = "1", features = ["full"] }
wreq = "0.16"
wreq-util = "0.2"

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(())
}

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