Azure Application Gateway Forwarding without Listener

Question

Azure Application Gateway Forwarding without Listener

Britt Tucker 40

In an effort to set up Azure Application Gateway to forward to an Azure Container Environment, I discovered that it was not routing to the the application I wanted. It was forwarding to a different backend pool.

Since this was for testing I removed the rule, backend setting, backend pool, and listener, however my client would still connect to that backend pool when I went to the name. (my client has a host file configured for that name.)

At this point I decided to try another name which didn't use any of the certificates that I had applied to the gateway, and it still forwarded to that same backend pool. (the backend pool is "training" which uses a wildcard certificate. This attached screenshot shows what I'm seeing. fcagw-fake.com-resolution

My questions is why is my gateway accepting/forwarding these requests? How do I prevent this. As I stated previously, the issue that made me discover this was that a legitimate set up I meant to connect to a container app environment, was resolving this back end pool as well. I will probably address that in a different post/ticket.

Thanks you.

P Kamala 0 Reputation points Microsoft Employee Moderator

2026-08-11T08:28:52.45+00:00
@Britt Tucker
Since traffic to a completely fabricated hostname (fcagw-fake.com) — one that has no matching certificate or listener you configured — is still being routed to the "training" backend pool, you almost certainly have a Basic listener (as opposed to a Multi-site listener) on port 443 (or 80). A Basic listener has no hostname filter — it matches every incoming request on that port, regardless of the Host header or SNI value. Its associated routing rule then sends all that traffic to whichever backend pool it's configured for, which in your case is "training."

The wildcard certificate is not the cause. A wildcard cert controls which hostnames get a valid TLS handshake, but it doesn't control routing. The listener type and routing rule do. Even with a certificate mismatch, Application Gateway will still accept and route the connection if a Basic listener matches.

To confirm this, run:

az network application-gateway http-listener list \ --gateway-name <your-appgw-name> -g <your-resource-group> \ --query "[].{Name:name, Type:properties.protocol, HostName:properties.hostName, HostNames:properties.hostNames}" -o table

Look for any listener where HostName and HostNames are both null/empty — that's your catch-all Basic listener.

To fix it, you have two options:

Convert that Basic listener to Multi-site and assign it a specific hostname (e.g., training.yourdomain.com) so it only matches intended traffic.

Remove the Basic listener (and its associated rule) if it's no longer needed.

After making the change, you can verify by checking the access logs (if Diagnostic Settings are enabled):

AzureDiagnostics | where ResourceType == "APPLICATIONGATEWAYS" | where host_s contains "fcagw-fake" | project TimeGenerated, host_s, listenerName_s, ruleName_s, backendPoolName_s, httpStatusCode_d | order by TimeGenerated desc

If listenerName_s shows the Basic/catch-all listener, that confirms the diagnosis.

Regarding your Container App Environment routing issue — yes, the same catch-all listener would have been intercepting that traffic too. Once you fix the listener, your Container App backend should start receiving its intended requests.
P Kamala 0 Reputation points Microsoft Employee Moderator

2026-08-13T09:13:33.99+00:00

@Britt Tucker
I am following up on the guidance provided earlier regarding your query. Could you please confirm whether the issue has been resolved?

If you are still experiencing any difficulties or require further clarification, please let us know. We would be happy to assist further.

Thank you, and I look forward to your update.

Regards,
Kamala...

1 answer

Your answer

P Kamala 0 Reputation points Microsoft Employee Moderator

2026-08-13T09:13:33.99+00:00

@Britt Tucker
I am following up on the guidance provided earlier regarding your query. Could you please confirm whether the issue has been resolved?

If you are still experiencing any difficulties or require further clarification, please let us know. We would be happy to assist further.

Thank you, and I look forward to your update.

Regards,
Kamala...

Answer 1

Application Gateway can still accept the request if another listener is matching it as a catch-all or wildcard listener and that listener’s rule routes to the training backend pool.

The behavior shown matches these documented cases:

A multi-site listener with no hostname acts as a catch-all
If a listener is configured without a hostName, it matches any hostname not matched by other listeners.
A wildcard listener can match before a more specific listener
If a wildcard listener has higher priority than the intended specific listener, traffic is routed by the wildcard listener’s rule.
Rules/listeners are what determine the backend pool
Application Gateway evaluates the listener and associated routing rule, then sends the request to the backend pool selected by that rule.

To prevent this:

In Application Gateway > Listeners, check for:
- any listener with a blank hostname
- any wildcard listener such as *.domain.com
- duplicate listeners on the same port
- listeners on the wrong port that might still be matching traffic
In Application Gateway > Rules, verify that:
- the hostname being tested maps only to the intended listener
- no wildcard or catch-all listener has a higher priority than the specific listener
- no remaining rule still points to the training backend pool
If the request is going to the wrong backend because of listener matching:
- give the intended specific listener a higher precedence by using the correct priority
- remove or correct any catch-all listener if it is not intentional
If the backend is a multitenant PaaS target such as App Service, Azure Functions, or similar FQDN-based backend, also verify the HTTP settings Host header behavior. A wrong host header can make the request appear to land on the wrong app or return the wrong content.
Check access logs to confirm which listener actually handled the request:
- if listenerName_s is not the expected listener, it is a listener priority or catch-all/wildcard match issue
- if listenerName_s shows the wildcard or catch-all listener, fix listener priority/configuration

If all listener priorities and hostnames are correct but the problem persists, file an Azure support request.

References: