Patchright is Playwright with the telling parts patched out. If your proxy behaves oddly under it, the first thing to know is reassuring. The proxy option is not one of the patched parts. The release holds 67 files and not one of them touches proxy handling. What does change is the machinery around your requests, and that is where the surprises live. We read release 1.63.0 on 20 September 2026.
What the patches touch
| Part | Patched? | What it means for your proxy |
|---|---|---|
| The automation flags on the command line | yes | the proxy flag is not among them |
| Script injection | yes, it uses request routes | this is where proxies have collided |
| The network manager | yes, interception is always on | it decides what reaches the wire |
| The browser cache | yes, kept on unless you add routes | fewer bytes down your line |
| The proxy option itself | no | plain Playwright, with the login in the dictionary |
So the setup is the familiar one, with a server, a username, a password and a bypass list, and both a plain HTTP port and a SOCKS5 port work.
An init script is a request route
This is the detail that explains most proxy trouble here. To inject scripts without the detectable path, the project routes requests and injects into the HTML as it passes. Its own documentation says so, and adds the honest warning that routes "may cause some bugs in other parts of your code".
Proxies have been one of those parts, twice.
In January 2026 a user reported that a proxy and an init script worked separately and failed together. The error was a tunnel connection failure. In April a SOCKS5 proxy with an exposed function or init script broke navigation against an HTTP/2 server. Both were closed by upgrading rather than by changing a setting.
The practical consequence is a diagnosis, not a workaround. If your proxy works and then stops when the script is added, do not go hunting through gateway settings. Remove the init script, confirm the proxy is fine, then check your version.
The cache is protecting your traffic
This tool intercepts every request by design. Stock behaviour would therefore switch the browser cache off permanently. Playwright disables the cache whenever interception is on.
The project patches that. The cache stays on unless you add routes of your own or record a session archive.
For anyone paying per gigabyte, that patch is worth money. It also gives you a rule: your own routes cost you the cache. Add one and every asset on the page comes down your line again on the next visit. If you are using a route to block images, that is a fair trade. If you are using one to read a response, consider whether you need it on every page.
The leak the proxy does not cover
A proxy decides where your requests come from. It does not stop a page asking the browser directly for something the browser knows. Two reports on the tracker describe the real address appearing through a browser feature that opens its own connections, while the proxy was handling the page perfectly.
The usual advice is to switch that feature off. The maintainer gives a better answer. The setting that disables it "can be detected an flagged", so whether it helps depends on the site. A proper fix belongs at the operating system level, with routing that covers the other protocol.
In other words: you are choosing between one signal and another. On a site that checks for the address, switch it off. On a site that checks for the setting, do not. That is an uncomfortable answer, and it is the true one.
Which proxy type fits it?
Residential, for the sites that refuse a hosting address, and with no illusions about what it buys. In our paired test a residential address changed 4 of 13 answers, and four sites refused both a server address and a residential one. Those four are what the patched browser is for. The rest is what the address is for. A user on this very tracker arrived blocked "even with residential proxies", which is the same lesson from the other side.
A sticky port suits browser work: one browser, one address, for as long as the session lasts. Write a retry anyway, because a sticky address can change early when its device leaves the network. The login travels in the proxy dictionary rather than in a flag, so passwords with awkward characters are not a problem here. If you would rather hold no password at all, a Residential Premium plan can allow your machine's address instead, up to 150 per plan. The residential proxies page lists the plans and the plan API manages allowed addresses from code.
What breaks
- Navigation fails only with an init script. Remove it, confirm the proxy, then upgrade.
- SOCKS5 fails against a newer protocol. Same pattern, same answer: a version.
- Your traffic doubles after a small change. You added a route, and the cache went off with it.
- The site sees your real address. A browser feature that makes its own connections. Decide which signal you prefer.
- A residential address is not enough. Four of thirteen sites in our test refused both.
What this page does not cover
We read the patches and the tracker as text and did not run the browser. So we did not reproduce the two collisions, did not measure what the cache saves on a real line, and did not test the leak. We make no claim about which sites this tool passes. Its own readme says it is considered undetectable with the right setup, and also admits it does not pass every test of the framework it patches. Whether the project's own script injection counts as a route for the cache rule is not something we established, so this page does not claim it either way. The project follows the version numbers of that framework and releases often, so we will read it again by 20 October 2026.
Where to go from here
Proxies for Camoufox covers the other patched browser, which matches the clock to the address for you. Proxies for CloakBrowser covers a patched Chromium whose login handling depends on your platform. How websites detect proxies covers the signals all three are working against.
Sources
- What it patches and what it admits (README.md), the command line switches (driver_patches/chromiumSwitchesPatch.ts), the always-on interception and the cache logic (driver_patches/crNetworkManagerPatch.ts), and the file listing that shows no proxy code. Kaliiiiiiiiii-Vinyzu/patchright, release v1.63.0 of 8 September 2026, read 20 September 2026.
- Issue 166 on a proxy with an init script, issue 190 on SOCKS5 with injection over HTTP/2, issues 93 and 128 on the address leak with the maintainer's answer, and issue 152 on a block despite residential addresses. Patchright issue tracker, read 20 September 2026.
- Our paired address test of 19 September 2026: 16 URLs, plain requests, two runs from our server and two through a residential line of our house plan. Raw output is kept in the research folder of our OpenClaw page.
- Plans, allowed addresses and sticky sessions. HProxy documentation, hproxy.com/docs, 20 September 2026.
