IIS Returning Bad Request - Invalid Hostname when accessing via IP address but not localhost

Sean Patterson 0

We have a server that suddenly started returning an HTTP 400 for Invalid Hostname after a reboot today. We have multiple other servers in the environment running the same configuration, OS version, patches etc. but do not see this issue.

This IIS server hosts several dozen IIS sites that are all configured similarly. HTTP binding, IP Address set at All Unassigned, Host Name field left blank with a unique non-conflicting port.

User's image

After a server reboot this morning, when we attempt to access any sites hosted on this server via IP address directly we are receiving the Invalid Hostname error however when attempting to access via hostname (localhost, server name, via a WAF with the host header being passed) we are properly receiving a response.

For example the following URLs fail:

http://127.0.0.1:1234/index.html

http://<serverIP>:1234/index.html

However these URLs work:

http://localhost:1234/index.html

http://<serverName>:1234/index.html

https://domain.com/index.html (which is forwarded by the Web App Firewall to the internal server on http with the host header containing the original request URL)

This is occurring with all sites hosted on this specific server, but not on other servers in the same environment with what should be identical configurations that also did a reboot this morning.

I cannot find any configuration differences between this server and ones that are working and am not seeing any sort of errors logged that would help me troubleshoot the issue further. The httperr log is reporting all of the invalid hostname requests like this:

2024-12-24 09:40:13 <sourceIP> 49756 <destIP> 18041 HTTP/1.1 POST <url> - 400 - Hostname W3SvcInspection

Where else can I look for logs to understand why IIS is returning the Invalid Hostname error?

Edit:

To confirm that I'm looking at the same site:

User's image

This is the confit for a test site.

http://localhost:19123 works fine

http://<servername>:19123 works fine

http://127.0.0.1:19123 returns invalid hostname

http://<serverIP>:19123 returns invalid hostname

These are the entries in the httperr log for the last 2 when running directly on the server:

2024-12-24 18:17:51 127.0.0.1 58322 127.0.0.1 19123 HTTP/1.1 GET / - 400 - Hostname W3SvcInspection

2024-12-24 18:17:51 127.0.0.1 58323 127.0.0.1 19123 HTTP/1.1 GET /favicon.ico - 400 - Hostname W3SvcInspection

2024-12-24 18:17:59 <serverIP> 58328 <serverIP> 19123 HTTP/1.1 GET / - 400 - Hostname W3SvcInspection

2024-12-24 18:17:59 <serverIP> 58329 <serverIP> 19123 HTTP/1.1 GET /favicon.ico - 400 - Hostname W3SvcInspection

MotoX80 34,856 Reputation points

2024-12-24T18:06:19.6833333+00:00

Your image shows port 18017 but your httperr log entry shows port 18041. Are you looking at the correct site?
Sean Patterson 0 Reputation points

2024-12-24T18:14:49.3+00:00

Yes, I grabbed a sample site as it's happening for all sites hosted on this server and they're all configured the same (different ports for each, but the same overall settings). Didn't think about grabbing the same site as the log entry since it was happening to all of the sites hosted on the server.

Here's one with the same port:

http://localhost:19123/URL works fine

http://<servername>:19123/URL works fine

http://127.0.0.1:19123/URL shows Invalid Hostname

http://<serverIP>:19123/URL shows Invalid Hostname

2024-12-24 18:11:51 127.0.0.1 58204 127.0.0.1 19123 HTTP/1.1 GET <url> - 400 - Hostname W3SvcInspection

2024-12-24 18:11:51 127.0.0.1 58205 127.0.0.1 19123 HTTP/1.1 GET /favicon.ico - 400 - Hostname W3SvcInspection

2024-12-24 18:12:26 <serverIP> 58218 <serverIP> 19123 HTTP/1.1 GET <url> - 400 - Hostname W3SvcInspection

2024-12-24 18:12:26 <serverIP> 58219 <serverIP> 19123 HTTP/1.1 GET /favicon.ico - 400 - Hostname W3SvcInspection

1 answer

MotoX80 34,856 Reputation points

2024-12-24T20:23:54.1166667+00:00

The word W3SvcInspection should be a clue about what's going on, but an internet search doesn't show much. I found that in iisw3adm.dll but surrounding text doesn't point to any specific function.

I can recreate the 400 error with a bogus hostname, but I don't see W3SvcInspection in my httperr log. That's on Win11.

Do you have any isapi filters or redirects that might affect the request url? Does "inspection" ring any bells?

If you add a bogus hostname to the site so that all requests fail, do you see W3SvcInspection on all/any 400 entries in the httperr log?

What about defining a simple new site and putting it on a different port. If that works then it would point to some configuration setting in the existing site.

If you don't find anything, then the next step is to configure Failed Request Tracing and capture the 400 error.

https://zcusa.951200.xyz/en-us/troubleshoot/developer/webapps/iis/health-diagnostic-performance/troubleshoot-arr-using-frt-rules

There are other sites on the net like this one that offer instructions on FRT if you run into problems.

https://4sysops.com/archives/iis-failed-request-tracing/

The biggest issue with FRT that I've experienced is with browsing the XML trace files. I've had to load MSEdge in IE Mode (from the 3 dot menu) to get it to format the file.
Please sign in to rate this answer.
Sean Patterson 0 Reputation points

2024-12-24T21:02:34.9633333+00:00

I can recreate the 400 error with a bogus hostname, but I don't see W3SvcInspection in my httperr log. That's on Win11.

If I enter a bogus hostname (www.test.com) I get a connection timeout instead of a Bad Hostname

Do you have any isapi filters or redirects that might affect the request url? Does "inspection" ring any bells?

Only isapi filters are the standard asp.net ones and match any of the other servers we have in this environment

If you add a bogus hostname to the site so that all requests fail, do you see W3SvcInspection on all/any 400 entries in the httperr log?

Adding a bogus hostname results in no entries in the httperr log

What about defining a simple new site and putting it on a different port. If that works then it would point to some configuration setting in the existing site.

Created a new index.html that's just a basic "Yay it works" in the html body and I get the same behavior where hitting it via IP gives an Invalid Hostname but via servername or localhost works.

If you don't find anything, then the next step is to configure Failed Request Tracing and capture the 400 error.

Added the most broad FRT I could. Status Codes 100-999, all content, full verbosity.

Browsing to me test site on http://localhost:19321/ logs an entry that looks about as expected for an HTTP load. I don't entirely know what I'm looking for, but nothing is jumping out as bad. I created an identical site on another server.

On that server all of http://localhost/ and http://<serverIP> and http://127.0.01/ work

I enabled FRT there as well and the FRT from the http://localhost/ load is identical to the one from the bad server with the standard exception of things like TimeCreated Correction ActivityID, Execution ProcessID, ContextID, and Computer which are expected to be different.

The odd part is that when I hit the site via IP address, even with the broad FRT on, I'm not getting anything as a trace at all. I enabled FRT on the sample site and added the rule both in the main IIS Server window as well as on the site.

I can see the entries in the httperr log but nothing is coming through as a trace.

MotoX80 34,856 Reputation points

2024-12-24T22:51:42.54+00:00

I configured FRT at the server level for 400 and 404.

Then on the individual sites I checked FRT and set it to inherit from the parent.

I get 404 traces but nothing on a 400 error.

Looks like IIS will only log an FRT entry if it knows which site to route the request to.

Check the httperr log again. Sometimes it takes some time before the entries get written. See if the 400's all have W3SvcInspection.

If some of your servers work and some don't, I don't know what to tell you. It's probably something simple and you'll want to bang your head when you finally figure it out. I gotta believe that W3SvcInspection is the best clue.

What about IPV6? Is that enabled/disabled on all servers?

Run this and look at the different Registered URL's. See if there is an asterisk in it. Maybe compare to a working server.

netsh.exe http show servicestate verbose=yes

Sean Patterson 0 Reputation points

2024-12-25T00:50:45.2166667+00:00

Check the httperr log again. Sometimes it takes some time before the entries get written. See if the 400's all have W3SvcInspection.

Yep, all 400s have the W3SvcInspection

If some of your servers work and some don't, I don't know what to tell you. It's probably something simple and you'll want to bang your head when you finally figure it out. I gotta believe that W3SvcInspection is the best clue.

Agree with this but unfortunately my searches haven't turned up anything useful.

What about IPV6? Is that enabled/disabled on all servers?

Working servers and the non-working one have 2 NICs. IPv4 on both, IPv6 on one of them as well. No meaningful difference in configuration that I can see

Run this and look at the different Registered URL's. See if there is an asterisk in it. Maybe compare to a working server.

AHA! now we have something!

Working server:

