[Bug]: pw:client-certificates: "Invalid IPv6 token" when corporate transparent proxy presents cert with IPv4 SAN

[ggopperr-lgtm]

Version

1.60.0

Steps to reproduce

Environment:

Playwright Java (same behavior expected in other bindings)
Machine is connected to a corporate network with a transparent HTTPS proxy (e.g., Zscaler, Squid or similar)
The transparent proxy intercepts all outbound HTTPS traffic and presents its own TLS certificate
That certificate contains an IPv4 address in the IP SAN field (e.g., 192.168.0.35)
Target site uses mutual TLS (mTLS) and requires a client certificate

Steps:

Be connected to a corporate network that has a transparent HTTPS proxy with IPv4 address in its certificate's IP SAN field
Enable debug logging: DEBUG=pw:client-certificates
Set NODE_TLS_REJECT_UNAUTHORIZED=0
Configure ClientCertificate for a target site
Call page.navigate() to that site

pw:client-certificates Failed to connect to :443: Invalid IPv6 token 192.168.0.35
net::ERR_CONNECTION_CLOSED at https://your-internal-site.example.com
The error occurs because Playwright's internal Node.js TLS proxy receives the corporate proxy's certificate, which contains an IPv4 address (192.168.0.35) in the IP SAN field. Internally, this IPv4 address is incorrectly processed as an IPv6 token — likely wrapped in brackets ([192.168.0.35]) somewhere in the URL construction code — causing new URL() to throw Invalid IPv6 token.

Note: Setting NODE_TLS_REJECT_UNAUTHORIZED=0 does not resolve the issue because the error occurs during certificate parsing, not during certificate validation. These are separate stages in Node.js TLS processing.

Expected behavior

Playwright's internal TLS proxy should correctly handle TLS certificates that contain IPv4 addresses in the IP SAN field. An IPv4 address like 192.168.0.35 must not be processed as an IPv6 token.

Either:

The proxy should distinguish between IPv4 and IPv6 addresses before constructing any URL or connection string, and should not wrap an IPv4 address in brackets []
Or, when setIgnoreHTTPSErrors(true) is set on the browser context, the proxy should skip any processing of the intercepting proxy's certificate entirely and forward the connection transparently
As a result, page.navigate() to a site behind a corporate transparent HTTPS proxy should succeed when setIgnoreHTTPSErrors(true) is configured — consistent with how it behaves in a non-proxied environment.

Actual behavior

Setting NODE_TLS_REJECT_UNAUTHORIZED=0 does not resolve the issue because the error occurs during certificate parsing, not during certificate validation. These are separate stages in Node.js TLS processing.

Additional context

No response

Environment

System:
    OS: macOS 26.5
    CPU: (12) arm64 Apple M3 Pro
    Memory: 172.41 MB / 18.00 GB
  Binaries:
    Node: 26.3.1 - /opt/homebrew/bin/node
    npm: 11.16.0 - /opt/homebrew/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash

[danpeleg4]

Hi I'd like to work on this issue

[pavelfeldman]

This isn't actionable as filed. The root-cause analysis in the report is speculative and, as far as I can tell, wrong on the key points:

• Invalid IPv6 token is not produced by Playwright. It also isn't Node's modern URL parser — new URL("https://[192.168.0.35]") throws Invalid URL, not Invalid IPv6 token. The cert's IP SAN is never passed to a new URL() anywhere in the client-certificate proxy, so the "IPv4 wrapped in brackets during URL construction" theory does not hold.
• The log line points away from cert parsing. Failed to connect to :: … only wraps connection setup (proxy-agent / socket creation), not the TLS handshake to the server — those errors are logged separately. The 192.168.0.35 in your message is far more likely coming from your proxy configuration (env var or PAC) than from the cert SAN.
• NODE_TLS_REJECT_UNAUTHORIZED=0 is irrelevant here. Playwright passes an explicit rejectUnauthorized derived from the context's ignoreHTTPSErrors, which overrides that env var.

We can't move on this without a reproduction we can actually run. I will not be installing Squid/Zscaler/mitmproxy or standing up a corporate network. Please provide a self-contained, pure Node.js repro — a single script with no external infrastructure — that:

1. Stands up the intercepting proxy in-process using Node's built-in net/tls/http2 modules and a self-signed cert generated in the script (with the IPv4 in the SAN), and
2. Drives Playwright against it to trigger the Invalid IPv6 token failure,
3. so that node repro.js reproduces it on a clean machine with nothing installed but playwright.

Without a pure-Node repro and a stack trace there is nothing to investigate.