App Service custom domain returns 400 Invalid Hostname after binding succeeds — routing-table state stuck on cluster

Question

App Service custom domain returns 400 Invalid Hostname after binding succeeds — routing-table state stuck on cluster

Tom Bauto 5

Summary

A newly provisioned App Service Linux (B1) in southeastXXXX rejects ALL custom-domain HTTPS requests with HTTP 400 Bad Request — Invalid Hostname, even though every customer-side configuration is correct (DNS, hostname binding, SSL cert, asuid TXT record). The same cluster's other App Service (same plan, sibling resource) serves its own custom domains without issue. Recreating the affected App Service from scratch did not resolve. Looking for confirmation this is a platform-side routing-table state that needs Microsoft to flush, or guidance on what else to try.

Topology

Region: southeastXXXX
App Service Plan: Linux B1, shared between two sites:
- Site A (Portal) — bound example.com + www.example.com, both Secured (SNI SSL), works fine, returns app content.
- Site B (API) — newly provisioned. Default *.azurewebsites.net hostname works. Any custom domain bound to it returns 400.
Cluster (per nslookup): waws-prXX-sXX-113.sip.azurewebsites.windows.net / IP 20.212.x.x
Both sites are in the same resource group, same subscription, same managed identity pattern.

Symptom

$ curl -v https://api.example.com/health
HTTP/1.1 400 Bad Request
Server: Microsoft-Azure-Application-Gateway/v2

<h2>Bad Request - Invalid Hostname</h2>
<p>HTTP Error 400. The request hostname is invalid.</p>

The default hostname on the SAME App Service works:

$ curl https://<my-api-app>.azurewebsites.net/health
Healthy

Same 400 for a second test subdomain (app.example.com) bound to the same site. So it's not specific to one hostname — it's any custom domain on this particular App Service.

What I verified

DNS resolves correctly to the App Service's IP via the standard *.azurewebsites.net CNAME chain:

   $ nslookup api.example.com
   Aliases: api.example.com
            <my-api-app>.azurewebsites.net
            waws-prod-sg1-113.sip.azurewebsites.windows.net
   Address: 20.212.x.x

Hostname binding exists with correct SSL (per az webapp config hostname list):

   HostNameType  Name                SslState     Thumbprint
   ------------  ------------------  -----------  --------------------------------
   Verified      api.example.com     SniEnabled   <thumbprint>
   Verified      app.example.com     SniEnabled   <thumbprint>

Certificate is healthy — App Service Managed Certificate, keyVaultSecretStatus: Succeeded, correct expiration. TLS handshake from the client serves the correct certificate (verified via System.Net.Security.SslStream.AuthenticateAsClient):
```
   Subject: CN=api.example.com
   Issuer:  CN=GeoTrust TLS RSA CA G1, OU=www.digicert.com, O=DigiCert Inc, C=US
```
So TLS terminates correctly. The 400 comes after TLS, from Azure's edge HTTP router.
asuid TXT record is present at the DNS provider (Namecheap):
```
   $ nslookup -type=TXT asuid.api.example.com
   asuid.api.example.com  text = "<verification-id>"
```
Matches the App Service's customDomainVerificationId.

No competing hostname binding anywhere in the subscription:

   $ az resource list --resource-type Microsoft.Web/sites/hostNameBindings -o table | findstr api.example.com
   (no other results)

Recreated the App Service from scratch via az webapp delete --keep-empty-plan + Bicep redeploy. Same symptom on the new instance. The recreate landed on the same cluster.
Sibling app on the same plan + same cluster works. It has example.com + www.example.com bound the same way and they serve fine. So the cluster's edge router CAN route custom domains — it just doesn't have a route for the new App Service.

What I tried (in order)

AttemptOutcome1. az webapp config ssl bind against original certBind succeeded, still 400.2. Delete + recreate hostname bindingStill 400.3. Delete + recreate the Managed Certificate, rebindStill 400.4. az webapp restartStill 400.5. App Service Plan SKU bounce (B1 → S1 → B1) to force cluster reassignmentStill 400 (landed on same cluster).6. Full az webapp delete --keep-empty-plan + Bicep redeploy + rebindStill 400.7. Add asuid.api.example.com TXT record matching customDomainVerificationIdStill 400.8. Test with a different subdomain (app.example.com) — fresh hostname, fresh certStill 400.## Question for the community / Microsoft

Is this a known scenario where the App Service edge router caches a bad routing state for a recreated resource that needs Microsoft-side intervention to flush?
Is there any customer-accessible way to force the edge router's routing table to re-read the hostname bindings, short of moving to a new App Service Plan in a different cluster?
For people who've hit this: what unstuck it for you?

Happy to share resource IDs / subscription details privately if needed for diagnosis.

Environment / version info:

