Azure Linux App Service custom domain returns HTTP 400 Invalid Hostname despite verified SNI binding

Question

Azure Linux App Service custom domain returns HTTP 400 Invalid Hostname despite verified SNI binding

Michael GP 0

A custom domain bound to my Azure Linux App Service consistently returns HTTP 400 “Bad Request – Invalid Hostname,” although the default Azure hostname and application are healthy.

Environment:

App Service: acqnest-prod-west-0b8596

Resource group: rg-acqnest-prod

Region: West US 2

Plan: Linux B1

Custom domain: app.acqnest.com

Default hostname: acqnest-prod-west-0b8596.azurewebsites.net

Verified:

The default Azure hostname works.

The application health endpoint reports Healthy and the database reports Connected.

app.acqnest.com has a DNS-only CNAME pointing to acqnest-prod-west-0b8596.azurewebsites.net.

The asuid.app.acqnest.com TXT ownership record resolves publicly with the correct custom-domain verification ID.

Azure lists app.acqnest.com as Verified.

SNI SSL is enabled with an App Service Managed Certificate.

TCP port 443 is reachable.

The error occurs from multiple networks and devices.

The custom-domain and SNI bindings were removed and recreated after correcting the TXT record.

The App Service was restarted.

Always On and the /health health check are enabled.

Actual result:

HTTP 400 — Bad Request — Invalid Hostname

The request appears to be rejected by the Azure App Service front-end before reaching the application. This resembles stale or missing hostname-routing state on the App Service scale unit.

Please refresh the front-end hostname-routing entry for app.acqnest.com, move the site to a healthy scale unit, or escalate this into a private Azure support case for platform investigation.A custom domain bound to my Azure Linux App Service consistently returns HTTP 400 “Bad Request – Invalid Hostname,” although the default Azure hostname and application are healthy.

Environment:

App Service: acqnest-prod-west-0b8596

Resource group: rg-acqnest-prod

Region: West US 2

Plan: Linux B1

Custom domain: app.acqnest.com

Default hostname: acqnest-prod-west-0b8596.azurewebsites.net

Verified:

The default Azure hostname works.

The application health endpoint reports Healthy and the database reports Connected.

app.acqnest.com has a DNS-only CNAME pointing to acqnest-prod-west-0b8596.azurewebsites.net.

The asuid.app.acqnest.com TXT ownership record resolves publicly with the correct custom-domain verification ID.

Azure lists app.acqnest.com as Verified.

SNI SSL is enabled with an App Service Managed Certificate.

TCP port 443 is reachable.

The error occurs from multiple networks and devices.

The custom-domain and SNI bindings were removed and recreated after correcting the TXT record.

The App Service was restarted.

Always On and the /health health check are enabled.

Actual result:

HTTP 400 — Bad Request — Invalid Hostname

The request appears to be rejected by the Azure App Service front-end before reaching the application. This resembles stale or missing hostname-routing state on the App Service scale unit.

Please refresh the front-end hostname-routing entry for app.acqnest.com, move the site to a healthy scale unit, or escalate this into a private Azure support case for platform investigation.

Michael GP 0 Reputation points

2026-08-07T13:27:01.67+00:00

Thank you. I compared the public TXT record directly with the authoritative customDomainVerificationId returned by the affected App Service.

Results:

Azure: 217AD7891CA7DAB6CE101F7A5ACA3DFA770067365BFA109E32E51718365259D2

Public Cloudflare TXT: 217AD7891CA7DAB6CE101F7A5ACA3DFA770067365BFA109E32E51718365259D2

Comparison result: True

The verification ID included in your response differs from the ID returned by the App Service. Your response contains ...CA7DA86...F7A5AC3..., while the authoritative App Service ID contains ...CA7DAB6...F7A5ACA3....

The TXT record is publicly resolvable and exactly matches the App Service verification ID. The CNAME, verified custom-domain binding, managed certificate, and SNI SSL binding are also configured. Nevertheless, app.acqnest.com continues returning HTTP 400 “Invalid Hostname,” while the default Azure hostname remains healthy.

Please rerun the backend ownership validation using the authoritative App Service verification ID and refresh the App Service front-end hostname-routing assignment.
Michael GP 0 Reputation points

2026-08-10T04:40:25.01+00:00

Hello,

Can you please check my answer above?

Thank you.
Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-08-11T14:59:21.6866667+00:00
Hi @Michael GP

From the backend investigation, We found that Custom Domain Add Operations URL asuid.app.acqnest.com could not be assigned because of ownership verification failure due to incorrect/missing DNS records. Current DNS configuration for the verification record is shown as “DNS not configured for URL asuid.app.acqnest.com”.

Ensure the DNS for asuid.app.acqnest.com contains either:

A TXT record Name = asuid.app (or asuid.app.acqnest.com) Value = the exact Custom Domain Verification ID (217AD7891CA7DA86CE101F7A5AC3DFA770067365BFA109E32E51718365259D2)

or a CNAME record pointing to acqnest-prod-west-0b8596.azurewebsites.net.

It requires the asuid TXT record to be publicly resolvable before the domain can be successfully validated and bound. When the verification record is missing or incorrect, the hostname is never fully registered on the App Service front-end, which produces the 400 Invalid Hostname response.

Action

At your DNS provider create (or correct) the TXT record:

Host / Name: asuid.app

Value: 217AD7891CA7DA86CE101F7A5AC3DFA770067365BFA109E32E51718365259D2

Wait for propagation (up to 4 hours; usually much faster).

Verify public resolution with:

nslookup -type=TXT asuid.app.acqnest.com

In the Azure portal > App Service > Custom domains > remove app.acqnest.com if present, then re-add it and click Validate. Green check marks must appear for both the hostname record and the TXT record.

