This issue was reported on #contour on the k8s slack. In essence, when using minikube the service load balancer will allocate a random high port as the ingress. This is problematic because this port is not a well known (RFC 2616 gibberish) port so curl(1) or browsers will include the port number in the Host: header. This causes Envoy to misroute the request because the domains file the RDS virtualhost entry does not contain the matching :port suffix.

The problem is the port minikube chooses is not easily predictable, so it is not simply a matter of including various permutations of hostname:port in the virtualhost.domains array.

Supporting Envoy ticket, envoyproxy/envoy#1269.

Workarounds

The workaround if you are using minikube is to either force the Host: header with something like

curl -H "Host: example.com" -v http://example.com:31847

Or use a OSX specific extension to curl

curl -v --connect-to example.com:80:example.com:31847 http://example.com/