Home/Blog/Mobile Proxy for Playwright MCP
Tool Integration

Mobile Proxy for Playwright MCP

Playwright MCP is the browser your AI agent drives from Claude Desktop, Cursor, or VS Code. By default it browses from your machine's IP - or your cloud box's datacenter IP. One flag routes all of that traffic through a mobile proxy instead. Here is the exact config for each client, plus the authenticated-proxy workaround the docs do not spell out.

7 min read·Last updated: July 2026

Quick Answer

Add --proxy-server to the server's args array in your MCP client config, or set the PLAYWRIGHT_MCP_PROXY_SERVER environment variable. For proxies that need a username and password, pass a JSON config file with --config and set Playwright's proxy object under browser.launchOptions.

  • The README documents http://myproxy:3128 and socks5://myproxy:8080 as example values
  • Every CLI option has an env var twin, so env blocks in MCP configs work too
  • A proxy fixes the IP layer only - the maintainers say bot-protection evasion is out of scope

This guide is about the Playwright MCP server (@playwright/mcp), the Model Context Protocol server that Microsoft describes as providing "browser automation capabilities using Playwright." It is what runs when Claude or Cursor opens a browser tab on your behalf. If you are writing Playwright scripts directly in Python or Node.js, the proxy goes into the library's launch options instead - that setup is covered in our Playwright proxy configuration guide. With MCP there is no script: the AI client launches the server for you, so everything is configured through CLI args, environment variables, or a config file.

The --proxy-server flag

Playwright MCP ships two proxy options, documented in the README's configuration table:

--proxy-server

"specify proxy server, for example 'http://myproxy:3128' or 'socks5://myproxy:8080'". Env var: PLAYWRIGHT_MCP_PROXY_SERVER

--proxy-bypass

"comma-separated domains to bypass proxy, for example '.com,chromium.org,.domain.com'". Env var: PLAYWRIGHT_MCP_PROXY_BYPASS

Per the README, these arguments "can be provided in the JSON configuration above, as a part of the "args" list" - meaning the same JSON block you already use to register the server in any MCP client. Everything the agent browses then exits through the proxy.

Claude Desktop: claude_desktop_config.json

Claude Desktop reads its MCP servers from claude_desktop_config.json. Open it via Settings, then the Developer tab, then Edit Config. On macOS the file lives at ~/Library/Application Support/Claude/claude_desktop_config.json, on Windows at %APPDATA%\Claude\claude_desktop_config.json. Add the flag and its value as two entries in args:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--proxy-server", "http://proxy.mobileproxies.org:8000"
      ]
    }
  }
}

Fully quit and restart Claude Desktop afterwards - the config is only read at launch. The same JSON shape is what the Playwright MCP README calls its "standard config" and it works unchanged in most MCP clients.

Cursor and Claude Code

Cursor uses the same structure in .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global). This example uses the environment-variable route instead of the flag - every Playwright MCP option has an env var equivalent named PLAYWRIGHT_MCP_*, and MCP clients pass an env object to the server process:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"],
      "env": {
        "PLAYWRIGHT_MCP_PROXY_SERVER": "http://proxy.mobileproxies.org:8000"
      }
    }
  }
}

In Claude Code, register the server from the terminal. The -- separator matters: everything after it is passed to the server untouched, so the proxy flag reaches Playwright MCP instead of being parsed by the Claude CLI:

claude mcp add playwright -- npx @playwright/mcp@latest \
  --proxy-server "http://proxy.mobileproxies.org:8000"

SOCKS5 works the same way in any of these: swap the value for socks5://proxy.mobileproxies.org:1080.

Authenticated proxies: the --config workaround

Here is the part the README leaves implicit. Its --proxy-server examples are plain scheme://host:port values with no credentials, and embedding user:pass@ in the URL is not a documented pattern. Playwright itself, however, documents a proxy object with server, username, and password fields for authenticated HTTP(S) proxies - and Playwright MCP exposes raw Playwright launch options through its JSON config file. So: put the credentials in a config file and point the server at it.

Save this as playwright-mcp.json somewhere stable (use an absolute path):

{
  "browser": {
    "launchOptions": {
      "proxy": {
        "server": "http://proxy.mobileproxies.org:8000",
        "username": "u_4a9c",
        "password": "p_2X7q"
      }
    }
  }
}

Then reference it from the MCP client config:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--config", "/Users/you/playwright-mcp.json"
      ]
    }
  }
}

