Home
Servers
HTTP Status Code and IIS Configuration Troubleshooting Guide

HTTP Status Code and IIS Configuration Troubleshooting Guide

Kerry Cordero
Servers
30 min read

HTTP Status Codes are three-digit numbers returned by a web server (like IIS) in response to an HTTP request from a client (like a web browser). They indicate whether a specific HTTP request has been successfully completed. Understanding these codes is fundamental to troubleshooting web application issues.

This guide breaks down common HTTP status codes, explains their meaning in the context of a web server, and provides specific troubleshooting steps relevant to Microsoft Internet Information Services (IIS).

Understanding HTTP Status Code Categories

HTTP status codes are grouped into five categories:

  • 1xx Informational: The request was received and understood. The server is continuing the process. (Less common in typical end-user troubleshooting).
  • 2xx Success: The request was successfully received, understood, and accepted. (e.g., 200 OK).
  • 3xx Redirection: Further action needs to be taken in order to complete the request. (e.g., 301 Moved Permanently).
  • 4xx Client Error: The request contains bad syntax or cannot be fulfilled. (e.g., 404 Not Found).
  • 5xx Server Error: The server failed to fulfill an apparently valid request. (e.g., 500 Internal Server Error).

Troubleshooting often focuses on 4xx and 5xx errors, as these indicate problems preventing the client from accessing the desired resource or the server from processing the request.

Troubleshooting 4xx Client Error Codes (IIS)

4xx codes indicate that the problem is likely on the client side, although the server configuration (IIS) dictates how it responds to a client’s invalid request.

400 Bad Request

The server cannot process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Typical Causes in IIS:

  • Malformed HTTP headers.
  • Request exceeding size limits.
  • Invalid characters in the URL.

Troubleshooting Steps (IIS):

  1. Examine IIS Logs:
    • Why: IIS logs record details about each request, including the status code and substatus code, which can provide clues about why the request was considered bad.
    • How: Navigate to the IIS log files location (default is %SystemDrive%\inetpub\logs\LogFiles\<site_id>). Open the relevant log file and look for entries with status code 400. Check the substatus code (e.g., 400.1 for Invalid Hostname, 400.2 for Invalid Header, 400.3 for Invalid Bytes in URL).
    • Details: The substatus code is crucial for pinpointing the specific reason for the 400 error.
    • Typical Errors/Output: Log entries showing the client IP, requested URL, and the 400 status with a substatus code.
  2. Check IIS Request Filtering Configuration:
    • Why: Request Filtering in IIS allows administrators to block requests based on various criteria, such as URL length, query string length, headers, or specific characters. Overly strict rules can cause legitimate requests to be rejected with a 400 error.
    • How: Open IIS Manager, navigate to the server or site level, and double-click “Request Filtering.” Review the settings under “File Extensions,” “Rules,” “Hidden Segments,” “Deny Url Sequences,” and “Headers.” Click “Edit Feature Settings…” to check limits like “Maximum allowed content length,” “Maximum URL length,” and “Maximum query string length.”
    • Details: Ensure that the client’s request is not violating any of these rules or limits.
    • Typical Errors/Output: Clients receiving 400 errors for requests that seem valid but might exceed configured limits or contain blocked elements.
  3. Inspect Client Request (Advanced):
    • Why: To see the exact request being sent by the client, including headers and body, which might be malformed.
    • How: Use browser developer tools (Network tab) or network sniffing tools like Wireshark or Fiddler on the client side, or Wireshark on the server side. Capture the HTTP request leading to the 400 error.
    • Details: Analyze the raw request data for any syntax errors, unexpected characters, or violations of HTTP standards.
    • Typical Errors/Output: Malformed HTTP headers (e.g., extra spaces, invalid characters), incorrect content length header, invalid transfer encoding.

401 Unauthorized

The client must authenticate itself to get the requested response.

Typical Causes in IIS:

  • Anonymous authentication is disabled.
  • Incorrect or missing user credentials (Basic, Digest, Windows Authentication).
  • Permissions issues on the file system or network resource for the authenticated user.