URL group ID: FD00000240000001 State: Active Request queue name: XXX Properties: Max bandwidth: inherited Max connections: inherited Timeouts: Timeout values inherited Authentication Configuration: Authentication schemes enabled: Number of registered URLs: 1 Registered URLs: HTTP://*:18190/<URL>/

Failing server:

URL group ID: C000000040000AE3 State: Active Request queue name: XXX Properties: Max bandwidth: inherited Max connections: inherited Timeouts: Timeout values inherited Authentication Configuration: Authentication schemes enabled: Number of registered URLs: 2 Registered URLs: HTTP://<PublicURL>:18190:<SERVERIP>/<URL> HTTP://<SERVERNAME>:18190:[FE80::7767:8424:163F:AD0B]/<URL>

Then at the top of the results for the failing server:

URL group ID: FE00000740000002 State: Active Request queue name: W3SvcInspection Properties: Max bandwidth: inherited Max connections: inherited Timeouts: Timeout values inherited Number of registered URLs: 109 Registered URLs: HTTP://:19321/ HTTP://:18128/ HTTP://:18043/ HTTP://:18200/ HTTP://*:18261/ ..... continues to list all

So somehow it looks like this W3SvcInspection is grabbing all of the standard listening URLs so they're not available for the other sites to get and they get the host name ones?

I'm out of my depth here so hopefully we're able to troubleshoot further. At least we have a lead now and can see a difference.

MotoX80 34,856 Reputation points

2024-12-25T14:45:00.7633333+00:00

I am at a severe disadvantage since I have no idea what you or your teammates have installed and configured on these machines.

Do you have any 3rd party anti-virus or intrusion detection software installed? Do you have a service or IIS site (worker process) named W3SvcInspection? Search the registry. Look for a folder/program with that name. Compare the software and Windows features that are installed on a working/non-working machine. Maybe something WCF related?

Sean Patterson 0 Reputation points

2024-12-26T13:48:16.6366667+00:00

Do you have any 3rd party anti-virus or intrusion detection software installed?

AV is Sophos Intercept X, which is the same as all the other servers.

Do you have a service or IIS site (worker process) named W3SvcInspection? Search the registry. Look for a folder/program with that name.

Zero programs, services or dlls by that name. Nothing is showing in the entire registry

Compare the software and Windows features that are installed on a working/non-working machine. Maybe something WCF related?

All identical as best I can tell.

You mentioned in your original post that you found W3SvcInspection "in iisw3adm.dll but surrounding text doesn't point to any specific function"

Where were you able to locate that? All of my searches for "W3SvcInspection" only return my posts here or on stack overflow, another guy who had the same issue in August and was directed here (but didn't appear to post, and I sent a message to him to see if he ever sorted it), and an old post from 2017 from the iis forums that is shown via rssing.com archiving.

At this point I'm trying to find any information I can on W3SvcInspection to figure out what might trip it up or cause it to grab all the URLs, but there's effectively nothing I can locate on the public internet.

MotoX80 34,856 Reputation points

2024-12-26T14:06:02.56+00:00

Duplicate comment. Buggy forum.

MotoX80 34,856 Reputation points

2024-12-26T14:54:23.09+00:00

Since the forum deleted both of our comments, I'll try again.

I used Agent Ransack to search my C: drive.

Then I used strings to extract text.

https://zcusa.951200.xyz/en-us/sysinternals/downloads/strings

Since that text was found in an IIS module, check the .config files in C:\Windows\System32\inetsrv\config and look for "inspect" in them. Or compare them with the files from a working server. There has to be something different.

Sean Patterson 0 Reputation points

2024-12-27T13:51:17.7666667+00:00

Since that text was found in an IIS module, check the .config files in C:\Windows\System32\inetsrv\config and look for "inspect" in them. Or compare them with the files from a working server. There has to be something different.

Nothing referencing "inspect" in any of the config files. All files in /config/Schema are identical, administration and redirection.config are identical. applicationHost.config has the expected differences.

Since the servers don't host identical webservices there's some different names of app pools, sites, and paths, but all of those are expected and reasonable. Other than those expected differences, the only difference in the files is the specific AES session key, which would be assumed to be different.

I went through all sites on the failing server in the apphost.config and nothing looked off.

I'm letting ransack run on the server now to see if it comes up with anything different on the server from either your example or a working server so hopefully that'll turn up something.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

IIS Returning Bad Request - Invalid Hostname when accessing via IP address but not localhost

1 answer

Your answer