After successful validation, create/bind the App Service Managed Certificate as SNI SSL and restart the App Service.

Reference:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain?tabs=root%2Cazurecli
https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-custom-domain-issues-azure-app-service
https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-domain-and-tls-ssl-certificates

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.From the backend investigation, We found that Custom Domain Add Operations URL asuid.app.acqnest.com could not be assigned because of ownership verification failure due to incorrect/missing DNS records. Current DNS configuration for the verification record is shown as “DNS not configured for URL asuid.app.acqnest.com”. Ensure the DNS for asuid.app.acqnest.com contains either:

A TXT record Name = asuid.app (or asuid.app.acqnest.com) Value = the exact Custom Domain Verification ID (217AD7891CA7DA86CE101F7A5AC3DFA770067365BFA109E32E51718365259D2)

or a CNAME record pointing to acqnest-prod-west-0b8596.azurewebsites.net.

It requires the asuid TXT record to be publicly resolvable before the domain can be successfully validated and bound. When the verification record is missing or incorrect, the hostname is never fully registered on the App Service front-end, which produces the 400 Invalid Hostname response.

Action

At your DNS provider create (or correct) the TXT record:

Host / Name: asuid.app

Value: 217AD7891CA7DA86CE101F7A5AC3DFA770067365BFA109E32E51718365259D2

Wait for propagation (up to 4 hours; usually much faster).

Verify public resolution with:

nslookup -type=TXT asuid.app.acqnest.com

In the Azure portal > App Service > Custom domains > remove app.acqnest.com if present, then re-add it and click Validate. Green check marks must appear for both the hostname record and the TXT record.

After successful validation, create/bind the App Service Managed Certificate as SNI SSL and restart the App Service.

Reference:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain?tabs=root%2Cazurecli
https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-custom-domain-issues-azure-app-service
https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-domain-and-tls-ssl-certificates

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Michael GP 0 Reputation points

2026-08-12T19:06:50.9166667+00:00

The issue is resolved. Azure custom-domain validation, DNS, and SNI binding were correctly configured. The remaining HTTP 400 response was caused by the application’s production AllowedHosts setting not including app.acqnest.com. After adding the hostname and redeploying, https://app.acqnest.com/health returns Healthy with the database Connected.

Thank you for your assistance.

2 answers

Your answer

Michael GP 0 Reputation points

2026-08-07T13:27:01.67+00:00

Thank you. I compared the public TXT record directly with the authoritative customDomainVerificationId returned by the affected App Service.

Results:

Azure: 217AD7891CA7DAB6CE101F7A5ACA3DFA770067365BFA109E32E51718365259D2

Public Cloudflare TXT: 217AD7891CA7DAB6CE101F7A5ACA3DFA770067365BFA109E32E51718365259D2

Comparison result: True

The verification ID included in your response differs from the ID returned by the App Service. Your response contains ...CA7DA86...F7A5AC3..., while the authoritative App Service ID contains ...CA7DAB6...F7A5ACA3....

The TXT record is publicly resolvable and exactly matches the App Service verification ID. The CNAME, verified custom-domain binding, managed certificate, and SNI SSL binding are also configured. Nevertheless, app.acqnest.com continues returning HTTP 400 “Invalid Hostname,” while the default Azure hostname remains healthy.

Please rerun the backend ownership validation using the authoritative App Service verification ID and refresh the App Service front-end hostname-routing assignment.
Michael GP 0 Reputation points

2026-08-10T04:40:25.01+00:00

Hello,

Can you please check my answer above?

Thank you.
Michael GP 0 Reputation points

2026-08-12T19:06:50.9166667+00:00

The issue is resolved. Azure custom-domain validation, DNS, and SNI binding were correctly configured. The remaining HTTP 400 response was caused by the application’s production AllowedHosts setting not including app.acqnest.com. After adding the hostname and redeploying, https://app.acqnest.com/health returns Healthy with the database Connected.

Thank you for your assistance.

Answer 1

Hi @Michael GP

Thank you for reaching us regarding the issue.

You have confirmed that the public TXT record for asuid.app.acqnest.com exactly matches the Custom Domain Verification ID returned by the App Service:

Verification ID from App Service: 217AD7891CA7DAB6CE101F7A5ACA3DFA770067365BFA109E32E51718365259D2

Public TXT record value: identical

CNAME for app.acqnest.com points to the App Service default hostname

Domain appears as verified in the portal

App Service Managed Certificate is bound as SNI SSL

These are the exact prerequisites stated in Microsoft documentation for a successful custom-domain mapping. When the asuid TXT record matches the verification ID, the CNAME is correct, validation succeeds in the portal, and an SNI certificate binding exists, the custom domain is considered fully configured.

Once the above conditions are met, requests to the custom domain should reach the application.

The error explicitly documented for a missing or incomplete hostname binding is HTTP 404 – Web app not found.

Reference https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-custom-domain-issues-azure-app-service https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/connection-issues-with-ssl-or-tls/troubleshoot-domain-and-tls-ssl-certificates

Kindly let us know if the above helps or you need further assistance on this issue.

Please "accept" if the information helped you. This will help us and others in the community as well.

Golla Venkata Pavani 7,535 Reputation points Microsoft External Staff Moderator

2026-08-16T13:55:09.6233333+00:00

Hi @Michael GP

I am glad! your issue is resolved. If you found my assistance is helpful, Please "accept" the answer. It will be helpful for other community members as well.

Answer 2

Michael GP 0

The issue is resolved. Azure custom-domain validation, DNS, and SNI binding were correctly configured. The remaining HTTP 400 response was caused by the application’s production AllowedHosts setting not including app.acqnest.com. After adding the hostname and redeploying, https://app.acqnest.com/health returns Healthy with the database Connected.

Thank you for your assistance.

0 comments