Per-client TLS config vs global insecureSkipTLSVerify for mixed-trust k6 targets

k6 scripts that target both public CA-signed endpoints and internal services with self-signed certificates face a configuration trade-off. The http client supports insecureSkipTLSVerify, which disables certificate validation for every request using that client instance, but k6 does not document a per-request override. Mixing trust models therefore requires either a dedicated client with validation disabled or accepting a global bypass across the script.

The unresolved concern is failure observability. Certificate validation errors, DNS resolution problems, and connection failures are aggregated into the same http_req_failed metric with only a generic error string from Go's TLS package. Without built-in separation, distinguishing an expired certificate from an untrusted CA or a DNS lookup failure requires parsing error messages manually.

When a script uses multiple http clients—some with certificate validation enabled and others with insecureSkipTLSVerify—does the default metric aggregation still obscure the boundary between TLS handshake failures and DNS errors, or does client-scoped configuration alter how those failures are reported? Is there a documented approach for preserving separate failure classes for connection setup versus certificate validation when mixed TLS configurations coexist in a single k6 run?