IIS限制域名访问，核心方法是在站点绑定主机头的基础上，叠加URL Rewrite规则对HTTP_HOST进行校验，实现白名单或黑名单过滤；而多域名独立配置限制规则，则是为每个域名分别编写独立的规则条件，互不干扰。
iis限制域名怎么设置？先分清两种核心场景
不少人遇到的情况是：网站已经绑定了某个域名，但别人用服务器IP或另一个域名也能访问到站点内容，改了半天绑定的主机头还是不行，原因在于，IIS自带的主机头绑定只负责请求路由，并不承担访问控制，想真正限制域名,需要分场景看需求。
白名单模式：只放行指定域名，其他一律拒绝
给你一个常见场景：A站和B站共用一台独立服务器，A站绑定了 www.a.com，但对外IP是同一个，这时候有人通过IP直接访问，就能看到A站默认页,既不安全也不专业。
配置思路是：先允许全部请求进入，再用规则判定当前请求的Host头是否符合白名单，若不符合，直接返回403状态码,请求在应用层被拦下。
黑名单模式：阻挡特定域名，其余正常放行
另一种场景是网站本身有访问来源，但某个恶意域名或镜像站经常盗用内容，这时候设置黑名单，将特定域名加入拒绝列表,其余访问不受影响。
与白名单相比，黑名单的规则条件更简单，只需将 HTTP_HOST 的内容与目标域名做精确匹配，命中后返回403，不命中则放行，黑名单适合事后处置，白名单适合事前管控，两者可以同时存在,但要注意规则顺序。
不装模块的临时方案：利用主机头绑定做粗粒度过滤
如果只是临时过滤，不想安装额外模块，可以返回到IIS站点绑定本身。每个站点可以绑定多个域名，但不能绑定“除某域名以外”的集合,因此这个方案只适合单站隔离场景。
比如一台服务器上有三个站点，分别对应三个不同域名，只要在站点绑定里分别指定各自的主机头，就不会出现跨站点访问，但如果某个站点的请求头被篡改，绑定就失效了。行业共识认为，主机头绑定的隔离强度有限，仅适合内部测试环境，生产环境必须配合规则层控制。
多域名如何独立配置限制规则？URL重写是首选
多域名独立配置限制规则的核心思路：利用URL Rewrite模块，在web.config中为每个站点或每个域名单独写规则，规则之间通过{HTTP_HOST}区分匹配范围。 同一台服务器,可以不同站点使用完全不同的限制策略。
第一步：确认URL Rewrite模块已装好
在IIS管理器中打开站点，如果右侧有“URL重写”图标，说明已安装，没有的话，通过Web Platform Installer搜索“URL Rewrite”下载安装，装好后重启IIS服务。这是后续所有域名规则操作的基石模块，不装它，多域名独立规则无从入手。
第二步：在web.config中按域名拆分规则
以 www.a.com 和 www.b.com 两个站点共用IIS为例，需要做到：只允许访问 a.com 的请求到A站，只允许访问 b.com 的请求到B站,其余域名全部403。
在A站根目录的web.config中增加以下规则：
<rewrite>
<rules>
<rule name="A-Domain-Allow" stopProcessing="true">
<match url="." />
<conditions>
<add input="{HTTP_HOST}" pattern="^(www.)?a.com$" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="403" />
</rule>
</rules>
</rewrite>B站同理，只需把匹配的域名换掉，这段规则的含义是：如果请求的Host头不匹配 a.com，立即返回403；匹配则继续处理。这样两个站点各自独立限制，互不干扰。
第三步：验证访问结果与规则冲突排查
保存配置后，在浏览器分别输入 www.a.com，再尝试用另一个域名指向该IP发起访问，正常情况下，域名的请求正常打开页面,非白名单请求返回403错误页。
如果发现规则不生效,优先检查以下三点：
- 规则是否写进了正确的web.config文件（站点目录层级搞错会直接不生效）。
- 是否启用了 URL Rewrite 的“预编译”设置（长期缓存可能导致修改不刷新）。
- 是否存在其他模块（如ARR反向代理）在重写之前修改了Host头。
业内专家指出，多域名独立配置限制规则时，最容易出问题的不是规则本身，而是同一站点绑定了多个主机头或开启了URL重写转发的叠加效应。
规则优先级与冲突处理
多个规则同时存在时，IIS按照web.config中“rules”节点的顺序从上到下匹配，处理逻辑为：先匹配到“match url”，再校验其中所有condition条件，全部成立则执行action，此时若stopProcessing为true，该请求立刻结束，不再向下匹配。 所以优先将更严格的白名单规则放在靠前位置,黑名单规则放在后面兜底。
对于多个域名独立规则的情况，应该为每个域名单独写一个rule，而不是用一个rule里到处写多个条件,否则无法精确控制每个域名的独立策略。
iis域名白名单设置进阶：多场景下的实操细节
基础规则跑通之后，很多站长在实际部署中会遇到更复杂的情况,下面几个技巧能帮你把规则运用得更灵活。
共享IP下的多站隔离
同一IP上跑着多个站点，且每个站点都有独立域名和独立限制规则，这时不推荐在“服务器级别”统一配置域名限制，因为那样会把所有站点的规则混在一起,出现误伤。
正确操作是：在“站点级别”而非“服务器级别”配置web.config。 每个站点目录下放着独立的web.config文件，IIS会按站点的层级读取并应用各自的规则，这样可控性最强,也和前面类似问题的排查思路保持一致。
与CDN回源请求的兼容处理
当网站接了CDN加速时，IIS收到的HTTP请求来自CDN节点，Host头依然是源站域名，此时若规则按域名白名单过滤，CDN回源请求通常能正常通过，但有一种特殊场景：CDN服务商在回源时修改了Host头，改成回源域名或IP。 这种情况下规则会把真实来源拦截掉,导致全站打不开。
解决办法是在规则条件中同时允许两个Host值，一个是用户访问的公开域名，另一个是回源Host，也可以直接改为判断 {HTTP_X_forwarded_Host} 标头，但需要注意安全性,防止请求伪造。
多域名绑定同一站点的独立规则
如果多个域名指向同一个站点，且需求是不同域名走不同的访问限制，可以通过规则内的多个condition条件组合实现。a.com 允许访客访问，b.com
仅允许管理员来源IP访问，则先匹配域名,再匹配客户端IP。
- 规则1：匹配
{HTTP_HOST}为a.com,执行允许访问。 - 规则2：匹配
{HTTP_HOST}为b.com，条件追加{REMOTE_ADDR}属于内网IP段,允许访问。 - 规则3：其余情况,统一返回403。
这样既实现了多域名独立配置限制规则，又把IP维度的校验叠加进了域名规则中,满足更复杂的权限需求。
iis域名访问限制配置高频问题
规则写错导致网站全站403怎么办？
这是发生过很多次的情况。改错规则后，优先通过备份的web.config文件恢复或直接删除站点目录下的web.config文件中的rewrite节点。 一旦删除或还原，IIS会恢复默认行为，如果整个站点都打不开且不确定是哪个文件导致，可以暂时在IIS中停止该站点,再排查配置文件语法错误。
多域名独立规则与通配符规则同时存在时谁优先？
按IIS的规则匹配顺序，优先级由规则在配置文件中出现的先后顺序决定，而不是域名本身的长度或字符数量。如果一个通配符规则出现在具体域名规则之前，通配符会先拦截所有请求，具体域名规则将永远不会被执行。 因此必须把精确匹配的域名规则写在前面,把兜底或通配规则放在最后。
屏蔽访问后返回403还是301更合适？
403状态码适用于真正的访问拦截，而301跳转更适合域名迁移或规范化。 绝大多数“域名限制”场景的目标是不让某些来源看到内容，直接返回403最干净，搜索引擎不会误inherit收录，如果需求是把旧域名流量导流到新域名，再用301，不要混用，IIS的URL Rewrite规则中，CustomResponse 对应403，Redirect 对应301,选用哪种取决于你的业务意图。
回到核心问题：iis限制域名怎么设置？答案是规则驱动，而非绑定驱动，iis域名访问限制配置的本质就是对HTTP_HOST做条件判断，多域名独立配置限制规则的关键则在于为每个域名单独编写规则并将这些规则部署在对应站点的web.config中，把这两个逻辑想清楚,任何复杂的域名访问场景都能拆分出干净的解决方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/643427.html
