Under certMode: dns01 or existingSecret, an HTTPRoute that claims the hostname of one of the tenant's TLS-passthrough listeners, such as api.<apex>, is reported Accepted=True by the TenantGateway controller, but it never gets the traffic.
Both modes render the wildcard *.<apex> HTTPS listener and the tls-<svc> passthrough listeners on port 443 of the same Gateway. The controller accepts the HTTPRoute because the wildcard listener's hostname covers the name. Envoy, however, picks the passthrough filter chain for that SNI, since an exact server_names match wins over the wildcard. A client asking for api.<apex> reaches the passthrough backend, and the HTTPRoute serves nothing while its status says it is attached.
Under http01 the same claim is refused: the name is reserved for the passthrough listener and the route reads Accepted=False with NoMatchingListenerHostname. The whole-apex modes skip that check because they render no per-hostname listeners (collectHostnameClaims returns early for them).
This predates the passthrough rework in #4638; the package README now describes the serving path, but the route status still disagrees with it. A fix would apply the same reservation verdict to the route status in dns01 and existingSecret, without changing which listeners are rendered.
Under
certMode: dns01orexistingSecret, an HTTPRoute that claims the hostname of one of the tenant's TLS-passthrough listeners, such asapi.<apex>, is reportedAccepted=Trueby the TenantGateway controller, but it never gets the traffic.Both modes render the wildcard
*.<apex>HTTPS listener and thetls-<svc>passthrough listeners on port 443 of the same Gateway. The controller accepts the HTTPRoute because the wildcard listener's hostname covers the name. Envoy, however, picks the passthrough filter chain for that SNI, since an exactserver_namesmatch wins over the wildcard. A client asking forapi.<apex>reaches the passthrough backend, and the HTTPRoute serves nothing while its status says it is attached.Under
http01the same claim is refused: the name is reserved for the passthrough listener and the route readsAccepted=FalsewithNoMatchingListenerHostname. The whole-apex modes skip that check because they render no per-hostname listeners (collectHostnameClaimsreturns early for them).This predates the passthrough rework in #4638; the package README now describes the serving path, but the route status still disagrees with it. A fix would apply the same reservation verdict to the route status in
dns01andexistingSecret, without changing which listeners are rendered.