Troubleshooting Steps (IIS):

  1. Check IIS Authentication Configuration:
    • Why: IIS needs to be configured to accept the type of authentication the client is providing (or expects).
    • How: Open IIS Manager, navigate to the site or application level, and double-click “Authentication.” Check which authentication methods are Enabled (Anonymous, ASP.NET Impersonation, Basic, Digest, Forms, Windows).
    • Details: If Anonymous Authentication is disabled, IIS will require authentication credentials. If using specific methods like Basic or Windows Authentication, ensure they are enabled and configured correctly.
    • Typical Errors/Output: Browser prompting for credentials repeatedly or displaying a 401 error page.
  2. Verify File System Permissions:
    • Why: Even if a user authenticates successfully, the IIS process identity or the authenticated user needs read permissions on the requested file or folder.
    • How: In Windows Explorer, navigate to the site’s physical path. Right-click the folder or file, select “Properties,” go to the “Security” tab. Check the permissions for the IIS_IUSRS group, the Application Pool Identity, or the specific authenticated user account.
    • Details: Ensure the necessary Read permissions are granted. For write operations, modify or write permissions are also needed.
    • Typical Errors/Output: 401 errors even after providing correct credentials, often accompanied by file system access denied errors in Windows Event Viewer or application logs.
  3. Check Application Pool Identity:
    • Why: The identity under which the application pool runs is the account IIS uses to access resources, including performing integrated Windows Authentication lookups or accessing file systems when Anonymous Authentication is enabled.
    • How: In IIS Manager, go to “Application Pools,” select the relevant pool, right-click and choose “Advanced Settings.” Check the “Identity.”
    • Details: Ensure the configured identity (e.g., ApplicationPoolIdentity, NetworkService, or a custom account) has the necessary network and file system permissions.
  4. Review Authentication Logs (if available):
    • Why: Some authentication methods or custom modules might log successful or failed authentication attempts.
    • How: Check Windows Security Event Logs or application-specific logs for authentication-related messages.

403 Forbidden

The server understood the request but refuses to authorize it. Unlike 401, authentication will not help.

Typical Causes in IIS:

  • Directory Browse is disabled, and no default document is configured.
  • IP Address and Domain Restrictions are blocking the client’s IP.
  • Permissions are explicitly denied for the user or group.
  • SSL is required, but the client is using HTTP.
  • Specific files or folders are explicitly denied access via configuration.

