iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🌐

Azure Container Apps Ingress Configuration Patterns Part 1: Public Web/API

に公開
Azure
Network
Azure Container Apps
tech

Introduction

This article documents my experience building and testing Ingress configuration patterns in Azure Container Apps.

https://zenn.dev/georgeosddev/articles/azure-container-apps-ingress-architecture-patterns

Starting with the simplest pattern, I will cover pattern ① from the article above.

Architecture

The environment I created is as follows. In this case, the (Optional) components shown in the mermaid diagram above are omitted.

Container Apps Environment

aca-env-without-vnet

This was created without a custom VNet, and Public Network Access is set to Enabled.

A static IP of 130.33.219.240 is assigned. This IP, as well as the External Loadbalancer used to reach the environment, are Azure-managed resources and are therefore not registered as resources under the user's subscription.

EnvironmentOverView

EnvironmentPNAEnabled

Each property can also be checked via the CLI.

$ az containerapp env show -g zenn-aca-without-vnet -n aca-env-without-vnet \
  --query "properties.{defaultDomain: defaultDomain, staticIp: staticIp, publicNetworkAccess: publicNetworkAccess}" \
  -o json

{
  "defaultDomain": "whitemoss-043fed62.japaneast.azurecontainerapps.io",
  "publicNetworkAccess": "Enabled",
  "staticIp": "130.33.219.240"
}

Container Apps

aca-without-vnet

I am using the quickstart container image (mcr.microsoft.com/k8se/quickstart:latest).

app-overview

app-ingress-external

The application URL is https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io. This is a combination of the app name and the environment's defaultDomain. whitemoss-043fed62 serves as the environment's unique identifier.

Reference
Connect apps in Azure Container Apps | Microsoft Learn

app-fqdn

Checking related properties, we can see that there is an FQDN for the latest revision, and 70 outbound IP addresses have been assigned.

az containerapp show -g zenn-aca-without-vnet -n aca-without-vnet \
  --query "properties.{environmentId: environmentId,
                       configuration: {ingress: configuration.ingress},
                       latestRevisionFqdn: latestRevisionFqdn,
                       outboundIpAddresses: outboundIpAddresses}" \
  -o json

{
  "configuration": {
    "ingress": {
      "additionalPortMappings": null,
      "allowInsecure": false,
      "clientCertificateMode": null,
      "corsPolicy": null,
      "customDomains": null,
      "exposedPort": 0,
      "external": true,
      "fqdn": "aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io",
      "ipSecurityRestrictions": null,
      "stickySessions": null,
      "targetPort": 80,
      "targetPortHttpScheme": null,
      "traffic": [
        {
          "latestRevision": true,
          "weight": 100
        }
      ],
      "transport": "Auto"
    }
  },
  "environmentId": "/subscriptions/<SubscriptionID>/resourceGroups/zenn-aca-without-vnet/providers/Microsoft.App/managedEnvironments/aca-env-without-vnet",
  "latestRevisionFqdn": "aca-without-vnet--i416lq8.whitemoss-043fed62.japaneast.azurecontainerapps.io",
  "outboundIpAddresses": [
    "20.48.86.170",
    "20.48.86.160",
    "135.149.20.219",
    ...// Omitted, contains a total of 70 public IPs.

  ]
}

Verifying Routing to the Application

Access from Clients Outside the Environment

HTTP requests to aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io are resolved to 130.33.219.240, which is the staticIp of the environment, and reach the application.

Application access

