"Error 404 - This Container App is stopped or does not exist" page when calling internally by IP or name with different Host header

[CezaryKlus]

This issue is a:

• [x] bug report

  Issue description

  Trying to achieve this setup:

Application Gateway -> VNET [ Container App Environment -> Ingress (Internal) -> App(Yarp Proxy) -> App(API)]

When Yarp Proxy tries to forward (X-Forwarded- headers added) by App(API) name e.g. http://api/path I receive a full HTML page Error 404 - This Container App is stopped or does not exist

from the logs in App(API) it is not even hitting it.

Can you explain what sits on the path of (presumably ClusterIP-based) inter-service calls in a fully internal environment - by App name? And if so, what is the motivation for that instead allowing direct traffic. I expected nothing but that "Error 404" page suggests traffic goes through something.

Docs: https://learn.microsoft.com/en-us/azure/container-apps/connect-apps?tabs=bash#call-a-container-app-by-name

Other interesting behaviors when investigating from a diagnostic app in the same environment:

IP of api = 100.100.236.115

curl --header 'Host: api' http://100.100.236.115/path => OK curl http://100.100.236.115/path => HTML page "Error 404 - This Container App is stopped or does not exist" curl --header 'Host: api' http://100.100.236.115/**non-existing-path** => Plain 404 from api

and our specific scenario is calling the App(API) by name with the original host header plus X-Forwarded-*: curl --header 'Host: host.external-domain.com' http://**api**/path => HTML page "Error 404 - This Container App is stopped or does not exist"

Steps to reproduce

1. Container App Environment inside VNet
2. Call your API by IP and expect the full 404 page
3. Call your API by IP with the host header as your API App name results in 200

Expected behavior Inter-service calls by IP/name are not altered.

Actual behavior Inter-service calls by IP/name are altered by proxy.

Additional context

1160

1240

[v-vish]

@CezaryKlus Hi, We have an OSI Layer 7 mesh that requires this information for HTTP routing. If you prefer not to specify a Host header, is it possible to use TCP for ingress?

[CezaryKlus]

@v-vish the problem is that TCP ingress cannot expose itself on standard ports 80/443. In our lift and shift scenario we need to make sure to add the ports for inter-service calls. It would be good to have the possibility to configure non-processed TCP ingress on standard 80/443 ports.