Linux App Service, .NET runtime stack
Region: Southeast XXXX
App Service Plan SKU: B1 (Linux)
App Service Managed Certificate (free SNI SSL)
Custom domain bound via az webapp config hostname add + ssl create + ssl bind CLI sequence

TP 156.7K Reputation points Volunteer Moderator

2026-05-17T16:01:04.9133333+00:00

Hi Tom,

Have you tried deploying the web app, add custom domain, certificate, binding, but not deploy your application or any files? So when you browse to the app it just displays the default "Your web app is running and waiting for your content" page and nothing else.

Would like to rule out something with the runtime stack/app config.

Also, are you testing through app gateway with your app service as backend? If yes there may be configuration issue there that is causing it.

-TP
Aditya N 2,975 Reputation points Microsoft External Staff Moderator

2026-05-18T06:17:06.3566667+00:00

Hello @Tom Bauto

Thank you for reaching out Microsoft Q&A. Thank you for sharing the steps which you already tried. We need some more information, we've reached you out in private message.
Tom Bauto 5 Reputation points

2026-05-19T04:15:40.3866667+00:00

@TP no, we're not, but the Microsoft-Azure-Application-Gateway/v2 header is App Service's internal edge layer (App Service IS a multi-tenant App Gateway under the hood)
TP 156.7K Reputation points Volunteer Moderator

2026-05-19T04:44:10.0666667+00:00

@Tom Bauto Okay. I'm not used to seeing that header when connecting to app service frontend. What are you seeing in the log when these 400 errors occur? Are you seeing matching 400 error each time in the log, or is it not logged, or something different?

Are you able to make http:// to these custom domains with exact same error, or do you see different result? Note to test you have to turn off https only, and if using browser specifically enter http://api.yourdomain.com in order to get it to attempt http instead of auto-switching to https.

I'm less inclined (but still open to the idea) to think it is frontend routing issue since it read the incoming SNI, selected (and delivered) correct cert to client, and then after all that failed with invalid hostname. That's why I'm curious what the logs show.

The other thing in my experience is the overall domain validation, cert validation/issuance/binding can be brittle in some cases, but if you make it all the way with properly issued app service managed cert and binding (showing correct on azure side) it normally works.

1 answer

Your answer

TP 156.7K Reputation points Volunteer Moderator

2026-05-17T16:01:04.9133333+00:00

Hi Tom,

Have you tried deploying the web app, add custom domain, certificate, binding, but not deploy your application or any files? So when you browse to the app it just displays the default "Your web app is running and waiting for your content" page and nothing else.

Would like to rule out something with the runtime stack/app config.

Also, are you testing through app gateway with your app service as backend? If yes there may be configuration issue there that is causing it.

-TP
Aditya N 2,975 Reputation points Microsoft External Staff Moderator

2026-05-18T06:17:06.3566667+00:00

Hello @Tom Bauto

Thank you for reaching out Microsoft Q&A. Thank you for sharing the steps which you already tried. We need some more information, we've reached you out in private message.
Tom Bauto 5 Reputation points

2026-05-19T04:15:40.3866667+00:00

@TP no, we're not, but the Microsoft-Azure-Application-Gateway/v2 header is App Service's internal edge layer (App Service IS a multi-tenant App Gateway under the hood)
TP 156.7K Reputation points Volunteer Moderator

2026-05-19T04:44:10.0666667+00:00

@Tom Bauto Okay. I'm not used to seeing that header when connecting to app service frontend. What are you seeing in the log when these 400 errors occur? Are you seeing matching 400 error each time in the log, or is it not logged, or something different?

Are you able to make http:// to these custom domains with exact same error, or do you see different result? Note to test you have to turn off https only, and if using browser specifically enter http://api.yourdomain.com in order to get it to attempt http instead of auto-switching to https.

I'm less inclined (but still open to the idea) to think it is frontend routing issue since it read the incoming SNI, selected (and delivered) correct cert to client, and then after all that failed with invalid hostname. That's why I'm curious what the logs show.

The other thing in my experience is the overall domain validation, cert validation/issuance/binding can be brittle in some cases, but if you make it all the way with properly issued app service managed cert and binding (showing correct on azure side) it normally works.

Answer 1

Alex Burlachenko 21,310 MVP Volunteer Moderator

Tom Bauto hi,

u already ruled out normal DNS/cert mistakes, this now looks like stale hostname propagation/routing state on the App Service front-end cluster, honestly this does look like stale/broken App Service edge routing state, not customer DNS/cert config anymore. u already proved the important parts: DNS chain resolves correctly, TLS handshake serves the right cert, hostname binding exists and is verified, no duplicate hostname elsewhere, and the default *.azurewebsites.net hostname works. That means the failure is happening after TLS, at the App Service front-end routing layer. The fact that the sibling app on the same cluster works while every custom hostname on this one app returns 400 Invalid Hostname is the big clue.

The other strong signal is that deleting/recreating the app did not help because it landed back on the same cluster (waws-prod-sg1-113). That points away from the app container/runtime and toward stale hostname propagation or corrupted front-end routing metadata on that cluster.