$ curl -v https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/
*   Trying 130.33.219.240:443...
* Connected to aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io (130.33.219.240) port 443 (#0)

<Omitted>

> GET / HTTP/2
> Host: aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
> user-agent: curl/7.81.0
> accept: */*
> 

< HTTP/2 200
< accept-ranges: bytes
< content-length: 4332
< content-type: text/html; charset=utf-8
< last-modified: Mon, 13 Oct 2025 15:12:40 GMT
< date: Wed, 07 Jan 2026 01:41:57 GMT
< 
<html>

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Azure Container Apps</title>
    <link href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" rel="stylesheet">
    <link rel="stylesheet" href="style.css">
</head>

<Omitted>

</html>
* Connection #0 to host aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io left intact

If you create another App within the environment named aca-without-vnet-2, it will be exposed as https://aca-without-vnet-2.whitemoss-043fed62.japaneast.azurecontainerapps.io/.

Nginx App
Deploying an Nginx image to aca-without-vnet-2

You can also access it using the revision-specific URL, such as https://aca-without-vnet--i416lq8.whitemoss-043fed62.japaneast.azurecontainerapps.io/ (the latestRevisionFqdn). Note that if you specify a non-existent app name or revision in the subdomain, a 404 error will be returned. In all cases, the resolved public IP address is 130.33.219.240.

$ curl -v https://notexist.whitemoss-043fed62.japaneast.azurecontainerapps.io/
*   Trying 130.33.219.240:443...
* Connected to notexist.whitemoss-043fed62.japaneast.azurecontainerapps.io (130.33.219.240) port 443 (#0)

<Omitted>

> GET / HTTP/2
> Host: notexist.whitemoss-043fed62.japaneast.azurecontainerapps.io
> user-agent: curl/7.81.0
> accept: */*
> 

< HTTP/2 404
< content-type: text/html; charset=utf-8
< content-length: 1946
< date: Wed, 07 Jan 2026 01:47:17 GMT
< 
<!DOCTYPE html>
<html>
<head>
    <title>Azure Container App - Unavailable</title>

<Omitted>

<body bgcolor="#00abec">
<div id="feature">
    <div id="content">
        <h1 id="unavailable">Error 404 - This Container App is stopped or does not exist.</h1>
        <p id="tryAgain">The Container App you have attempted to reach is currently stopped or does not exist.</p>
        <p id="toAdmin">If you are the Container App administrator, please visit <a href="https://portal.azure.com/">Azure Portal</a>.</p>
    </div>
</div>
</body>
</html>

On the other hand, the environment's defaultDomain, whitemoss-043fed62.japaneast.azurecontainerapps.io, itself cannot be resolved.

$ nslookup whitemoss-043fed62.japaneast.azurecontainerapps.io 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
*** Can't find whitemoss-043fed62.japaneast.azurecontainerapps.io: No answer

What this means is that it is inferred that a wildcard A record exists, such as *.whitemoss-043fed62.japaneast.azurecontainerapps.io. A 130.33.219.240.

Excerpt of discussion with Copilot regarding the existence of wildcard A records

Understood. I will briefly summarize the reasoning that led to the final conclusion (Wildcard A exists / Wildcard CNAME does not exist) based on observational results and DNS rules.

Summary (Basis for Conclusion)

  1. A record is returned even for non-existent hostnames

    dig +noall +answer doesnotexist.whitemoss-043fed62.japaneast.azurecontainerapps.io A
    → doesnotexist... 0 IN A 130.33.219.240

  • Normally, if there is no corresponding record, it becomes NXDOMAIN.
  • Nevertheless, an A record (130.33.219.240) is returned = Typical behavior when a wildcard DNS record is hit.
  • At this point, it is confirmed that either a "wildcard A or CNAME→A" exists.

  1. No CNAME exists for specific hostnames

    dig -t cname aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
    → ANSWER: 0 (No CNAME answer / NOERROR)

  • It is clear that there is no "individual CNAME".

  1. No answer when querying the authoritative DNS (Azure DNS) directly for the wildcard CNAME

    dig @ns1-35.azure-dns.com '*.whitemoss-043fed62.japaneast.azurecontainerapps.io' CNAME
    → ANSWER: 0 (NOERROR, SOA only)

  • The authoritative server answers that it does not have a wildcard CNAME in the zone definition.
  • No CNAME returned to the authority = It can be concluded that there is no CNAME definition in the zone.
  1. Overall Judgment
  • ① Confirmed that a wildcard system exists.
  • ② and ③ Confirmed that no CNAME exists (neither individual nor wildcard).
  • Therefore, the only remaining possibility is a wildcard A.
  • Specifically, there is a setting equivalent to *.whitemoss-043fed62.japaneast.azurecontainerapps.io. A 130.33.219.240.

Conclusion (Reiterated)

  • Wildcard CNAME: None (No answer for queries to authoritative DNS)
  • Wildcard A: Exists (Confirmed by the behavior of returning A even for non-existent names)
  • Therefore, any arbitrary host under this is resolved to 130.33.219.240 due to the wildcard A setting.

I can also illustrate the relationship between this wildcard A and ACA's L7 (Host header) routing if necessary.

fqdn-lookup

Additionally, I can confirm that a direct IP address specification results in a 404, while using a Host header routes to the application.

$ curl -I 130.33.219.240
HTTP/1.1 404 Not Found
content-type: text/html; charset=utf-8
content-length: 1946
date: Wed, 07 Jan 2026 03:01:08 GMT

$ curl -I 130.33.219.240 -H "Host: aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io"
HTTP/1.1 301 Moved Permanently
location: https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/
date: Wed, 07 Jan 2026 03:01:02 GMT
transfer-encoding: chunked

Reference
Host Name Preservation - Azure Architecture Center | Microsoft Learn

Why Web Platforms Use the Host Name

Outbound Communication from Applications and Internal Communication within the Env

Next, I will verify outbound communication from applications. Since it's tedious to implement an app, I will try it by console-connecting to the Nginx container I prepared earlier.

app-outbound-console-check

I will execute the following commands:

apt update -y
apt install dnsutils -y

echo "---- check global IP ----"

curl -s https://ipinfo.io/ip

echo "---- global fqdn ----"

nslookup aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io

dig aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io

curl -v https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/

echo "---- internal fqdn ----"

nslookup aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io

dig aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io

curl -v https://aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io/

echo "---- Removing the suffix ----"

nslookup aca-without-vnet

dig aca-without-vnet

curl -v https://aca-without-vnet


curl -v http://aca-without-vnet

Outbound Public IP Address

You can see that the IP is being used from among the values assigned to the application's outboundIpAddresses property.

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# curl -s https://ipinfo.io/ip
48.218.81.17

Access to External (Default) FQDN of Applications within the Env

This is the communication path from aca-without-vnet-2 to https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io.

The name resolution result is 130.33.219.240, which is the same as when accessed from outside the Env.
The DNS used for name resolution is 127.0.0.11.

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# nslookup aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
Address: 130.33.219.240

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# dig aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31846
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7282ed0496a99852 (echoed)
;; QUESTION SECTION:
;aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io. IN        A

;; ANSWER SECTION:
aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io. 30 IN A 130.33.219.240

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Wed Jan 07 03:25:37 UTC 2026
;; MSG SIZE  rcvd: 191

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# curl -v https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/
* Host aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io:443 was resolved.
* IPv6: (none)
* IPv4: 130.33.219.240
*   Trying 130.33.219.240:443...

<Omitted>

> GET / HTTP/2
> Host: aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
> User-Agent: curl/8.14.1
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< accept-ranges: bytes
< content-length: 4332
< content-type: text/html; charset=utf-8
< last-modified: Mon, 13 Oct 2025 15:12:40 GMT
< date: Wed, 07 Jan 2026 03:25:37 GMT

<Omitted>

* Connection #0 to host aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io left intact
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#

Access to Internal (".internal." subdomain) FQDN of Applications within the Env

This is the communication path from aca-without-vnet-2 to https://aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io.

Note: FQDNs with .internal. can also be used when ingress.external is true.

The name resolution result is 100.100.0.210, obtaining a Private IP address, which is different from when accessed from outside the Env.
A 200 OK is returned, confirming that you can actually access it.

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# nslookup aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
;; Got recursion not available from 127.0.0.11
Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
Address: 100.100.0.210
;; Got recursion not available from 127.0.0.11

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# dig aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40867
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 61c05fc3b520bb97 (echoed)
;; QUESTION SECTION:
;aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io. IN A

;; ANSWER SECTION:
aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io. 30 IN A 100.100.0.210

;; Query time: 4 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Wed Jan 07 03:25:52 UTC 2026
;; MSG SIZE  rcvd: 209

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# curl -v https://aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io/
* Host aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io:443 was resolved.
* IPv6: (none)
* IPv4: 100.100.0.210
*   Trying 100.100.0.210:443...

<Omitted>

> GET / HTTP/2
> Host: aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
> User-Agent: curl/8.14.1
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< accept-ranges: bytes
< content-length: 4332
< content-type: text/html; charset=utf-8
< last-modified: Mon, 13 Oct 2025 15:12:40 GMT
< date: Wed, 07 Jan 2026 03:25:52 GMT
< 

<Omitted>

* Connection #0 to host aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io left intact
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#

Access by Name to Applications within the Env

This is the communication path from aca-without-vnet-2 to http(s)://aca-without-vnet.

The nslookup results show that name resolution occurred via the "internal DNS (Kubernetes/CNI service DNS)". Also, HTTPS communication (to port 443) did not pass, and I was only able to communicate via HTTP (to port 80), which the application exposes through Ingress settings.

Explanation by Copilot

This indicates that name resolution was performed by the "internal DNS (Kubernetes/CNI service DNS)" within the Azure Container Apps (ACA) environment. This is a different path than the external *.azurecontainerapps.io → 130.33.219.240 resolution.

Interpreting the output:
Server: 127.0.0.11
Address: 127.0.0.11#53
Name: aca-without-vnet.k8se-apps.svc.cluster.local
Address: 100.100.241.104
;; Got recursion not available from 127.0.0.11

① What is 127.0.0.11?

A local DNS stub configured in /etc/resolv.conf within the container (provided by the container runtime). In ACA, this is internally forwarded to CoreDNS (Kubernetes DNS service) to resolve cluster-internal names.
(The container sees the 127.0.0.11 stub, but CoreDNS provides the final answer.)

② aca-without-vnet.k8se-apps.svc.cluster.local

The resolved FQDN is a standard Kubernetes service domain:

<service-name>.<namespace>.svc.cluster.local

k8se-apps suggests the namespace used by ACA (the common NS to which apps in an Env belong). In other words, aca-without-vnet is exposed as a "Service (ClusterIP)" within the Env, and can be reached by that service name.

③ Address: 100.100.241.104

This is the ClusterIP (IP of the internal virtual network).
From another app within the Env (aca-without-vnet-2), it reaches the internal service directly via the Service without going through an external public IP.

④ Got recursion not available

A notification that recursive queries are not permitted. The internal DNS is designed to return authoritative responses for the cluster's own zones (e.g., *.svc.cluster.local) and does not perform full recursion for external names, hence this message. There is no actual harm; cluster-internal name resolution is functioning correctly.

What is happening (the big picture)

For external: *.whitemoss-...azurecontainerapps.io → 130.33.219.240 (wildcard A) → routed by Ingress/L7.
For internal: <app-name>.<namespace>.svc.cluster.local → ClusterIP (100.100.x.y)
→ Inter-app communication within the Env reaches directly via this internal DNS + Service.

Therefore, the reason calling aca-without-vnet from aca-without-vnet-2 is successful is because it uses internal Service name resolution (Kubernetes DNS).

Verification points (you can check them yourself)
Shell# Checking DNS settings in the container

cat /etc/resolv.conf
# Example:# nameserver 127.0.0.11
# search k8se-apps.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5
# Reachable by internal name
nslookup aca-without-vnet
nslookup aca-without-vnet.k8se-apps.svc.cluster.local
# Real connection (HTTP example)
curl -H "Host: aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io" http://aca-without-vnet:80/
# * Adjust according to the port/header the app expects

The search line causes the short name (aca-without-vnet) to be completed to an FQDN. The value of ndots changes the judgment/search order for whether a name is an FQDN.

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# nslookup aca-without-vnet
;; Got recursion not available from 127.0.0.11
Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   aca-without-vnet.k8se-apps.svc.cluster.local
Address: 100.100.241.104
;; Got recursion not available from 127.0.0.11

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# dig aca-without-vnet

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> aca-without-vnet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63372
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3d46607b1f3decfd (echoed)
;; QUESTION SECTION:
;aca-without-vnet.              IN      A

;; AUTHORITY SECTION:
.                       30      IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2026010601 1800 900 604800 86400

;; Query time: 104 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Wed Jan 07 03:26:05 UTC 2026
;; MSG SIZE  rcvd: 132

root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# curl -v https://aca-without-vnet
* Host aca-without-vnet:443 was resolved.
* IPv6: (none)
* IPv4: 100.100.241.104
*   Trying 100.100.241.104:443...

// Could not communicate via HTTPS (port 443)

^C
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/# curl -v http://aca-without-vnet
* Host aca-without-vnet:80 was resolved.
* IPv6: (none)
* IPv4: 100.100.241.104
*   Trying 100.100.241.104:80...
* Connected to aca-without-vnet (100.100.241.104) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: aca-without-vnet
> User-Agent: curl/8.14.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< accept-ranges: bytes
< content-length: 4332
< content-type: text/html; charset=utf-8
< last-modified: Mon, 13 Oct 2025 15:12:40 GMT
< date: Wed, 07 Jan 2026 03:26:15 GMT
< 

<Omitted>

* Connection #0 to host aca-without-vnet left intact
root@aca-without-vnet-2--0000002-5895d64787-c9g9t:/#

I have learned that for both internal and application name specification, communication occurs via a Private IP. However, the former allows SSL communication (meaning a component exists to perform SSL termination), while the latter does not (meaning the path is different from the former).

Reference
Troubleshooting ingress issues on Azure Container Apps -

“.internal.” FQDN versus “appname”
On Container Apps, you can make inter-cluster requests to other applications, which is called out in Domain names.

The .internal. FQDN (eg. appname.internal.funnyname123abc.<region>.azurecontainerapps.io) can only be used to call between applications in the cluster. This will show as “limited to environment”. Routing through this method passes through Envoy proxies in the environment and stays in the environment.
You can call to another app within the environment - for example, curl -v myotherapp. This uses a helper proxy in the same pod that the application container is running in.
Calling to another app simply by its name is a nice helper. If you happen to notice issues calling to the upstream application in this manner and has been determined it is not application related, try using the .internal. FQDN of the upstream application instead.

Also, in both cases, when the Private IP was specified without a Host header, a 404 error was returned.

root@aca-without-vnet-2--0000002-5895d64787-9txpk:/# curl http://100.100.241.104 -I
HTTP/1.1 404 Not Found
content-type: text/html; charset=utf-8
content-length: 1946
date: Wed, 07 Jan 2026 05:33:16 GMT

root@aca-without-vnet-2--0000002-5895d64787-9txpk:/# curl http://100.100.0.210 -I
HTTP/1.1 404 Not Found
content-type: text/html; charset=utf-8
content-length: 1946
date: Wed, 07 Jan 2026 05:33:21 GMT

Discussion