TLS passthrough configuration

Hi,

We're currently testing a migration path where we are running Envoy GatewayAPI in front of nginx ingress controller. The idea is that, we can pass all traffic through the gateway via listenerset (port 443 and protocol TCP) and a TCPRoute to nginx-ingress. Afterwards we migrate by translating ingresses to httproutes 1 by 1. This work(ed) until we've upgraded to Envoy Gateway 1.8.0 and traffic to nginx-ingress got dropped.

After the upgrade, we're getting this error on the listenerset which is responsible for the tcproute:
```
- lastTransitionTime: "2026-05-20T13:05:43Z"
message: All listeners for a given port must use a compatible protocol
observedGeneration: 1
reason: ProtocolConflict
status: "True"
type: Conflicted
```

When we migrate an ingress, we create a new listener set on port 443 and protocal HTTP. I think this is the reason for the above error. Even though the configuration functionally works, the current validation rules don't allow it.

I believe this is by design, because there [are tests](https://github.com/kubernetes-sigs/gateway-api/blob/9edc34983c4af9ff30078d4158a252ab89b79078/conformance/tests/listenerset-protocol-conflict.yaml#L28) which reject this specific configuration.

After this error, we tried to switch from TCP to TLS with tls.mode `passthrough`. Which seem to work, but here we have the issue that for a tlsroute the [spec.hostnames can't be empty] (https://github.com/kubernetes-sigs/gateway-api/issues/3871) and you should use TCP routes, but we can't because of the above conflic error.. . We want to use TLS passthrough to forward all SNI traffic to nginx-ingress without specifying hostnames, since nginx handles the routing internally. Requiring hostnames defeats the purpose of the passthrough migration step.

Now we're kinda at a halt and unsure how to proceed. So my question is, Is there a supported way to use TLS passthrough to forward all traffic to a backend without specifying spec.hostnames on a TLSRoute? If not, is this a gap that could be addressed?

Start with the linked ListenerSet protocol-conflict conformance test and the TLSRoute hostname requirement issue. Compare the documented TCPRoute and TLS passthrough behavior, then determine whether an existing supported configuration can forward all SNI traffic or whether the hostname requirement represents a spec gap; done means a maintainer-confirmed path or a scoped change proposal.

Written by the indexing model from the issue text.