Separate WebView2 User-Data Folders for Different Proxy Routes

A proxy supplied through AdditionalBrowserArguments becomes part of the WebView2 browser process’s launch command. Editing that options object later does not rewrite the running process’s command line.

For a .NET application creating an independent route, choose an application-owned user-data folder before initializing the control:

var options = new Microsoft.Web.WebView2.Core.CoreWebView2EnvironmentOptions
{
    AdditionalBrowserArguments = "--proxy-server=http://proxy.example:8080"
};
var environment = await Microsoft.Web.WebView2.Core.CoreWebView2Environment
    .CreateAsync(userDataFolder: profileFolder, options: options);
await browser.EnsureCoreWebView2Async(environment);

profileFolder is a writable application-selected directory, and browser is the existing uninitialized WebView2 control. Run initialization through the UI’s normal async lifecycle. The HTTP proxy list offers candidates for the launch flag when that profile will make permitted public-site requests.

A new options object is not a new process

Environments associated with the same user-data folder can share the browser process. Creating another object with that folder is not a way to assign it conflicting launch-time proxy flags.

For simultaneous policies through this launch mechanism, use separate environments with separate folders. That also separates their website data; a second environment does not automatically inherit the first one’s login state.

To reuse the original folder with new launch settings, close the controls sharing its process and coordinate shutdown before initializing a replacement. Disposing one control while another keeps the process alive is not that transition.

Keep the environment and folder lifecycle with the application. Creating a fresh browser process for every request can be much more expensive than maintaining a small deliberate set of routes.