当Windows云服务器使用IIS访问Web站点提示“Bad Request – Invalid Hostname”时，核心原因是HTTP请求中的Host头与IIS站点绑定的主机名不匹配，解决方案是调整站点绑定或修改本机hosts文件。
这个报错到底在说什么
IIS作为Windows环境下的Web服务器，处理每个HTTP请求时都会检查请求头中的Host字段，这个字段是浏览器或客户端访问时主动携带的，告诉服务器“我要访问哪个域名”，当IIS发现这个Host字段与当前站点绑定的主机名对不上，就会直接返回400错误，页面显示“Bad Request – Invalid Hostname”。
举个例子，你在IIS里给站点绑定了www.example.com，但浏览器地址栏输入的是服务器公网IP，此时浏览器发送的Host头是IP地址，IIS翻遍所有站点绑定都找不到匹配项，于是拒绝服务，这个机制是IIS从7.0版本开始强化的安全策略,目的是防止恶意请求通过伪造Host头访问未绑定的站点。
为什么云服务器上这个问题特别常见
本地开发环境很少遇到这个报错，但放到Windows云服务器上，问题就频繁冒出来了,根源在于云服务器的访问路径比本地复杂得多。
本地访问IIS站点时，浏览器Host头写的是localhost，而IIS默认站点恰好绑定了localhost，天然匹配，云服务器场景下，你很可能用公网IP访问，或者用刚解析的域名访问,但IIS站点绑定里根本没有对应条目。
另一个高发场景是备案问题，国内云服务器要求域名备案后才能正常访问80端口，不少人为了绕过备案，直接用IP加端口访问，比如http://123.45.67.89:8080，如果IIS绑定的是域名加8080端口，直接敲IP访问就会触发Invalid Hostname。
如何快速定位问题根源
第一步：确认当前站点绑定配置
打开IIS管理器，左侧连接树选中你的站点，右侧操作栏点击“绑定”，查看弹出的窗口里有没有你访问时使用的域名或IP，如果绑定列表里只有www.example.com，而你用45.67.89访问,问题就出在这里。
第二步：查看请求的Host头到底是什么
按F12打开浏览器开发者工具，切到Network（网络）标签页，刷新页面，找到那个返回400错误的请求，点击请求详情，在Headers（请求头）部分找到Host字段,看它写的值是什么。
小于这步操作的人很多，但这一步能直接告诉你IIS收到的是什么,对照绑定列表一眼就能看出差距。
四种解决思路，按场景对号入座
修改IIS站点绑定，匹配你的访问方式
这是最直接的解决办法，如果你希望用户通过域名访问,就把域名加进绑定里。
- 打开IIS管理器，右键点击站点，选择“编辑绑定”
- 点击“添加”，类型选择HTTP，主机名填你的域名，端口填80
- 确认后重启站点，在服务器命令行执行
iisreset或直接在IIS管理器右侧点击“重新启动”
如果你希望用户通过IP访问，把主机名留空即可，留空意味着匹配所有Host头，但要注意这会让所有未绑定域名都指向这个站点,多站点部署时慎用。
修改本地hosts文件，强制域名解析
当你确认IIS绑定没问题，但浏览器就是报错时，问题可能出在DNS解析上，域名解析还没生效，或者解析到了别的服务器,你访问的域名根本就没指向这台云服务器。
临时验证方法就是改hosts文件,强制本机把域名指向目标服务器IP。
- 以管理员身份打开记事本
- 打开
C:WindowsSystem32driversetchosts文件 - 在末尾添加一行：
45.67.89 www.example.com（换成你的实际IP和域名） - 保存文件，刷新浏览器再试
这个方案适合排查问题，不建议长期使用，真正的解决路径是检查云服务商的控制台DNS解析记录，确认A记录指向正确，据行业共识，DNS解析生效时间最长可达48小时,但通常几小时内就能生效。
直接改用IP加端口访问
如果你只是想快速看到站点内容，不介意临时用IP访问,那给IIS站点加上一个IP加端口的绑定就行。
- 在IIS“编辑绑定”里，添加一条新绑定
- 类型选HTTP，IP地址留空或选服务器内网IP，端口填8080之类未被占用的端口，主机名留空
- 确认后在云服务商的安全组规则里放行该端口
这里有个坑要提醒你：云服务器的安全组规则和Windows防火墙是两道关卡，安全组放行8080后，还要检查Windows防火墙是否拦截了该端口，在服务器上执行netsh advfirewall firewall add rule name="IIS 8080" dir=in action=allow protocol=TCP localport=8080,一步到位。
检查反向代理和SSL证书配置
部分场景下，IIS前面还挂着ARR（Application Request Routing）或其它反向代理组件，这时Host头可能被代理组件改写,导致后端IIS收到的Host头与原始请求不一致。
如果你配置了HTTPS访问，还要检查SSL绑定是否包含正确的域名，IIS 8.0及以上版本支持SNI（Server Name Indication），多个HTTPS站点可以共用同一IP和端口，但每个站点必须绑定自己的域名，如果SNI配置错误,浏览器访问时也会出现Hostname不匹配的问题。
不同场景下的解决方案对比
| 场景 | 报错原因 | 推荐方案 | 操作难度 |
|---|---|---|---|
| 用IP访问绑定域名的站点 | Host头不匹配 | 增加IP加端口绑定 | 低 |
| 用域名访问但DNS未生效 | 域名解析错误 | 修改hosts验证 | 低 |
| 多站点共用同一IP | 站点绑定冲突 | 启用SNI或使用不同端口 | 中 |
| 反向代理场景 | Host头被改写 | 检查ARR代理设置 | 高 |
| 备案未完成用IP访问 | 绑定不匹配 | 使用非80端口访问 | 低 |
IIS绑定配置的常见误区和注意事项
通配符绑定不能乱用
不少人图省事，把主机名设为或留空，觉得这样所有请求都能访问，这个做法在单站点服务器上没问题，但多站点环境会出乱子，IIS会优先匹配精确主机名，匹配不到才走通配符绑定，如果你有两个站点，一个绑定www.example.com，一个绑定，访问www.example.com时没问题，但访问其它域名时全部落到通配符站点上,容易造成内容混乱。
端口冲突是隐形杀手
IIS绑定端口时，要确认该端口没有被其它程序占用，尤其是80端口，经常被Apache、Nginx、或者SQL Server Reporting Services抢占，在命令行执行netstat -ano | findstr :80，看到PID后用tasklist | findstr PID查是哪个进程占用的。
修改绑定后要重启站点
很多人在IIS管理器里改了绑定，浏览器刷新还是报错，就以为没改对，实际上IIS的配置修改需要站点重启才能完全生效，在IIS管理器右侧操作栏点击“重新启动”，或者执行iisreset /restart,确保配置加载完整。
用命令行排查IIS站点配置
除了图形界面，命令行工具也能快速查看和修改站点绑定，Windows Server自带的appcmd命令非常实用。
查看所有站点绑定信息：
%windir%system32inetsrvappcmd list sites修改指定站点的绑定：
%windir%system32inetsrvappcmd set site "Default Web Site" /bindings.http://:80:www.example.com添加新绑定：
%windir%system32inetsrvappcmd set site "Default Web Site" /+bindings.[protocol='http',bindingInformation=':8080:']
这些命令在远程管理云服务器时特别有用,不用打开图形界面就能完成配置调整。
IIS Bad Request Invalid Hostname 是什么原因
的问题本身，这个错误的直接原因是Host头与绑定不匹配，但深层原因可能涉及DNS解析、安全组规则、反向代理配置等多个层面，排查思路应该从绑定配置开始，逐层向外延伸，先确认IIS站点本身没问题,再检查网络层和系统层配置。
多数情况下，修改IIS站点绑定或在hosts文件里做临时解析映射就能解决问题，如果这两种方法都无效，就要检查是否有中间层组件改写了Host头,或者IIS是否被安全软件拦截。
下面整理几个相关问题作为补充。
IIS上如何同时绑定多个域名并正常访问？
在IIS站点绑定时，为每个域名添加一条独立的HTTP绑定记录，主机名分别填写对应域名，确认所有域名都解析到同一台服务器IP后，IIS会根据请求的Host头自动路由到对应绑定，如果域名数量较多，使用通配符绑定加URL重写规则可以简化管理,但精确绑定更安全可靠。
修改hosts文件后IIS仍然报错怎么办？
先确认hosts文件格式是否正确，IP地址和域名之间有至少一个空格，且该行没有以开头，然后用ping www.example.com看解析结果是否指向hosts里写的IP，如果解析正确但IIS仍报错，检查IIS绑定列表中是否包含该域名，以及站点是否处于启动状态,最后确认服务器防火墙和云安全组是否放行了对应的访问端口。
IIS站点绑定IP加端口后，外网还是无法访问？
这种情况通常是安全组规则或Windows防火墙没有放行对应端口，首先在云服务商控制台的安全组入方向规则里，添加允许该TCP端口的规则，然后在服务器上执行netsh advfirewall firewall add rule name="自定义名称" dir=in action=allow protocol=TCP localport=端口号，最后检查IIS站点是否成功监听该端口，命令行执行netstat -ano | findstr 端口号，看到LISTENING状态说明监听正常。
写在最后
IIS的Invalid Hostname报错本质上是Host头校验机制在起作用，它保证了多站点环境下的请求路由准确性，遇到这个问题不必慌张，按照绑定配置检查、DNS解析验证、端口放行确认的顺序排查，绝大多数情况都能在几分钟内解决，记住那个核心原则：请求的Host头必须与IIS站点绑定中的主机名完全一致，要么改绑定，要么改访问方式,两条路总有一条走得通。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/557545.html