At this point I would stop redoing bindings certs. two things ....

move the app to a completely different App Service Plan/cluster (not just SKU bounce on same plan). Create a temporary new Linux plan in another region stamp if possible, deploy app there, bind hostname, test.
Open a ticket and ask specifically for App Service front-end hostname routing refresh / stale hostname cleanup on the cluster. Include the hostname, app name, cluster name, timestamps, and the fact that TLS succeeds but HTTP routing fails with Invalid Hostname.

the response header Microsoft-Azure-Application-Gateway/v2 is interesting because standard App Service front-ends usually do not expose that header directly. I would double-check there is no Front Door/App Gateway/CDN layer still pointing at the old app/site config somewhere in DNS/proxy chain, even indirectly. But since the default hostname works and cert is correct, I still lean platform routing metadata.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Tom Bauto 5 Reputation points

2026-05-19T04:25:09.17+00:00
Hi @Alex Burlachenko , thanks — your framing matches what I'm seeing.

Two clarifications and a follow-up question:

Clarification 1: We haven't fully abandoned the split. We've temporarily routed all traffic through the sibling Portal site to unblock go-live, but the split is still on the roadmap (the API workload genuinely needs to scale independently of the portal under multi-site load). So this is a "what do we do when we hit it again" question, not just a post-mortem.

Clarification 2: Worth noting that the default *.azurewebsites.net URL on the broken site works end-to-end — it returns the health endpoint and redirects to the login page as expected. So the app code, runtime stack, TLS, and the App Service edge are all happy on the default hostname. The 400 fires only for the bound custom domain. That narrows the stale state specifically to the custom-hostname routing metadata, not anything app- or cluster-wide.

Follow-up question: This is what's actually keeping me up. If binding a custom domain to a freshly-provisioned App Service can land in this stuck state, then it's not really a "splitting the API" problem — it's a problem for any future scenario where we bind a new custom domain to a new App Service. That includes:

Blue/green via a parallel App Service (not slots — full sibling site at a staging subdomain).

Active-passive DR in a second region (new site, new custom domain binding).

Future per-tenant subdomains.

Have you (or anyone reading) seen this routing-table desync hit a scale-out or DR scenario, not just a split? If the answer is "yes, it can happen any time you bind a new custom hostname to a new site," that changes our architecture choices around DR/scale far more than it changes the API split decision.

Will try your suggestion of a fresh App Service Plan in a different region stamp this week and report back — agree it's the cleanest way to isolate "cluster-side stuck state" vs. "resource-hash-side stuck state".

Thanks again for taking the time.
Alex Burlachenko 21,310 Reputation points MVP Volunteer Moderator

2026-05-19T10:25:18.9666667+00:00
hey Tom Bauto,

yes, this could affect blue/green or DR if u bind hostname at cutover time. Mitigation is pre-bind, pre-warm, validate, then cut traffic, not bind during the critical window, yeah, that clarification makes sense, and I agree this is bigger than just the API split.

The important distinction is this I would not assume custom hostname binding is generally unreliable, because that would be too strong. Most App Service custom domain bindings work normally every day. But yes, based on ur case, the failure mode is not tied to the API workload itself. It can theoretically affect any scenario where a new hostname binding needs to propagate into App Service front-end routing metadata.

So for blue/green, DR, and per-tenant subdomains, I would treat this as a rare but real platform propagation risk, not as an app architecture issue. The practical mitigation is to avoid making hostname binding a last-minute go-live step. Precreate and prebind hostnames as early as possible, validate them with a simple health endpoint & only then move real traffic. For DR keep the secondary site and hostname binding warm validated instead of creating it during incident response. For tenant subdomains, automate binding validation and fail the provisioning flow if HTTPS custom hostname does not return expected content after a timeout.

Urs default hostname result is also important. Since *.azurewebsites.net works and only the custom hostname fails, I agree this narrows it specifically to custom hostname routing metadata, not runtime, container, TLS or the app service plan generally. For the isolation test fresh App Service Plan in a different stamp is exactly the right move. If it works there so it strongly supports cluster/stamp-level routing state. If it fails again with the same hostname on a different stamp then I would start suspecting hostname-level stale metadata somewhere in Microsoft.Web, not the specific cluster.

If I were designing around this, I would not abandon split API/portal architecture. I would just build the deployment process assuming custom-domain propagation can fail rarely and must be validated before cutover.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal
Alex Burlachenko 21,310 Reputation points MVP Volunteer Moderator

2026-05-20T12:10:00.26+00:00

hey Tom Bauto, how its goes?

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

rgds,

Alex

Share via

App Service custom domain returns 400 Invalid Hostname after binding succeeds — routing-table state stuck on cluster

Summary

Topology

Symptom

What I verified

What I tried (in order)

1 answer

Your answer