The config schema types browser.launchOptions as Playwright's own launch options, which is where the documented proxy object lives. If you would rather keep credentials out of files entirely, IP allowlisting on the proxy side removes the need for a username and password - then the plain --proxy-server flag is all you need.

Why AI browsing needs a carrier IP

Playwright MCP is deliberately not a stealth tool. When users reported CAPTCHA walls and "unusual traffic" pages in the project's issue tracker, a maintainer's answer was blunt: "Circumventing bot protection is out of scope for this project." The tool automates a browser; it does not hide that fact.

That leaves you with the layers you can control. The first one every anti-bot system checks is the IP address, and it is also the one most people get wrong: agents running on a VPS browse from datacenter ranges that are trivially classified, and even a home connection accumulates a history that does not survive heavy automated use.

Carrier-grade NAT works in your favor

A mobile 4G/5G IP is shared by many real subscribers behind CGNAT, so blocking it outright carries collateral damage sites want to avoid. Your agent's requests originate from the same address space as ordinary phone traffic.

The proxy fixes the IP layer, not the fingerprint

Be honest about scope: a mobile IP removes the most common block trigger for AI-driven browsing, but it does not alter the automation signals of the browser itself. Sites with aggressive behavioral detection can still challenge the session.

Geo matters for agent output

What an agent reads depends on where it browses from. Prices, search results, and content vary by region, which is why teams pin agents to specific markets - see our guide to US mobile IPs for AI testing.

We cover the broader pattern of giving autonomous agents a trustworthy egress in mobile proxies for AI agents, and the data-collection side in our web scraping solutions.

Verify the proxy is actually applied

Do not assume - check. Playwright MCP exposes a browser_get_config tool that returns "the final resolved config after merging CLI options, environment variables and config file," so you can simply ask your agent to call it and confirm the proxy is present. Then have the agent navigate to an IP echo service:

# Prompt for Claude / Cursor once the server is connected:
"Use the Playwright browser to open https://api.ipify.org?format=json
and tell me the IP address shown."

The returned address should be the proxy's exit IP on a mobile carrier ASN, not your own. If it is not, the usual suspects are a client that was not fully restarted after the config edit, a typo in the flag name, or args placed under the wrong server entry.

Two adjacent flags worth knowing: --proxy-bypass excludes domains you want to reach directly (internal dashboards, localhost tooling), and --mobile makes the browser emulate a generic mobile device - a sensible pairing when your egress is a phone network anyway.

Frequently asked questions

Does Playwright MCP support user:pass in the --proxy-server URL?

The official README documents --proxy-server with plain scheme://host:port values such as http://myproxy:3128 or socks5://myproxy:8080, without credentials. The documented way to pass a username and password is Playwright's own proxy object (server, username, password), which you can set in a JSON file passed via --config under browser.launchOptions.proxy. Alternatively, use IP allowlisting on the proxy side so no credentials are needed.

How is this different from setting a proxy in Playwright code?

Playwright MCP is a server your AI client (Claude Desktop, Cursor, VS Code) launches for you, so there is no script where you could pass a proxy option. Configuration happens through CLI args, environment variables, or a config file declared in the MCP client's JSON config. If you are writing Playwright scripts yourself, see our separate guide on Playwright proxy configuration for the library API.

Will a proxy stop Playwright MCP from being detected as a bot?

Not by itself. A proxy fixes the IP reputation layer: your agent stops browsing from a datacenter or flagged address. It does not change the automation fingerprint of the browser Playwright launches. The Playwright MCP maintainers have stated that circumventing bot protection is out of scope for the project, so treat the proxy as removing the most common block trigger, not as an evasion tool.

Which MCP clients does the --proxy-server flag work with?

Any client that lets you define the server command and args in JSON: Claude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json or ~/.cursor/mcp.json), VS Code, Windsurf, and Claude Code via claude mcp add. The flag belongs to the Playwright MCP server itself, so the client only needs to pass it through in the args list.

Can I use a SOCKS5 proxy with Playwright MCP?

Yes. The README's --proxy-server examples explicitly include socks5://myproxy:8080. Note that Playwright's documentation describes username and password as options for HTTP(S) proxies, so for authenticated access a HTTP proxy endpoint with credentials via the config file, or IP allowlisting for SOCKS5, is the safer route.

Sources

Related Guides

Give your agent a carrier-grade IP

Dedicated 4G/5G mobile proxies with HTTP and SOCKS5 endpoints that drop straight into the --proxy-server flag. One config edit and your Playwright MCP traffic browses like a phone.