For the headless_chrome Rust crate, the browser launch setting selects an HTTP intermediary. The tab’s Fetch handler supplies the account when Chromium asks for it:

let proxy = "http://proxy.example:8080";
let options = headless_chrome::LaunchOptions::default_builder()
    .proxy_server(Some(proxy))
    .build()?;
let browser = headless_chrome::Browser::new(options)?;
let tab = browser.new_tab()?;

tab.enable_fetch(None, Some(true))?;
tab.authenticate(Some(proxy_user), Some(proxy_password))?;
tab.navigate_to("https://www.example.org/")?;
tab.wait_until_navigated()?;

The enclosing function propagates errors, and proxy_user and proxy_password are String values supplied by the application’s existing account configuration. Set up authentication before navigation can trigger the challenge.

enable_fetch’s second argument enables authentication events. Chromium does not treat user information embedded in --proxy-server as this credential exchange.

Keep the browser and tab alive for the workload. If custom Fetch interception is also installed, define who continues paused requests and answers challenges; leaving a paused request unresolved can stall navigation.

This simple tab authentication setup assumes the intended proxy challenge. A workflow with unrelated origin authentication needs explicit challenge scoping rather than reusing the intermediary account for every server. Chromium’s SOCKS5 username/password limitation is also separate from this HTTP authentication path.

Mikanda mikatakata