Overview
We recently encountered an HTTP 400 – Bad Request (Invalid Hostname) error while accessing an ASP.NET Core application hosted on Azure App Service using a custom domain.
This article documents the root cause analysis, diagnostic steps, and final resolution, along with Microsoft official references for further reading.
Issue Description
Users attempting to access the application via the custom domain https://app.azureguides.com received the following error:
Bad Request – Invalid Hostname
HTTP Error 400. The request hostname is invalid.
Accessing the same application through the default Azure URL (azgdev.azurewebsites.net) worked correctly.
Diagnostic Approach
Step 1: Enable Failed Request Tracing
To understand where the request was failing, Failed Request Tracing was enabled on the Azure App Service.
Failed Request Tracing provides detailed insight into how IIS and the ASP.NET Core hosting module process each request, making it ideal for diagnosing HTTP 4xx and 5xx errors.
Microsoft Reference:
- Enable diagnostic logging and Failed Request Tracing in Azure App Service
Enable diagnostic logging for Azure App Service
Step 2: Analyze Failed Request Tracing Output
The Failed Request Trace revealed that:
- The request passed through the IIS pipeline successfully.
- No failures occurred in authentication, authorization, or request filtering.
- The request was handed over to AspNetCoreModuleV2.
- ASP.NET Core returned HTTP 400 – Invalid Hostname immediately.
MODULE_SET_RESPONSE_ERROR_STATUS Warning ModuleName=”AspNetCoreModuleV2″, Notification=”EXECUTE_REQUEST_HANDLER”, HttpStatus=”400″, HttpReason=”Bad Request”, HttpSubStatus=”0″, ErrorCode=”The operation completed successfully. (0x0)”, ConfigExceptionInfo=”” 06:57:37.812
This confirmed the issue was application-level, not IIS or networking-related.
Reviewed AllowedHosts Configuration
The wildcard AllowedHosts setting is commented out, and custom AllowedHosts values are enabled in appsettings.json.
//”AllowedHosts”: “*”,
“AllowedHosts”: “azgdev.azurewebsites.net”,
Root Cause
The fix was to add the missing hostname to the AllowedHosts configuration.
“AllowedHosts”: “azgdev.azurewebsites.net;app.azureguides.com”,