Troubleshooting Steps (IIS):

  1. Check IIS Default Document and Directory Browse:
    • Why: If a user requests a folder URL (e.g., http://yoursite.com/app/) and Directory Browse is disabled and no default document (like index.html, default.aspx) exists in that folder, IIS will return a 403.
    • How: In IIS Manager, navigate to the site or folder level. Double-click “Default Document” and “Directory Browse.” Ensure a valid default document is listed and exists, or enable Directory Browse if listing files is intended.
    • Details: The order of default documents matters.
    • Typical Errors/Output: Accessing a folder URL results in a 403 error page.
  2. Review IP Address and Domain Restrictions:
    • Why: IIS can be configured to allow or deny access based on the client’s IP address or domain name.
    • How: In IIS Manager, navigate to the server, site, or application level. Double-click “IP Address and Domain Restrictions.” Check if the client’s IP address is explicitly denied or if the configuration uses Deny by default with no Allow rules for the client’s IP.
    • Details: This feature can be configured globally or per site/application.
    • Typical Errors/Output: Clients from specific IP addresses or networks receive 403 errors.
  3. Verify SSL Settings:
    • Why: If “Require SSL” is enabled for a site or application and the client attempts to connect using HTTP, IIS will return a 403.
    • How: In IIS Manager, navigate to the site or application level. Double-click “SSL Settings.” Check if “Require SSL” is checked.
    • Details: Ensure clients are using HTTPS if SSL is required.
    • Typical Errors/Output: Accessing the site via HTTP results in a 403 error, often with a substatus code like 403.4 (SSL required).
  4. Check File System Permissions (Deny):
    • Why: An explicit Deny permission on the file system for the IIS process identity or a relevant user group will result in a 403.
    • How: As in the 401 troubleshooting, check the “Security” tab of the file or folder properties. Look for explicit Deny entries that might override Allow permissions.
    • Details: Deny permissions take precedence over Allow permissions.
    • Typical Errors/Output: 403 errors when accessing specific files or folders, potentially with a substatus code like 403.2 (Read access forbidden) or 403.3 (Write access forbidden).

404 Not Found

The server cannot find the requested resource.

Typical Causes in IIS:

  • The requested file or directory does not exist at the specified path.
  • Incorrect site bindings or physical path configuration.
  • Issues with handlers or modules processing the request.
  • Incorrect URL in the client request.

Troubleshooting Steps (IIS):

  1. Verify the File/Folder Exists:
    • Why: The most common reason for a 404 is that the requested resource simply isn’t there.
    • How: On the IIS server, navigate to the site’s physical path in Windows Explorer and manually verify that the requested file or folder exists and is spelled correctly, including case sensitivity if applicable.
    • Details: Double-check the site’s physical path configuration in IIS Manager (under “Basic Settings” for the site).
    • Typical Errors/Output: Browser displays a 404 error page.
  2. Check IIS Site Bindings:
    • Why: If the hostname or IP address used by the client doesn’t match an IIS site binding, IIS won’t know which site the request is for and might return a 404 or serve the default site.
    • How: In IIS Manager, navigate to the server, expand “Sites,” select the relevant site, and click “Bindings” in the Actions pane. Ensure a binding exists for the hostname, IP address, and port the client is using.
    • Details: Pay attention to host headers.
    • Typical Errors/Output: Requests using a specific hostname fail with 404, while using the IP might work (if a binding exists for the IP).
  3. Examine Handler Mappings:
    • Why: IIS uses handler mappings to determine which process should handle a request for a specific file type (e.g., .html, .aspx, .php). If the mapping is missing or incorrect, IIS might not know how to process the request and return a 404.
    • How: In IIS Manager, navigate to the site or application level. Double-click “Handler Mappings.” Check if there’s a mapping for the extension of the requested file.
    • Details: Ensure the handler mapping is configured correctly for the technology being used (ASP.NET, PHP, etc.).
    • Typical Errors/Output: Requests for specific file types (e.g., .aspx) result in a 404, while static files (e.g., .html) might work. Sometimes a 404.3 substatus (MIME type restriction) might indicate a related issue with MIME types.
  4. Check URL Rewrite Rules:
    • Why: If URL Rewrite rules are configured, they might incorrectly rewrite a valid URL to a non-existent path, resulting in a 404.
    • How: In IIS Manager, navigate to the site or application level. Double-click “URL Rewrite.” Review the configured rules to ensure they are not causing unintended rewrites that lead to 404s.
    • Details: Use the “Trace Failed Requests” feature (see 500 errors) to see how URL Rewrite processed the request.

405 Method Not Allowed

The HTTP method used in the request (e.g., GET, POST, PUT, DELETE) is not allowed for the requested resource.

Typical Causes in IIS:

  • Handler mapping restricts the allowed HTTP verbs.
  • Request Filtering is configured to deny specific HTTP verbs.
  • Web.config configuration restricting HTTP verbs.

Troubleshooting Steps (IIS):

  1. Review Handler Mappings (Allowed Verbs):
    • Why: Handler mappings not only specify which executable handles a request but also which HTTP verbs are allowed for that handler.
    • How: In IIS Manager, navigate to the site or application level. Double-click “Handler Mappings.” Select the relevant handler mapping and click “Edit.” Check the “Request restrictions…” button and review the “Verbs” tab.
    • Details: Ensure the HTTP verb the client is using is listed as allowed.
    • Typical Errors/Output: GET requests work, but POST requests to the same URL fail with 405, or vice versa.
  2. Check Request Filtering (HTTP Verbs Tab):
    • Why: Request Filtering has a specific tab for allowing or denying HTTP verbs globally or per site/application.
    • How: In IIS Manager, navigate to the server or site level. Double-click “Request Filtering” and go to the “HTTP Verbs” tab. Check for any verbs that are explicitly denied or if the configuration uses “Deny unspecified verbs.”
    • Details: Be cautious with “Deny unspecified verbs” as it requires you to explicitly allow *all* verbs needed by your application.
  3. Examine web.config for Verb Restrictions:
    • Why: Application-specific configurations in the web.config file can also restrict allowed HTTP verbs, often within the <handlers> or <security> sections.
    • How: Open the web.config file in the application’s root directory. Search for configurations related to HTTP methods or verbs, particularly within the <system.webServer> section under <handlers> or <security>.
    • Details: Look for elements like <add ... verb="..." /> or <remove verb="..." />.

Troubleshooting 5xx Server Error Codes (IIS)

5xx codes indicate that the server encountered an error while trying to process a seemingly valid request. The problem lies with the server, not the client’s request syntax.

500 Internal Server Error

A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.

Typical Causes in IIS:

  • Errors in application code (ASP.NET, PHP, etc.).
  • Incorrect configuration in web.config or applicationhost.config.
  • Issues with application pool (crashing, misconfigured identity).
  • Module or handler errors.
  • Permissions issues preventing the application from running or accessing resources.
  • Problems with backend connections (databases, APIs) initiated by the server-side application.

Troubleshooting Steps (IIS):

  1. Enable Detailed Error Messages:
    • Why: By default, IIS might show a generic 500 error page for security. Enabling detailed errors provides specific information about the exception or error that occurred on the server.
    • How:
      • Development Environment: In IIS Manager, navigate to the site or application level. Double-click “Error Pages,” then in the Actions pane, click “Edit Feature Settings…” and select “Detailed errors.” You might also need to configure web.config: 
        <configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
</configuration>
      • Production Environment (Caution!): It’s not recommended to show detailed errors directly to end-users. Instead, configure “Custom errors” to show a friendly page for remote clients but show “Detailed errors for local requests” or log the detailed error.
    • Details: Detailed errors often include the exact line of code causing an application error, configuration file parse errors, or information about failing modules.
    • Typical Errors/Output: Instead of a generic 500, you’ll see a specific .NET exception traceback, configuration error details, or module loading failures.
  2. Examine Application Pool Status and Configuration:
    • Why: Application pools provide the environment in which your application runs. Issues with the pool (crashing, wrong .NET version, misconfigured identity) cause 500 errors.
    • How: In IIS Manager, go to “Application Pools.” Check the status of the pool (should be Started). Right-click and select “Advanced Settings.” Review settings like “.NET CLR Version,” “Managed Pipeline Mode (Integrated/Classic),” and “Identity.” Check the Windows Event Viewer System and Application logs for errors related to the application pool (e.g., WAS errors).
    • Details: Ensure the .NET version and Pipeline Mode match your application’s requirements. Verify the Identity has necessary permissions.
    • Typical Errors/Output: Application pool stopping frequently, WAS errors in event logs, configuration errors related to managed modules.
  3. Check web.config and applicationHost.config:
    • Why: Syntax errors or incorrect configurations in these files are a common source of 500 errors.
    • How: Open the web.config file in the site or application directory and the applicationHost.config file (default: %SystemRoot%\System32\inetsrv\config\applicationHost.config) in a text editor. Look for malformed XML, incorrect section names, or conflicting settings.
    • Details: Even a single misplaced character or incorrect tag can break the entire site.
    • Typical Errors/Output: Specific configuration parsing errors are often shown if detailed errors are enabled, pointing to the line number in the configuration file.
  4. Trace Failed Requests:
    • Why: This IIS feature provides detailed logs for requests that return specific status codes (like 500), showing which IIS modules processed the request and where it failed.
    • How: In IIS Manager, navigate to the server or site level. Double-click “Failed Request Tracing Rules.” Add a rule for status code 500. Ensure “Failed Request Tracing” is enabled at the server level (“Configure” in the Actions pane). Replicate the error and then view the generated XML log files in the specified tracing directory (default: %SystemDrive%\inetpub\logs\FailedReqLogFiles\<site_id>).
    • Details: The trace logs are extremely detailed and can show which module failed, the error code, and the state of the request at different stages.
    • Typical Errors/Output: Complex XML files detailing the request processing pipeline and identifying the point of failure.
  5. Check Application Logs and Event Viewer:
    • Why: Application errors that cause a 500 are often logged by the application itself or in the Windows Event Viewer (Application logs).
    • How: Check specific application log files configured by your application. Open Windows Event Viewer and examine the “Application” and “System” logs for errors occurring around the time of the 500 error. Look for entries related to the application pool name or the application itself.
    • Details: Look for exception details, database connection errors, file access denied errors, or other application-specific error messages.

502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server.

Typical Causes in IIS (acting as a reverse proxy):

  • IIS is configured as a reverse proxy (using ARR – Application Request Routing) and the backend server returned an invalid or no response.
  • Connectivity issues between the IIS server and the backend server.
  • Backend server application crashing or returning malformed responses.

Troubleshooting Steps (IIS with ARR):

  1. Check ARR Proxy and Server Farm Health:
    • Why: If IIS is using ARR, it’s forwarding the request to a backend server defined in a Server Farm. The 502 indicates a problem with that backend communication.
    • How: In IIS Manager, navigate to the server level. Double-click “Application Request Routing Cache.” In the Actions pane, click “Server Farms.” Check the status of the server farms. Expand the farm and check the status of individual servers.
    • Details: Ensure the backend servers are online and healthy according to ARR’s monitoring.
  2. Verify Connectivity to Backend Servers:
    • Why: The IIS server needs to be able to reach the backend servers on the necessary ports.
    • How: From the IIS server, use ping <backend_server_ip> to check basic network connectivity. Use Test-NetConnection <backend_server_ip> -Port <backend_port> (PowerShell) or a port scanner to verify the required application port is open and reachable.
    • Details: Check firewalls between the IIS server and the backend server.
  3. Examine Backend Server Logs:
    • Why: The backend server likely encountered its own error while trying to fulfill the request forwarded by IIS.
    • How: Access the logs on the backend server (IIS logs, application logs, etc.) to see why it failed to respond correctly to IIS.
    • Details: Look for 5xx errors, application exceptions, or crashes on the backend server.
  4. Check ARR Tracing or Failed Request Tracing:
    • Why: ARR provides its own tracing, and Failed Request Tracing can capture details about the 502 response from the backend.
    • How: Enable ARR tracing (often through the URL Rewrite trace provider) and/or Failed Request Tracing for 502 errors. Analyze the logs to see the request being sent to the backend and the response received by IIS.
    • Details: The trace logs can show the exact error message returned by the backend server before IIS issued the 502.

503 Service Unavailable

The server is not ready to handle the request. Common causes are a server that is down for maintenance or overloaded.

Typical Causes in IIS:

  • Application Pool is stopped or disabled.
  • Application Pool is rapidly crashing (“rapid-fail protection”).
  • Server is overloaded (CPU, memory, network).

Troubleshooting Steps (IIS):

  1. Check Application Pool Status:
    • Why: If the application pool is stopped or disabled, IIS cannot process requests for sites running in that pool and will return a 503.
    • How: In IIS Manager, go to “Application Pools.” Check the status column for the relevant pool. If it’s Stopped or Disabled, right-click and select Start.
    • Details: If the pool immediately stops again, it’s likely crashing due to an application error (see 500 troubleshooting).
    • Typical Errors/Output: Application pool status is “Stopped” or “Disabled.”
  2. Review Application Pool Advanced Settings (Rapid-Fail Protection):
    • Why: IIS has a feature called Rapid-Fail Protection that will automatically stop an application pool if it crashes a certain number of times within a configured time period.
    • How: In IIS Manager, go to “Application Pools,” right-click the pool, and select “Advanced Settings.” Under the “General” section, review “Rapid-Fail Protection.”
    • Details: If the pool is stopping due to rapid-fail protection, you need to troubleshoot the underlying application error causing the crashes (see 500 troubleshooting).
    • Typical Errors/Output: The application pool event log entries indicating rapid-fail protection has been triggered.
  3. Monitor Server Resources:
    • Why: If the server is experiencing high CPU, memory, or network utilization, it might become unresponsive and return 503 errors.
    • How: Use Task Manager, Resource Monitor, or Performance Monitor on the IIS server to check resource usage when the 503 errors occur.
    • Details: Look for processes consuming excessive resources, particularly the w3wp.exe process(es) for your application pool.

504 Gateway Timeout

The server, while acting as a gateway or proxy, did not get a response in time from the upstream server.

Typical Causes in IIS (acting as a reverse proxy):

  • Backend server is slow to respond or has timed out.
  • Network latency or congestion between IIS and the backend server.
  • Timeouts configured in ARR or IIS are too low.

Troubleshooting Steps (IIS with ARR):

  1. Check Backend Server Performance:
    • Why: The 504 usually means the backend server took too long to send a response back to IIS.
    • How: Access the backend server directly (bypassing IIS ARR) if possible and test the response time of the resource. Check the backend server’s resource utilization (CPU, memory, database performance).
    • Details: The issue is often a performance bottleneck on the backend.
  2. Verify Network Latency/Connectivity:
    • Why: High network latency or packet loss between IIS and the backend server can cause timeouts.
    • How: Use tools like ping or tracert from the IIS server to the backend server to check latency and identify potential network hops causing delays.
  3. Adjust ARR and IIS Timeouts:
    • Why: If the backend is legitimately slow and cannot be optimized further, or if network conditions fluctuate, increasing timeouts in IIS/ARR might mitigate the issue (though it doesn’t solve the underlying performance problem).
    • How:
      • ARR Timeout: In IIS Manager, server level, double-click “Application Request Routing Cache,” then in the Actions pane, click “Proxy.” Adjust the “Timeout (in seconds).”
      • IIS Request Timeout: This is typically handled by the application framework (e.g., executionTimeout in ASP.NET’s web.config) or global ASP.NET settings, but ARR’s timeout is usually the relevant one for 504s.
    • Details: Increase timeouts cautiously, as very high timeouts can tie up server resources.
  4. Analyze Trace Logs:
    • Why: Trace logs (ARR tracing or Failed Request Tracing for 504) can show the request being sent to the backend and the point where the timeout occurred.
    • How: Configure and analyze trace logs as described in the 500 troubleshooting section, specifically looking for timeout events when forwarding the request.

Troubleshooting 3xx Redirection Codes (IIS)

3xx codes indicate that the client needs to take further action (usually following a new URL) to complete the request. While not errors, unintended redirects can cause issues.

301 Moved Permanently / 302 Found (Temporary Redirect)

The requested resource has been permanently or temporarily moved to a new URL.

Typical Causes in IIS:

  • HTTP Redirect feature is enabled.
  • URL Rewrite rules are configured for redirection.
  • Application code is issuing redirects.

Troubleshooting Steps (IIS):

  1. Check IIS HTTP Redirect Feature:
    • Why: IIS has a built-in feature to redirect requests for a specific URL or range of URLs to a new destination.
    • How: In IIS Manager, navigate to the site, application, or virtual directory level. Double-click “HTTP Redirect.” Check if “Redirect requests to this destination” is enabled and review the configured destination URL.
    • Details: Note whether the redirect is set to be permanent (301) or temporary (302).
    • Typical Errors/Output: Browser is automatically sent to a different URL than expected.
  2. Review URL Rewrite Rules for Redirects:
    • Why: The URL Rewrite module is commonly used for more complex redirection logic.
    • How: In IIS Manager, navigate to the site or application level. Double-click “URL Rewrite.” Review the configured rules, specifically looking for rules with an Action Type of “Redirect.”
    • Details: Examine the pattern and the redirect URL to understand why a specific request is being redirected. Use the “Test Pattern” feature in the URL Rewrite module.
    • Typical Errors/Output: Unintended redirects, redirect loops (where a URL redirects back to itself or another URL that redirects back to the first), incorrect destination URLs.
  3. Inspect Application Code:
    • Why: Redirects can also be initiated by the web application’s code (e.g., using Response.Redirect() in ASP.NET).
    • How: If the redirect isn’t configured in IIS, the application code is the likely source. Debug the application or review the code handling the specific URL being requested.
    • Details: Application-level redirects are common for things like login pages, form submissions, or handling old URLs.
  4. Use Browser Developer Tools to Track Redirects:
    • Why: Browser developer tools (Network tab) clearly show the initial request, the 3xx response, and the subsequent request to the new location.
    • How: Open developer tools (F12 in most browsers), go to the Network tab, and navigate to the URL. Observe the list of requests and responses, noting the status codes.
    • Details: This helps confirm that a redirect is occurring and shows the exact URL being redirected to.

This guide covers the most common HTTP status codes encountered when troubleshooting IIS websites. By systematically checking the relevant IIS configurations and logs based on the status code received, you can efficiently diagnose and resolve web application access issues.

© 2025 cordero.me • All Rights Reserved