Originally published on proxymint.
How CDP detection spots Puppeteer, Playwright and Selenium through the Chrome DevTools Protocol, what the 2025 V8 change broke, and what a proxy changes.
TL;DR
- CDP detection targets the automation channel, not the fingerprint. Since Chrome 112, headless Chrome shares the regular Chrome code, so detection moved to side effects of the Chrome DevTools Protocol that Puppeteer, Playwright and ChromeDriver all use.
- The classic Runtime.enable probe went quiet in 2025. Two V8 commits in May 2025 stopped error previews from running user-defined getters, and Castle reports the error-getter check no longer fires on current Chrome.
- Other signals still fire. navigator.webdriver, ChromeDriver cdc_ residue, Playwright bindings, init scripts, launch defaults and behaviour remain readable from page JavaScript.
- A proxy cannot touch any of it. Over HTTP CONNECT the proxy relays encrypted bytes and never sees the page; it owns the IP, ASN, geolocation and network layer only.
Key takeaways
- Test the browser before changing the exit. If a challenge follows you across datacenter, residential and mobile exits, the flag is in the browser layer, and a new IP will not move it.
- Run the self-test on a page you own. Log navigator.webdriver, cdc_ properties and framework globals per client, direct and through each proxy, and compare.
- Treat a detected browser as a policy question first. Use the site's API or feed, a verified bot identity, or ask for access when the terms forbid automation.
- Pick a proxy category for the network signals only. Residential for consumer-origin pages, datacenter for lenient targets at volume.
Read the full guide on proxymint, with the commands, tables and sources.
