Playwright Workspace ignores BrowserNewContextOptions.Proxy when using ConnectAsync

Question

Playwright Workspace ignores BrowserNewContextOptions.Proxy when using ConnectAsync

Mateusz Baranowicz 0

Hello,

I would like to clarify whether custom proxy configuration is currently supported in Azure Playwright Workspaces when connecting to a remote browser using ConnectAsync.

We are using Playwright Workspaces with a remote browser connection:

var headers = new Dictionary<string, string>
{
    ["Authorization"] = $"Bearer {accessToken}"
};

var options = new BrowserTypeConnectOptions
{
    Headers = headers
};

await using var browser = await playwright.Chromium.ConnectAsync(serverWsAddress, options);

await using var context = await browser.NewContextAsync(new BrowserNewContextOptions
{
    Proxy = new Proxy
    {
        Server = "http://1.2.3.4:9999",
        Username = "invalid",
        Password = "invalid"
    }
});

var page = await context.NewPageAsync();

var response = await page.GotoAsync("https://api.ipify.org?format=json");

Console.WriteLine(await response!.TextAsync());

The behavior we observe is that the request succeeds even when an invalid proxy server and invalid credentials are configured. The returned IP address is the Playwright Workspace egress IP rather than the configured proxy IP.

Based on our understanding, we would expect one of the following:

Browser traffic should be routed through the configured proxy.

The request should fail when the proxy configuration is invalid.

Instead, it appears that the proxy configuration is ignored.

We are fairly certain this scenario worked previously in Azure Playwright Workspaces. When invalid proxy credentials were provided, navigation failed as expected. When valid proxy settings were configured, browser traffic was successfully routed through the proxy server and the public IP returned by services such as api.ipify.org matched the proxy IP rather than the Playwright Workspace IP.

Currently, both valid and invalid proxy configurations appear to be ignored, and browser traffic always uses the Playwright Workspace egress IP.

Could you please confirm:

Is BrowserNewContextOptions.Proxy officially supported when using Playwright Workspaces with ConnectAsync?

Has there been any recent change in behavior regarding proxy support?

Is there any additional configuration required to route Playwright Workspace browser traffic through a custom HTTP/SOCKS proxy?

Thank you.

0 comments

1 answer

Your answer

Answer 1

Hello Mateusz Baranowicz,

Greetings! Thanks for raising this question in Q&A forum.

What you are describing matches a known limitation rather than something specific to your code. When you use ConnectAsync to attach to an already running remote browser (which is exactly how Playwright Workspaces works), the per context Proxy option behaves differently than when you launch a browser locally. Playwright's own documentation notes that for Chromium, the browser needs to be started with the proxy enabled at the launch level for a per context Proxy override to actually take effect, if the browser was started without that, the context level Proxy setting is silently ignored rather than throwing an error. Since Playwright Workspaces controls how the remote browser is started on their infrastructure, you do not have control over that launch step, which lines up exactly with what you are seeing, the traffic just falls back to the workspace's own egress IP instead of failing.

Here is what I would check and do.

Confirm this is not a code issue on your side Your code itself looks correct, Proxy with Server, Username and Password is the right shape for BrowserNewContextOptions. This is not something you can fix by changing how you call NewContextAsync.

Be aware this is a documented Playwright SDK limitation too Separate from the Azure service itself, there is an existing open issue in the Playwright .NET project about proxy configuration not being supported when using ConnectAsync or ConnectOverCdpAsync against a remote browser. This affects any remote browser connection scenario, not just Playwright Workspaces specifically.

Use exposeNetwork only for the opposite direction Playwright Workspaces does have an exposeNetwork setting in playwright.service.config.ts, but that is used to expose your local machine's network (like localhost) to the cloud browser, it is not a mechanism for routing the cloud browser's outbound traffic through your own custom proxy. So this will not solve what you are trying to do.

Treat this as a behavior change that needs official confirmation Since you mention this previously worked and failed loudly with invalid credentials before, but now silently passes through, this looks like a possible regression on the service side rather than expected behavior. I would recommend opening a formal support request through the Azure Playwright Workspaces support channel so the product team can confirm whether proxy support was intentionally changed, since this is the kind of definitive yes or no answer that needs to come from the team that controls how the remote browsers are launched.

You can find the general configuration and troubleshooting reference here: https://learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/troubleshoot-test-run-failures

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.