{"id":1107,"date":"2026-10-13T19:17:27","date_gmt":"2026-10-13T16:17:27","guid":{"rendered":"https:\/\/mexela.com\/blog\/rust-reqwest-proxy\/"},"modified":"2026-10-13T20:19:37","modified_gmt":"2026-10-13T17:19:37","slug":"rust-reqwest-proxy","status":"publish","type":"post","link":"https:\/\/mexela.com\/blog\/rust-reqwest-proxy\/","title":{"rendered":"Rust reqwest Proxy Setup: Authentication, HTTPS CONNECT and TLS"},"content":{"rendered":"

To route a Rust reqwest request through a proxy, add Proxy::all(endpoint)<\/code> to a client builder, apply proxy credentials with Proxy::basic_auth()<\/code>, keep TLS validation enabled, and check the received HTTP status separately from transport errors. Make a direct baseline with ClientBuilder::no_proxy()<\/code> before diagnosing the selected proxy route.<\/p>\n

Reviewed and locally tested: October 13, 2026.<\/strong> The executed runtime was Rust 1.99.0 and reqwest 0.13.5 on Ubuntu 24.04 inside WSL2, using the Linux x86_64-unknown-linux-gnu<\/code> target. These observations do not certify native Windows, WebAssembly, older reqwest releases, or every TLS\/backend combination.<\/p>\n

Choose the client API and Cargo features<\/h2>\n
rustc --version\ncargo --version<\/code><\/pre>\n
This guide uses reqwest::blocking<\/code> for a small diagnostic program. Do not call this blocking API from within an async runtime. Existing Tokio applications should use the async reqwest::Client<\/code> and .send().await<\/code>; those application paths were not exercised by this lab. Read the official blocking API guidance<\/a>.<\/p>\n
The examples use the following exact reqwest version and feature selection. The supplied Cargo.lock<\/code> also records the resolved transitive versions; retain it for reproducible application builds and review dependencies before changing that graph.<\/p>\n
[dependencies]\nreqwest = { version = \"=0.13.5\", default-features = false, features = [\"blocking\", \"rustls\", \"socks\"] }<\/code><\/pre>\n
The rustls<\/code> feature enables TLS and socks<\/code> enables SOCKS5 support. Disabling default features here also omits automatic Windows\/macOS system-proxy integration; the loopback lab still tested environment proxy inheritance separately. This feature selection is a tested example, not a requirement for every application. Check the official feature list<\/a> and Rust installation instructions<\/a> for your platform.<\/p>\n
Run the actual tested Rust example<\/h2>\n
The Rust proxy examples ZIP<\/a> contains Cargo.toml<\/code>, Cargo.lock<\/code>, the starter, and this exact src\/bin\/article-example.rs<\/code>. Set an approved CHECK_URL<\/code>, credential-free PROXY_ENDPOINT<\/code>, and separate PROXY_USER<\/code>\/PROXY_PASSWORD<\/code> through your existing secret-management process. For example, the endpoint format is http:\/\/proxy.example:8080<\/code>; do not put credentials in the URL or shell history.<\/p>\n
cargo build --locked\ncargo run --locked --bin article-example<\/code><\/pre>\n
use reqwest::{blocking::Client, redirect::Policy, Certificate, Proxy, Url};\nuse std::{env, error::Error, time::Duration};\n\nfn run() -> Result<u16, Box<dyn Error>> {\n    let destination = Url::parse(&env::var("CHECK_URL")?)?;\n    if !["http", "https"].contains(&destination.scheme())\n        || !destination.username().is_empty() || destination.password().is_some() {\n        return Err("invalid destination".into());\n    }\n    let mut builder = Client::builder()\n        .no_proxy()\n        .connect_timeout(Duration::from_secs(2))\n        .timeout(Duration::from_secs(5))\n        .redirect(Policy::none());\n    if let Ok(endpoint) = env::var("PROXY_ENDPOINT") {\n        let endpoint = Url::parse(&endpoint)?;\n        if !["http", "https", "socks5", "socks5h"].contains(&endpoint.scheme())\n            || !endpoint.username().is_empty() || endpoint.password().is_some() {\n            return Err("invalid proxy endpoint".into());\n        }\n        let proxy = Proxy::all(endpoint)?\n            .basic_auth(&env::var("PROXY_USER")?, &env::var("PROXY_PASSWORD")?);\n        builder = builder.proxy(proxy);\n    }\n    if let Ok(path) = env::var("CA_FILE") {\n        let pem = std::fs::read(path)?;\n        builder = builder.tls_certs_merge([Certificate::from_pem(&pem)?]);\n    }\n    let client = builder.build()?;\n    Ok(client.get(destination).send()?.status().as_u16())\n}\n\nfn main() {\n    match run() {\n        Ok(status) => println!("http_status={status}"),\n        Err(_) => {\n            eprintln!("Request failed; inspect private diagnostics safely.");\n            std::process::exit(1);\n        }\n    }\n}<\/code><\/pre>\n
This example returns a numeric HTTP status after response headers and logs a fixed message if the operation fails. Interpret that status: 407<\/code> is not an accepted request simply because send()<\/code> returned a response. The separate diagnostic starter reads at most 64 KiB of response data in memory and outputs selected JSON flags without raw bodies, URLs, headers, or errors.<\/p>\n
Separate explicit routing from inherited environment settings<\/h2>\n
The displayed code starts with .no_proxy()<\/code>, disabling inherited proxies for the direct baseline. If PROXY_ENDPOINT<\/code> exists, it adds one explicit Proxy::all()<\/code> rule for HTTP and HTTPS destinations. This is a per-client configuration; other clients and browser traffic require their own settings and route checks.<\/p>\n
We also executed a separate default client that inherited HTTP_PROXY<\/code>. Another client with .no_proxy()<\/code> bypassed that inherited endpoint. An explicit proxy rule still reached the proxy when inherited NO_PROXY=*<\/code> was set. Set intentional bypass rules with Proxy::no_proxy()<\/code> when your application needs them; do not assume an environment bypass controls every explicit rule. See the official proxy API<\/a> and HTTP_PROXY, HTTPS_PROXY and NO_PROXY<\/a>.<\/p>\n
A status 200 alone does not prove which route handled the request. Our destination correlated actual accepted sockets with proxy-created upstream sockets. That establishes the loopback route used in these cases; it does not establish a commercial proxy’s public exit, country, speed, anonymity, or DNS privacy.<\/p>\n
Keep proxy and destination credentials separate<\/h2>\n
Proxy::basic_auth()<\/code> configures the proxy credential layer. By contrast, client.get(url).basic_auth(destination_user, Some(destination_password))<\/code> belongs to the destination request. The lab used different random credential pairs and checked destination authentication inside CONNECT while confirming that the destination never received a Proxy-Authorization header.<\/p>\n
An HTTP proxy connection does not encrypt Basic proxy authentication by itself, even when the destination is HTTPS through CONNECT. Choose an approved endpoint transport and network path. Wrong or absent HTTP proxy credentials produced a received 407 in our fixture. Wrong or absent CONNECT credentials failed before a destination request; the fixture recorded the tunnel’s 407, while reqwest returned a transport error with no destination HTTP status. Do not invent a destination 407 when no destination response was received. Continue with proxy authentication<\/a>.<\/p>\n
Keep TLS strict through HTTPS CONNECT<\/h2>\n
An http:\/\/<\/code> proxy can tunnel an HTTPS destination with CONNECT. The destination scheme and the proxy transport are separate settings. Our authenticated proxy accepted CONNECT, but strict default certificate validation then rejected the disposable untrusted certificate; no destination HTTP request arrived.<\/p>\n
After adding the fixture’s approved CA with Certificate::from_pem()<\/code> and ClientBuilder::tls_certs_merge()<\/code>, the same destination succeeded with certificate and hostname validation still enabled. CA_FILE<\/code> is scoped to the client in this example. Obtain a real CA from your trusted administration process rather than trusting an arbitrary certificate from a failed request. We did not test TLS to an HTTPS proxy or that proxy’s certificate configuration. See reqwest’s client trust configuration<\/a> and HTTP, HTTPS and SOCKS5 differences<\/a>.<\/p>\n
SOCKS5 support depends on the build<\/h2>\n
With the socks<\/code> feature enabled, the executed build accepted an authenticated socks5h:\/\/<\/code> endpoint with the same separate credential API and strict HTTPS validation. Our destination was an IP literal. That checks authenticated tunneling and the observed route; it does not test hostname resolution, DNS leakage, or every SOCKS server’s authentication method.<\/p>\n
What the local lab actually observed<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
Executed check<\/th>\nObservation<\/th>\n<\/tr>\n<\/thead>\n
Direct HTTP\/HTTPS and authenticated HTTP forwarding<\/td>\n200; destination distinguished direct and proxy routes<\/td>\n<\/tr>\n
Environment inheritance and explicit direct\/proxy clients<\/td>\nObserved routes matched the selected client configuration<\/td>\n<\/tr>\n
Wrong or absent HTTP proxy credentials<\/td>\n407 response; no destination request<\/td>\n<\/tr>\n
Wrong or absent CONNECT credentials<\/td>\nFixture tunnel 407; reqwest transport error, no destination status<\/td>\n<\/tr>\n
Untrusted certificate, approved CA, and hostname mismatch<\/td>\nStrict TLS failed, approved-CA CONNECT succeeded, and a mismatched hostname still failed<\/td>\n<\/tr>\n
SOCKS5 and separate destination credentials<\/td>\n200 on selected routes; no proxy credential header at destination<\/td>\n<\/tr>\n
Redirect and stalled response<\/td>\n302 returned without following; 350 ms timeout measured 401 ms including helper\/client setup<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The lab passed 23 checks against owned loopback sockets, including compiling and executing the exact Rust code displayed above. Random fixture credentials were not persisted in the article, examples, or report. Temporary certificate\/private-key files were removed after execution. No production endpoint, public exit geography, commercial speed, uptime, anonymity or native Windows compatibility was measured.<\/p>\n
Read transport errors and statuses at the correct layer<\/h2>\n
Use Error::is_timeout()<\/code> and Error::is_connect()<\/code> as selected diagnostic flags, then inspect the destination status only when a response exists. These flags do not uniquely identify every TLS or tunnel cause. The official Error reference<\/a> also notes that an error can contain a full URL. Raw errors, headers, response bodies and environment dumps can reveal secrets; use controlled private diagnostics when deeper evidence is necessary.<\/p>\n
The starter configures a 2 second connection limit and a 5 second request limit, reads a bounded body, and disables automatic redirects. Our 350 ms case tested a connected server that stalled before sending a response; it does not characterize all resolvers or operating systems. Retry only after understanding the failing layer and the request’s idempotency. Reuse a configured client for an application’s normal workload instead of treating these single-request lab timings as a throughput benchmark.<\/p>\n
Frequently asked questions<\/h2>\n
Does reqwest automatically use HTTP_PROXY?<\/h3>\n
A default native client can inherit proxy environment settings. Our Linux lab observed HTTP_PROXY routing. ClientBuilder::no_proxy()<\/code> disables that inheritance for the configured client; explicit proxy rules and intentionally supplied bypass rules should be reviewed separately.<\/p>\n
Should I disable certificate checks to fix CONNECT?<\/h3>\n
No. First distinguish proxy authentication or tunnel failure from destination certificate validation. Use an approved CA only when your trust policy requires it, keeping certificate and hostname checks enabled.<\/p>\n
Can I use this blocking code inside Tokio?<\/h3>\n
Use reqwest’s async client within an async application. This guide executed a standalone blocking program; its fixture evidence does not qualify your async application or browser-based WebAssembly runtime.<\/p>\n
Continue with Developer Guides<\/a>, the testing methodology<\/a>, the route verification checklist<\/a>, and WSL2 proxy setup<\/a>.<\/p>\n
Versioned Rust source files<\/h2>\n
Use the Rust folder in the public source repository<\/a> for the example, setup instructions, exact dependency versions and a sanitized test summary. The repository is a dated snapshot of owned examples; its loopback checks do not certify a commercial endpoint or every application configuration.<\/p>\n","protected":false},"excerpt":{"rendered":"
Configure Rust reqwest proxy routing, separate credentials, strict TLS and bounded diagnostics with executed HTTP, CONNECT and SOCKS5 examples.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[189],"tags":[],"_links":{"self":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts\/1107"}],"collection":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/comments?post=1107"}],"version-history":[{"count":0,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/posts\/1107\/revisions"}],"wp:attachment":[{"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/media?parent=1107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/categories?post=1107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mexela.com\/blog\/wp-json\/wp\/v2\/tags?post=1107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}